2

I have this scenario where I use Encrypt-then-MAC (AES256-CBC and HMAC-SHA256) with keys generated by a CSPRNG (specifically, SecureRandom in Java). I'd like to know which is better:

  • Use the CSPRNG to generate two distinct keys of 32 byte each

or

  • Use the CSPRNG to generate a master key of 32 byte and then use HKDF to derive the encryption and authentication key

I'd like to add that no human interaction is involved: this keys are stored inside a DB and are only used by machines.

Thank you very much!

Marcello
  • 357
  • 1
  • 2
  • 5

4 Answers4

3

If you are concerned about database size, only the master key needs to be stored when you use HKDF. Ditto when sending it to another computer. Otherwise, two independent random keys are clearly secure and simpler to implement, so you should do that.

otus
  • 32,462
  • 5
  • 75
  • 167
2

The other answers are now out of date. You should derive both keys from the same input keying material using a KDF.

If you randomly generate both keys, the construction will not be key- nor message-committing. This can lead to attacks in scenarios where keys can be adversarial. For example, if an attacker can submit a ciphertext encrypted using a password to a server that knows the key (an oracle), they can get a password guessing speedup due to a lack of key commitment.

This has affected the OPAQUE protocol, among others. Amazon also modified their AWS Encryption SDK to include key commitment by default. It's a property that was overlooked when designing AEADs.

As discussed here, it's also important to use a 256-bit+ authentication tag because committing security is about collision resistance.

samuel-lucas6
  • 2,211
  • 9
  • 20
2

If you are certain that SecureRandom is a trusted, verified CSPRNG you can use that without HKDF without problems.

user1028028
  • 719
  • 5
  • 18
1

Either is fine. If you're not concerned about database size or the size of transmitted keys, it doesn't matter which you choose. They are both secure. Choose whichever is more convenient, or easier to implement, or easier for others to interoperate with, or whatever other (non-security) criteria you might have.

D.W.
  • 36,982
  • 13
  • 107
  • 196