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

Rohit Sethi rklists at gmail.com
Thu Aug 20 12:40:27 EDT 2009


You're right, ocsp shouldn't be part of esapi. I stand corrected. I
should probably just take this up with the core java implementation
rather than trying asking to wrap it into esapi.

On 8/20/09, Boberski, Michael [USA] <boberski_michael at bah.com> wrote:
> 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
>


-- 
Rohit Sethi
Security Compass
http://www.securitycompass.com


More information about the OWASP-ESAPI mailing list