Re: Crypto Update for 2.6.38

2011-01-06 Thread Pavel Roskin

Quoting Herbert Xu :


setsockopt(tfmfd, SOL_ALG, ALG_SET_KEY,
   "\x06\xa9\x21\x40\x36\xb8\xa1\x5b"
   "\x51\x2e\x03\xd5\x34\x12\x00\x06", 16);


By the way, is it a good idea to use setsockopt() this way?  Some keys  
may be large.  And if AEAD is supported, will it use setsockopt() for  
the unencrypted authenticated data?


Maybe some variation of write() or sendto() would be more appropriate?

--
Regards,
Pavel Roskin
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Crypto Update for 2.6.38

2011-01-06 Thread Pavel Roskin

On 01/06/2011 04:16 PM, Herbert Xu wrote:


This is also why only hash and skcipher are supported as they
are the main algorithm types supported by teh current async
drivers in the kernel.


Are there any chances AEAD will be supported?  Is the API extendable to 
allow that?


If I remember correctly, the original patch was simply a port of FreeBSD 
/dev/crypto, which doesn't support AEAD.


--
Regards,
Pavel Roskin
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2] crypto: add blkcipher implementation of ARC4

2010-04-07 Thread Pavel Roskin
On Wed, 2010-04-07 at 10:29 +0200, Sebastian Andrzej Siewior wrote:
> * Pavel Roskin | 2010-04-07 02:19:55 [-0400]:
> 
> >On Mon, 2010-04-05 at 19:04 +0200, Sebastian Andrzej Siewior wrote:
> >
> >> +module_init(arc4_init);
> >> +module_exit(arc4_exit);
> >
> >I'm feelings uneasy about using the same module init/exit functions
> >names in arc4blk.c and arc4cip.c.
> >
> >Even though it doesn't break for me on x86_64 (whether I'm compiling
> >modules or a solid kernel), and even though the potential name conflict
> Take a look at
> - sd_mod_init
> - via_init
> - watchdog_init
> 
> just to name a few. There is no conflict because those functions are not
> global. The only problem you have is in the backtrace since you can't
> distinguish them.

Touché :-)

-- 
Regards,
Pavel Roskin
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 3/7] crypto/testmgr: add testing for arc4 based on ecb(arc4)

2010-04-06 Thread Pavel Roskin
On Sat, 2010-04-03 at 09:49 +0200, Sebastian Andrzej Siewior wrote:

> + if (mode == CRYPT_ARC4)
> + arc4_setup_iv((struct arc4_iv *)iv,
> + template[i].key, template[i].klen);
> + else
> + ret = crypto_ablkcipher_setkey(tfm, 
> template[i].key,
>  template[i].klen);

Can we avoid those special cases?  If the goal is "to make arc4
compliant with the crypto API", this looks like a step in a wrong
direction.

The same applies to many other changes in the series.

I do realize that the original arc4 is not a block cipher at all.

-- 
Regards,
Pavel Roskin
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2] crypto: add blkcipher implementation of ARC4

2010-04-06 Thread Pavel Roskin
On Mon, 2010-04-05 at 19:04 +0200, Sebastian Andrzej Siewior wrote:

> +module_init(arc4_init);
> +module_exit(arc4_exit);

I'm feelings uneasy about using the same module init/exit functions
names in arc4blk.c and arc4cip.c.

Even though it doesn't break for me on x86_64 (whether I'm compiling
modules or a solid kernel), and even though the potential name conflict
is temporary until arc4cip.c is removed, it could break on some other
architecture or maybe with another linker.

Let's use arc4blk_init and arc4blk_exit.

-- 
Regards,
Pavel Roskin
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Convert arc4 from a cipher into a block cipher

2010-04-05 Thread Pavel Roskin
On Sat, 2010-04-03 at 09:49 +0200, Sebastian Andrzej Siewior wrote:
> This patch series converts arc4 into a block cipher and converts all its
> users (except those in staging) to use it. The first two patches ensure
> that two implementations can coexist, the following patches convert each
> user so we remain bisectable.
> - lib80211_crypt_tkip was tested with ipw2200
> - mac80211 was tested with zd1211rw

Are you trying to speed up arc4?  Or you want to simplify the code?  Or
maybe you are trying to make arc4 unsuitable for anything other than WEP
and TKIP?  The later should be fine, actually, considering the known
security issues.

-- 
Regards,
Pavel Roskin
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Converting mac80211 CCMP to packet-at-a-time processing

2010-03-15 Thread Pavel Roskin
On Sat, 2010-03-13 at 20:28 +0800, Herbert Xu wrote:
> Pavel Roskin  wrote:
> > 
> > However, it's disappointing that the caller needs to deal explicitly
> > with completions.  The blkcipher API is much simpler.  I would have hard
> > time advocating a patch to CCMP that makes the code more complicated.
> 
> You won't have to deal with completions if you allocate your
> algorithm with the CRYPTO_ALG_ASYNC bit off.  Of course you won't
> be able to use most hardware accelerations either.

Actually, I thought using CRYPTO_ALG_ASYNC in the mask meant to
_exclude_ asynchronous algorithms.

Is there any documentation for Linux crypto API that documents use of
CRYPTO_ALG_ASYNC?  Also, I'd like to know meanings of
CRYPTO_TFM_REQ_MAY_BACKLOG and CRYPTO_TFM_REQ_MAY_SLEEP.

The crypto API feels like a minefield to me - I should check everything
in the code or even experiment to figure out how the public API works.

-- 
Regards,
Pavel Roskin
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Converting mac80211 CCMP to packet-at-a-time processing

2010-03-12 Thread Pavel Roskin
On Fri, 2010-03-12 at 11:49 +0100, Roberto Sassu wrote:
> Hello
> 
> i'm not expert with cryptographic modules, but i played sometime with the 
> "authenc" module, which is AEAD, and i applied it to the filesystem 
> "ecryptfs".
> In the forwarded message i added a brief description of what i do and i hope 
> this can be a useful example for you. 

Thank you!  That's indeed a useful example.

However, it's disappointing that the caller needs to deal explicitly
with completions.  The blkcipher API is much simpler.  I would have hard
time advocating a patch to CCMP that makes the code more complicated.

-- 
Regards,
Pavel Roskin
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Converting mac80211 CCMP to packet-at-a-time processing

2010-03-11 Thread Pavel Roskin
Hello!

The CCMP encryption in mac80211 uses crypto API to encrypt 16 bytes at a
time.  I believe this is not the best approach if hardware acceleration
is used.  The ixp4xx_crypto driver doesn't even provide the "aes"
ciphers.  It only provides block ciphers, such as "cbc(des)".

It would be much better if mac80211 could encrypt the whole packet at a
time.  Actually, that's what the WEP code is doing.

I realize that CCMP is a more sophisticated cipher, so maybe it's not so
easy.  "ccm(aes)" is probably the closest thing to what is needed, but
it's not even a block cipher, it's an AEAD.

Unfortunately, I don't see any examples of AEAD use in the kernel other
than the crypto testing module.  And I'm not even sure if "ccm(aes)" is
the right choice for CCMP.

I'll appreciate if somebody with a cryptographic background could have a
look at net/mac80211/aes_ccm.c and suggest whether it could be converted
to packet-at-a-time processing.

-- 
Regards,
Pavel Roskin
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html