6

I want to derive a 256 bit encryption key and a 256 bit MAC key from a single 256 bit master key for an authenticated encryption scheme.

I was considering the following construction to derive the two keys using a secure 256 bit hash algorithm e.g. Keccak:

  1. Key 1 for encryption = H(master key | '0')
  2. Key 2 for MAC = H(master key | '1')

The advantage of this is that if the MAC key is compromised, it will not lead to decryption of messages as it should be hard to find a pre-image for the one-way hash to determine the master key and thus the derived encryption key.

Also, if only the encryption key was compromised, then this would also not compromise the master key so the attacker should not be able to determine the MAC key and be able to forge future transmissions.

Is this a secure method to derive two keys from one key? If not, what is a more secure method?

Mike Edward Moras
  • 18,161
  • 12
  • 87
  • 240
xenek
  • 63
  • 3

2 Answers2

5

Yes, this should be secure, as it is largely compatible with KDF1 and KDF2 which basically use a 4 byte big endian encoding of the counter instead of a direct ASCII conversion to a byte. Note that this construct works fine for master keys (short length, high entropy) but may be vulnerable to length extension attacks if larger input is allowed.

However, if you want to use the latest and greatest, you could use HKDF, possibly even augmented with a salt for session keys.

HKDF and the KDF's in NIST SP800-108 typically have a better security proof and supply methods of expanding the amount of key material after extracting the key material from the input. They also incorporate methods of supplying an explicit label and other information (using "enc" and "mac" instead of '1' / '2'). Unfortunately they are not often present in cryptographic libraries, they are harder to implement, they are badly defined and they seem to offer relatively few benefits over simpler schemes such as KDF1 and 2.

Community
  • 1
Maarten Bodewes
  • 96,351
  • 14
  • 169
  • 323
2

Depends on what you mean by Keccak.

There is actually a slight issue here that not all 256-bit Keccak variants have 256-bit preimage resistance. SHA3-256 (in the current SHA-3 draft) does have 256-bit preimage, but if you are using Keccak with 256-bit capacity it only has 128-bit preimage resistance. At least some of the earlier documents had 256-bit output Keccak with 256-bit capacity.

If your hash function has 128-bit preimage resistance, an attacker who gets your encryption key might also be able to break the authentication or vice versa, using "only" about $2^{128}$ operations. Of course, even that wouldn't be feasible currently, but since you are going with 256-bit encryption, you should ensure that all steps maintain 256-bit resistance.

If you are using the version from the current SHA-3 draft, you should be fine. However, I'd like to second the suggestion of using HKDF (perhaps with a more established hash like SHA-256), because it is a fairly standard way to derive keys.

otus
  • 32,462
  • 5
  • 75
  • 167