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

Jim Manico jim.manico at owasp.org
Thu Aug 20 07:39:00 EDT 2009


Kevin changes to the encryption API are exceptional. Unless anyone has  
a strong objection we are going to deprecate some of the old APIs and  
migrate to Kevins work. I'd like to schedule a group code review of  
Kevins work before we push live.

Jim Manico

On Aug 20, 2009, at 1:25 AM, "Kevin W. Wall" <kevin.w.wall at gmail.com>  
wrote:

> 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
> _______________________________________________
> OWASP-ESAPI mailing list
> OWASP-ESAPI at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-esapi


More information about the OWASP-ESAPI mailing list