Mr. Touloumtzis: After reading your email I have surmised the following facts: a) AES is a safe choice to use b) a safe choice would be to use a key of 256-bits or greater (as this will work for email, filesystems, long term public data, and SSH login passwords, etc.), I will choose 128 for the moment, unless I am told a faster key will not damage noticeably the speed with witch a filesystem or other device can be read and written to given the additional overhead of the encryption technology As well in paragraph three of your reply you state "AES is not needed because 3DES is insecure; it's needed mainly because 3DES is _slow_, especially in software." This statement appears to absolutely make little sense. First of all if 3DES is insecure as you state, why are you the only person saying so? As well, if we give you the benefit of the doubt and presume for the moment (and I disagree) that 3DES is insecure, why does that make AES "not needed"!?! If 3DES is insecure, from my purview, it would make AES MORE NEEDED!?!?! You then go on to state that AES is needed because 3DES is slow in software, but 3DES runs independently of AES, and there two (as I understand) are separate algorithms. Hmm, guess I really didn't get you on that one. The software that you publish before (which I have yet to review), does it compile under Linux? As well, does it generate usable pass phrases to work with AES-128 or AES-256 viably? Very Respectfully, Stuart Blake Tener, IT3, USNR-R, N3GWG Beverly Hills, California VTU 1904G (Volunteer Training Unit) stuart@xxxxxxxxxxx west coast: (310)-358-0202 P.O. Box 16043, Beverly Hills, CA 90209-2043 east coast: (215)-338-6005 P.O. Box 45859, Philadelphia, PA 19149-5859 Telecopier: (419)-715-6073 fax to email gateway via www.efax.com (it's free!) JOIN THE US NAVY RESERVE, SERVE YOUR COUNTRY, AND BENEFIT FROM IT ALL. Wednesday, July 11, 2001 6:31 PM -----Original Message----- From: owner-linux-crypto@xxxxxxxxxxxx [mailto:owner-linux-crypto@xxxxxxxxxxxx] On Behalf Of Mike Touloumtzis Sent: Wednesday, July 11, 2001 5:57 PM To: linux-crypto@xxxxxxxxxxxx Subject: Re: Announce loop-AES-v1.3b file crypto package On Wed, Jul 11, 2001 at 03:10:00PM -0700, IT3 Stuart B. Tener, USNR-R wrote: > Miket: > > It really made no sense to me to here you say that having as many > bits as you want is not a safe thing to do as juxtaposed against a > backdrop of security for purposes of a threat of law enforcement > investigation, intrusive subpoena or just playing with crypto. I > presume you meant that there must be a minimum number of bits to > have. I personally am not breaking the law, nor am I worried about > being served with any intrusive subpoena, but I do believe in > having a level of encryption able to be stronger than what would > be subvertable by average law enforcement only as a bar to measure > up against how strong my encryption methodology and implementation > is. > > Are you saying that the implementations of crypto this group is > using are not strong enough to subvert even law enforcement? I > would tend to disagree with that, since the NSA is using AES! I > think you had better think again about what you just said, I doubt > anyone will take those words too seriously. Sorry, I guess I misunderstood your question. When I said "you can have as many bits as you want" I meant that there is no limit on the amount of passphrase entropy you can generate using the method I described. In terms of the question "what key length is safe for a symmetric crypto algorithm?" you are not alone in your frustration; one of the complaints about the FIPS for AES is that NIST provides for 128, 192, and 256 bit keys without any guidelines on when you should use which. Here is my understanding of the situation: -- All of the following symmetric encryption algorithms are currently believed to have no practical attacks given good key selection: AES, IDEA, Blowfish, Twofish, 3DES (DESede), CAST5, CAST-256, MARS, Serpent (there are more, too, but I think this covers the really common ones). If you are using one of these algorithms and your key selection is good, it is going to be much easier to use other methods than decryption to get at your data (for example, law enforcement agencies would try to surveil your monitor, bug your keyboard, or search your belongings for written pass phrases before they would try to crack such data). -- AES is not needed because 3DES is insecure; it's needed mainly because 3DES is _slow_, especially in software. AES is about eight times faster in software. The most important security consideration in AES is the move to a 128-bit block size, making attacks against ECB mode usage harder, but this is not a big deal for most cipher users (e.g. loopback FS in Linux uses CBC mode which is not vulnerable in the same way). -- A 64-bit key is not safe. The worldwide RC5-64 project on distributed.net has made it 52% of the way through a brute force search of a 64-bit keyspace. With today's technology this took over 1300 days with thousands of computers participating, but the fact that it's feasible at all means that this is not a good choice going forward. -- A 128-bit key is well beyond any current means of brute force search. In fact, most people are pretty comfortable with 3DES, which has a 112-bit effective key length. Anything above 128 bits is gravy. No one nowadays has any good reason to design a cipher with fewer than 128 bit keys (although there are evil reasons ;-). -- If you're using a passphrase with a symmetric algorithm, the way things work is that your passphrase is passed through a cryptographic hash function like MD5 or SHA-1. The entropy of the resulting key depends on the entropy of the pass phrase going in (and the quality of the hashes, but these two are considered pretty good for this purpose; I personally favor SHA-1). Here's how I decide what algorithm to use: -- For really long term data I use AES-256. Speed is not an issue on a PC nowadays, and AES-256 gives not only a longer key, but also more rounds. I may not be getting the full effect (passphrases with 256 bits of entropy are long, and most systems still aren't using hashes with 256-bit outputs, although some new SHA variants have been standardized with outputs that long). Still, given CPU speeds today, I don't see any reason _not_ to use AES-256 given the choice. -- I assume 3DES or any of the above public, well-peer-reviewed 128-bit+ algorithms are safe barring a qualitative (not merely quantitative) improvement in cryptanalytic technology. Lots of smart cards, etc. are probably going to use 128-bit, 10-round AES for performance reasons; I won't doubt their security on those grounds. -- I avoid using Skipjack (80 bit key, not a common algorithm anyway, and there are other reasons to mistrust it :-) on down. The main context in which weak ciphers come up these days is Web sites that want to use pathetic key sizes with SSL; you can disable the small key sizes in your browser. Here's how I decide how long and complex a passphrase to use: -- For login passwords (like for SSH remote logins) I try to have about 56 bits of entropy or so, on the grounds that I'll detect someone trying to brute force the keyspace long before they discover the password. -- For encrypted filesystems (of which I don't currently have any) I would try to use passwords that are 80+ bits, but I wouldn't be really anal about 128 bits of entropy. Filesystem contents are not public, so if you start to get worried you could re-encrypt with a stronger passphrase. -- For GPG email and other things that might be accessible in Internet archives essentially forever, I feel safe starting at 128 bits. miket Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
