[Owasp-esapi-c++] KeyDerivationFunction: key derivation key size or range?

[Kevin W. Wall]

On Fri, Aug 5, 2011 at 3:29 PM, Jeffrey Walton <noloader at gmail.com> wrote:
> On Fri, Aug 5, 2011 at 9:38 AM, Kevin W. Wall <kevin.w.wall at gmail.com> wrote:
>> On Fri, Aug 5, 2011 at 4:14 AM, Jeffrey Walton <noloader at gmail.com> wrote:
>>> Hi All/Kevin,
>>>
>>> Does Java enforce a range or size on the keyDerivationKey used in
>>> KeyDerivationFunction?
>>
>> No. It only makes sure that the size is smaller than a minimum (and
>> there I picked
>> 56-bits so somone desparate could use DES if they had to in order to support
>> legacy crypto code, but really I should have made a property for that). It also
>> checks to make sure that the key size is an even multiple of 8 bits. (In other
>> words, an whole # of bytes.)
>>
>> Beyond that, for the size checking of the keys, I'm relying on the Cipher
>> class to do that. If you call one of its doFinal() methods to do encryption /
>> decryption and use an incorrect key size, it will throw an InvalidKeyException
>> which is rethrown as an EncryptionException.
> To be clear here -
>
>    SecretKey kdk(N Bytes); // Key derivation key
>
> Call KeyDerivationFunction::computeDerivedKey(kdk, ...):
>
>    - if kdk.size = 0, then throw (< 56)
>    - if kdk.size = 56, then OK
>    - if kdk.size = 128, then OK
>    - if kdk.size = 512, then OK
>    ...
>
> In case 2 above, we are potentially using 56 bits of key material to
> key a 160 bit (20 byte) HMAC.
>
> I feel like something is slipping between the cracks related to
> security levels. Perhaps a sanity check should be kdk.size >=
> requestedKeySize or kdk.size >= SHA1.blockSize.

Ah, I see where you are going with this. I think
adding at least an assertion that kdk.size >= requestedKeySize
might make sense. It would be stupid to pass in a DES secret
key and tell it you want a 256 bit key back. Definitely loosing
some entropy there.

If you look at java.security.Key, SecretKey is simply an interface
that implements that but adds nothing. It is purely for type safety.
The Key interface has a getAlgorithm() that stores the cipher, so
you might also be able to use SecretKey.getAlgorithm() for some
guesstimates at key size. (For ciphers with fixed key size, that would
be fine, for ciphers w/ variable key size, not so much.)

I guess I never worried to much about it because of how I was using
KeyDerivationFunction. And the disclaimer ("note") in the javadoc
for KeyDerivationFunction.computeDerivedKey() that states:

        This method is generally not intended to be called
        separately. It is used by ESAPI's reference crypto
        implementation class JavaEncryptor and might be useful
        for someone implementing their own replacement class,
        but generally it is not something that is useful to
        application client code.

I would have used 'Caveat' or 'Warning' rather than 'Note', but I already
had a 'Caution' in the immediately preceding paragraph.

OTOH, I do have a friend who is using this to generate a bunch of
derived keys from a single master key, so I can only hope he's doing
this sanely. (I've not seen his code.)

So, at a minimum, some assertions are perhaps in order. Or maybe
even make them runtime checks so if compiled with -DNDEBUG they
don't disappear.

This would be a good thing to add to the ESAPI 2.0 Java version as well.
If you could be so kind to open a Google issue on this there so I don't forget,
it would be much appreciated.

Thanks,
-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