[OWASP-ESAPI] [Fwd: AES 256-bit vs. AES 128-bit in ESAPI]

Kevin W. Wall kevin.w.wall at gmail.com
Thu Aug 20 01:25:30 EDT 2009


FWIW, Jim Manico asked me to post this to the ESAPI mailing list.
I've already changed the default cipher transformation for ESAPI Java 2.0
to be "AES-128/CBC/PKCS5Padding", so I did get the go ahead to make the
default 128-bit key size rather than 256-bit key size.

Comments???

-kevin wall

-------- Original Message --------
Subject: AES 256-bit vs. AES 128-bit in ESAPI
Date: Sun, 26 Jul 2009 21:11:51 -0400
From: Kevin W. Wall <kevin.w.wall at gmail.com>
Organization: Qwest IT - Application Security Team
To: Jeff Williams <jeff.williams at owasp.org>,  Jim Manico <jim.manico at owasp.org>

Jeff,
Jim,

First, feel free to move this discussion to the OWASP-ESAPI list if you
wish.

In the default ESAPI.properties file that is provided, there is this
comment and property setting:

    #=========================================================================
    # ESAPI Encryption
    ...snip...
    # WARNING: Not all combinations of algorithms and key lengths are supported.
    # If you choose to use a key length greater than 128 (and you should),
    # you must download the unlimited strength policy files and install in
    # the lib directory of your JRE/JDK.
    # See http://java.sun.com/javase/downloads/index.jsp for more information.
    #
    ...snip...

    # AES is the most widely used and strongest encryption algorithm
    Encryptor.EncryptionKeyLength=256
    Encryptor.EncryptionAlgorithm=AES

In other words, users are urged to use key sizes of > 128 bits, specifically
AES-256 over AES-128.

I am going to try to attempt to persuade you that we should check this
recommendation to state "you should choose a key size >= 128 bits" and
change the default algorithm to use AES-128 rather than AES-256.

The reasons for this, in decreasing order of importance (IMO) is:
1) 128-bit key is not subject to US Export restriction. Therefore not
   everyone from every country can legally download the unlimited strength
   policy files from Sun that you reference. In contrast, the standard JCE
   jars and policy files will support 128-bit symmetric encryption and all
   but 7 countries (Iran, Iraq, Cuba, North Korea, and 3 others I can't
   recall w/out looking them up) are legally allowed to download those.
2) These policy files need to be installed where the official JRE/JDK lives.
   Usually this will require a sysadmin to do on a production server. However,
   if these are not installed, the error message is not always obvious. In my
   experience, this simply causes developers to eschew using encryption
   altogether.
3) As ESAPI is presently written, symmetric encryption in JavaEncryptor uses
   ECB mode to encrypt. This cipher mode has many known weaknesses and is
   much more likely to be the weakest link in encryption using ESAPI than
   the a brute force attack on the key length. (NB: This is one area I am
   addressing. I plan on making changes so that CBC will become this default
   cipher mode, but this has many backward compatibility issues so I can't
   promise it will be done when 2.0 is released. May have to wait until 2.1.)
4) Performance can be an issue as well. Encryption and decryption with a longer
   key size doesn't come for free. I'll see if I can find the results of the
   tests we ran. If you are only encrypting a few thousand pieces of data,
   performance might not be a big deal, but if you have a few million records
   you need to encrypt/decrypt from a DB it just might.
5) If one assumes that the cipher itself does not have any other known attacks,
   then key length becomes significant as the best one is assumed to be able to
   do is a brute force attack. However, frequently there are other
   vulnerabilities to obtain the key itself (e.g., on the key distribution or
   key storage, etc.) and brute forcing a 128-bit key vs. a 256-bit key is
   insignificant when looking at this from a practical rather than theoretical
   POV. For instance, if one could check a billion billion keys/sec (i.e.,
   10**18 keys/sec) would take 10**13 years to search the entire key space.
   And, for brute force attacks, on average, you will need to search half of the
   key space. But 10**13 years is roughly longer than the age of the universe.
   Sure, you could increase that search time to 2**128 as much by using a
   256-bit key size, but exhaustive searching a 128-bit key already takes longer
   than the universe is old, so who cares if it would take 2**128 times longer?
   BTW, most professional cryptographers I've seen figure that around 80-bits is
   sufficient for keeping secrets safe for the next 20 years or so, so 128-bits
   should be more than enough. If quantum computers become widely available,
   then everyone is going to have to reconsider the implications, but until that
   time I wouldn't loose sleep over it. One is much more likely to succumb to a
   "rubber hose" attack than a brute force attack on the key size of algorithm.
   (Aside: Somewhat ironically, the latest weakness found in AES is more
   more successful with longer key sizes than it is for shorter ones. Thus
   256-bit keys are most susceptible, followed by 192-bit keys, and finally
   128-bit keys. Read about it here
	http://cryptolux.uni.lu/mediawiki/uploads/1/1a/Aes-192-256.pdf
   and Bruce Schneier comments on it in his blog here
	http://www.schneier.com/blog/archives/2009/07/new_attack_on_a.html)

Therefore, because of all these things, I propose that we reword the
recommendation of the key size to simply state that it be >= 128 bits
and change the default to use AES-128 rather than AES-256. (It's OK to
leave the note about the unlimited strength policy, but that should
say it is only needed if one intends to use a key size of longer
than 128 bits.)

-kevin
--
Kevin W. Wall
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents."        -- Nathaniel Borenstein, co-creator of MIME



-- 
Kevin W. Wall
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents."        -- Nathaniel Borenstein, co-creator of MIME


More information about the OWASP-ESAPI mailing list