[Owasp-esapi-c++] KeyGenerator

[Kevin W. Wall]

On Sat, Aug 6, 2011 at 6:47 AM, Jeffrey Walton <noloader at gmail.com> wrote:
> Hi Kevin,
>
> I was reading http://download.oracle.com/javase/1.4.2/docs/guide/security/jce/JCERefGuide.html#AppA.

A more up-to-date version:
http://download.oracle.com/javase/6/docs/technotes/guides/security/crypto/CryptoSpec.html

The format is a bit different, but this has more algoritims mentioned, e.g.,
HmacSHA256.

Also, the latest of what the SunJCE provides for JDK 6 is here, in
nice, succint table:
http://download.oracle.com/javase/6/docs/technotes/guides/security/SunProviders.html

> It might be a good idea to restrict ciphers and modes. I envision a
> knarly Factory with lots of manual instantiations if everything is
> supported. I believe there are [up to] AxMxP choices
> (algorithm/mode/padding).

Yep, I agree; given that one does not have reflectionat one's disposal, writing
factories usually beomes one big mess of if/else if/else if/... code.

You'll get a good idea of what we are using / accept in ESAPI 2.0, but
searching for "Encryptor" in its ESAPI.properties file.

I think there's a *miminal* set of what we need to support: Here's what I
propose:

Cipher Algorithms:
   Symmetric block ciphers:
        AES, DESede (2-key and 3-key varieties)

   Asymmetric algorithms:
         RSA

   Currently not using any symmetric stream ciphers such as RC4, so
don't need that,
   at least for now.

Message Digest / Hashing Algorithms:
   HmacSHA1, HmacSHA256, HmacSHA384, and HmacSHA512

Block Cipher modes:
    CBC, GCM, CCM
(Nothing to do w/ key gen, but while we're on the topic...)
Padding Schemes
    None, PKCS5Padding (note: equivalent to PKCS7 padding for ciphers
                      with block sizes up to either 128-bits, or maybe
even 256 bits...too
                       lazy to look it up, but works for all ciphers
I've ran across in either
                       JCE or MSCAPI).

    For RSA... not required yet, but thinking forward to ESAPI 2.1, I
think we would need
                      support for the OAEPWith<digest>And<mgf>Padding
padding schemes. At least
                      these:
                                        OAEPWITHSHA-1ANDMGF1PADDING,
                                        OAEPWITHSHA-256ANDMGF1PADDING,
                                        OAEPWITHSHA-384ANDMGF1PADDING,
                                        OAEPWITHSHA-512ANDMGF1PADDING
                                  and maybe
OAEPWITHMD5ANDMGF1PADDING, although I wouldn't use it
                                  for encryption.

I suppose it's debatable of whether we should support DES. I suspect there's a
lot of legacy encrypted data out there that might be able to benefit
from it, but by the
same token, anytime you support something, someone is going to abuse and I'd
really like DES to just die. So, mixed feelings about that. I can see
both sides.

Hope this helps somewhat.

-kevin
-- 
Blog: http://off-the-wall-security.blogspot.com/
"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