On Saturday 01 August 2009 04:32:05 Daniel Cheng wrote: > On Sat, Aug 1, 2009 at 3:38 AM, Evan Daniel<[email protected]> wrote: > > On Fri, Jul 31, 2009 at 2:07 PM, Matthew > > Toseland<[email protected]> wrote: > >> http://www.schneier.com/blog/archives/2009/07/another_new_aes.html > >> > >> Practical related-key/related-subkey attacks on AES with a 256-bit key > >> with 9, 10 and 11 rounds. The official standard uses 14 rounds, so there > >> is precious little safety margin - attacks always get better. > >> > >> We use AES/256 (technically we use Rijndael with 256 bit key and 256 bit > >> block size mostly, which isn't strictly AES, although we use 128 bit block > >> size, which is, for store encryption). > > It is believed that Rijndael(256,256) is weaker then AES. > But there is no proof on this, just more or less "NIST say so" kind of > argument. > > Schneier's blog suggest the AES-128 is better then AES-256. > > >> Such attacks rely on related-key weaknesses in the protocol (as in WEP, > >> where the IV > >> was too small). In theory we shouldn't have any, although I am not > >> entirely sure how to > >> determine this. We shouldn't have known ciphertext, because we have an > >> unforgeable > >> authenticator on all packets, but I'm not sure exactly what the definition > >> of a related-key > >> weakness is. > > Some related key attack does not need ciphertext, just a statistical > distribution of > it would work, as long as they have enough data. > > Related-key attack can be prevented by changing the key frequently and using > a secure key exchange protocol.
Okay so CTR mode does not present any particular vulnerability, for example, and as long as we never reuse IVs it's just a matter of the total volume of traffic encrypted using a single key? The 9 round attack only requires 2 related keys... but it depends on how many keys need to be used to have an acceptable chance of having 2 keys related in such a way... We do have a secure key exchange protocol, and we do change keys regularly, at the link layer. For block encryption, we use a single key for a single block. For the encrypted node.db4o we use CTR mode over the whole file, which can be large, but not gigantic (there is a size limit, approx 16GB iirc). For the datastore, we use [ 16 bytes salt ] + [ 16 bytes key hash ] to encrypt each block... > > >> Nonetheless, it would seem prudent to increase the number of rounds as > >> Schneier outlines (28 rounds for a 256-bit key). We have the > >> infrastructure to do this without too much trouble, with key subtypes and > >> negotiation types. Moving to AES/128 would be considerably more work. > > > > I think it would be worth trying to get someone who is a qualified > > cryptographer to look in detail at how Freenet uses cryptography. > > I think it is more important to *document* how freenet use cryptography. > Asking a cryptographer to go though these maze of java code is not > that easy. Agreed, we would have to have a cryptographer go over our documented protocols, which requires we document the protocols, in a single place where we could point him/her to. > > > Freenet does a *lot* of crypto, mixed together in ways that aren't > > necessarily common. It's also a very interesting project from a > > cryptographic standpoint; it seems possible that someone could be > > talked into doing it on a volunteer basis. Even if it wasn't > > volunteer, it might be worth seeing how much a proper review would > > cost. Cryptographic review seems appropriate for a program which > > relies so strongly on the strength of its cryptography. > > > > Evan Daniel
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
