[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-crypto
Subject:    RE: Announce loop-AES-v1.3b file crypto package
From:       "IT3 Stuart B. Tener, USNR-R" <stuart () bh90210 ! net>
Date:       2001-07-12 1:57:40
[Download RAW message or body]

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@bh90210.net
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@nl.linux.org
[mailto:owner-linux-crypto@nl.linux.org]  On Behalf Of Mike Touloumtzis
Sent:	Wednesday, July 11, 2001 5:57 PM
To:	linux-crypto@nl.linux.org
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/

[prev in list] [next in list] [prev in thread] [next in thread]