Remarks on 4.0 from owlstead

[Maarten Bodewes]

Hi Rob & all,

This is Maarten / owlstead calling in. Hopefully there is still time left for reviewing 4.0, otherwise this may be for 5.0 :)

Some remarks about 4.0:

- Generating 512 bits of data using PBKDF2/SHA1 is not recommended in my opinion. It requires 4 calls to the internal PBKDF2 function, including all the iterations. Furthermore, the internal state will be no more than 160 bits - the output of SHA-1. It would be better to use SHA-512, even if that is less available to some implementations. Of course, most passwords will never reach 160 bits of entropy.

- The protocol should be described in terms of HKDF instead of the underlying HMAC function (a further explanation of what that means in HMAC operations could be provided of course).
- Instead of generating one large output of HKDF-extract, the keys and validation value should be generated by providing a different "OtherInfo" value. This frees the protocol from the awkward repeated use of HMAC.
- Mixing SHA-512 and SHA-512 / 256 for HKDF is not recommended in my opinion. SHA-512/256 is not often available anyway. It could be that SHA-512 was meant, taking the leftmost bits. That is different from SHA-512/256 as that uses different vectors internally. The use of the leftmost bits of 512 should be made clear, unless the previous comment was heeded of course, in which case it is not needed.
- It could be considered to to allow a key size of 16, 24 or 32 bytes for the key based encryption; it will be put through the extract phase of HKDF anyway (using more possible sizes will make implementations harder to validate).

- You should not refer to the expired draft for AEAD using AES-CBC & HMAC-SHA2: https://datatracker.ietf.org/doc/draft-mcgrew-aead-aes-cbc-hmac-sha2/ Note that that draft does not explicitly specify how the IV should be used and if it is included in the calculations. That's the absolute minimum I would expect from a draft specifying an AEAD scheme really. Just leave the RNCryptor stand on it's own merit, there is no proof or anything for that draft anyway.

- You may want to restrict decryption depending on specific parameters / protocol versions etc..

OK, that's it for now, happy coding.

Regards,

Maarten

[Rob Napier]

Maarten, I just wanted to let you know that I have definitely gotten this, read it, and it's great and useful input that I want to respond to. I'm just headed off on vacation right now and haven't had time to dig in and think through it all (I think most of your comments are probably correct; I just haven't had time to really study them yet). The v4 format has been on hold for quite a while now, and I really do want to get to it this year, so this is certainly timely. I'll get back to you when I'm back from the Grand Canyon.

Thanks again.

-Rob