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

Boberski, Michael [USA] boberski_michael at bah.com
Thu Aug 20 08:57:28 EDT 2009


I've been watching this and similar threads, maybe time to jump in.

ESAPI is over-reaching, trying to include crypto, in general. I think these discussions are further going sideways by even further over-reaching by attempting to include PKI functionality, with the mention of OCSP below. Repeated mention of advice to use for example BouncyCastle is plain BAD advice. Go check out the US Marine Corps' PKIF toolkit on SourceForge, see how hard it is to do a PKI toolkit right.

I would NEVER use non-FIPS 140 validated code to provide crypto. I would also never use a non-FIPS 140 validated PKI toolkit, nor bless an underlying container's non-FIPS validated TLS implementation. These are items where I'm going to draw a hard line in my own use of ESAPI on customer engagements. Most 140-validated modules have a hard enough time working correctly let alone any non-FIPS modules, and are extraordinarily delicate once they are TECHNICALLY CORRECTLY installed/configured/operating in FIPS mode.

Keeping a wrapper for things like authentication is fine, that's kind of a toss-up whether it's usable. Really need to stay focused on features and functions that are unique to the IDEA of an ESAPI, and the IDEA of ES-Enabling applications, and make those core functions easily used and reusable. Work on standardizing and stablizing these things.

Mike B.


-----Original Message-----
From: owasp-esapi-bounces at lists.owasp.org [mailto:owasp-esapi-bounces at lists.owasp.org] On Behalf Of Rohit Sethi
Sent: Thursday, August 20, 2009 8:26 AM
To: Jim Manico
Cc: owasp-esapi
Subject: Re: [OWASP-ESAPI] [Fwd: AES 256-bit vs. AES 128-bit in ESAPI]

I'd strongly recommend following Kevin's suggestion about changing feedback modes to CBC.

Is it possible to dynamically test the ciphertext in Java to see which feedback mode it uses (i.e by looking for the presense of an initialization vector)? I this it would be a great transitional step to support ECB for decryption (if necessary) but then force CBC for encryption going forward.

Also, with respect to Moxie Marlinspike's research on vulnerabilities with Online Certificate Status Protocol (OCSP - i.e. the replacement for revocation lists) http://www.thoughtcrime.org/papers/ocsp-attack.pdf, does it make sense to add a beefed up version of OCSP support to ESAPI in order to protect apps using client certs? I'll admit I haven't done the research to see if Java is already planning on fixing this but I have my doubts. In fact, in general OCSP support is turned off in Java by default (http://java.sun.com/javase/6/docs/technotes/guides/security/certpath/CertPathProgGuide.html#AppC)

On Thu, Aug 20, 2009 at 7:39 AM, Jim Manico<jim.manico at owasp.org> wrote:
> 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
> _______________________________________________
> OWASP-ESAPI mailing list
> OWASP-ESAPI at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-esapi
>



--
Rohit Sethi
Security Compass
http://www.securitycompass.com
_______________________________________________
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