Re: Crypto Update for 2.6.38
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: Crypto Update for 2.6.38
Quoting Herbert Xu herb...@gondor.apana.org.au: 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: [PATCH v2] crypto: add blkcipher implementation of ARC4
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: [PATCH 3/7] crypto/testmgr: add testing for arc4 based on ecb(arc4)
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
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: Convert arc4 from a cipher into a block cipher
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
On Sat, 2010-03-13 at 20:28 +0800, Herbert Xu wrote: Pavel Roskin pro...@gnu.org 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
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
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
