Consider Driving New Cipherkey for Each Encryption

[ircmaxell]

Consider generating a random salt every time you encrypt data.

That way, you can use HKDF to derive a new cipherkey, mackey and iv from the master key. Then, just pass the salt with the ciphertext instead of the iv (since you can regenerate the IV).

For example:

$salt = self::getRandomBytes(16, true);
$cipherKey = self::hkdf($this->masterKey, 'sha512', 32, 'cipherkey', $salt);
$macKey = self::hkdf($this->masterKey, 'sha512', 32, 'mackey', $salt);
$iv = self::hkdf($this->masterKey, 'sha512', 16, 'iv', $salt);

That way, you don't run into CTR key rotation issues with generation of 2^64 plain texts with the same cipher key (since every encryption here uses a unique cipherkey).

[narfbg]

Hmm, I hadn't thought of that and I wanted to use a salt. Thanks!

[narfbg]

I was just implementing this and stumbled upon the same issue that I had earlier (wanted to use the IV as salt) ... Because authentication is applied over the cipherText and IV/salt, I wouldn't be able to derive the hmacKey during decryption.

The same issue prevents me from using PBKDF2 to allow users to just use a password instead of a key.

[ircmaxell]

Well, as said in #5, that shouldn't be done anyway.

And you don't need to MAC the IV/salt with the ciphertext anyway.

If you derive the keys, using the code I have above, then validating a MAC on the ciphertext (decoded) without the IV/salt would also validate the IV/salt since the key is derived from it.

Example:

$raw = base64_decode($data);
$salt = substr($raw, 0, 32);
$mac = substr($raw, 32, 32);
$ciphertext = substr($raw, 64);
$macKey = hkdf($masterKey, 'sha512', 32, 'mackey', $salt);
if (hmac(hmac($ciphertext, $macKey), $macKey) !== hmac($mac, $macKey)) {
     // Authentication failed
}
$cipherKey = hkdf($masterKey, 'sha512', 32, 'cipherkey', $salt);
$iv = hkdf($masterKey, 'sha512', 16, 'iv', $salt);
// decrypt

There really isn't any reason to MAC the encoded ciphertext as opposed to the raw ciphertext (and doing so may open up additional vulnerabilities)...

[defuse]

Does anything else use this salt derivation method? It seems like it's relying on unproven properties of HKDF and HMAC.

[ircmaxell]

@defuse http://crypto.stackexchange.com/questions/5630/deriving-keys-for-symmetric-encryption-and-authentication (I asked the question, but check out the answers)...

[defuse]

@ircmaxell I feel a little better about it now, but would still like to see a security proof.

If used, the salt should be 256 bits, not 128. If it's 128, then a salt will repeat after 2^64 encryptions.

[defuse]

I'll think about this more later. I'm probably being overly-cautious.

[narfbg]

OK, moving the discussion from #5 here, since I think it's more relevant.

Quoting:

So, I'm more concerned about the possible drawbacks of not covering the Base64 string

Which are?

What you want to be doing is EtM (Encrypt Then MAC). This is specified in ISO/IEC 19772:2009 as using a MAC directly on the ciphertext output from the encryption function. Not the ciphertext with IV, not the ciphertext encoded, the raw ciphertext.

Now, I don't know about ISO/IEC 19772:2009 (paywalled, not cool), but a few searches led me to these:

• A blog post about Encrypt-then-MAC describes why we should MAC IV || CipherText.
• RFC Draft describes that C_0 (first block of the cipherText) is the IV (and therefore HMAC is applied over it as well).

And a few StackExchange answers that also say we should (H)MAC basically everything:

• http://security.stackexchange.com/a/32118
• http://crypto.stackexchange.com/a/224/15094
• http://crypto.stackexchange.com/a/924/15094
• http://stackoverflow.com/a/10290712/468027

And the cryptographic doom principle as a bonus, although I'm not sure if key/IV derivation counts as a cryptographic operation in that context.

True, all of these talk about CBC and I don't know if the same attacks can be successful against CTR, but still - it makes it sound scary to HMAC the raw cipherText, not including the IV.

That's not the real issue though, I could HMAC(IV || cipherText) and still use the IV as salt (or derive an IV using that salt). The question is, is it possible that an attacker could exploit that to forge a valid HMAC + cipherText with their own salt? Or does using that salt for derivation really verifies its authenticity?

This answer to my question says it's "a definite no". (In relation to your exchange though, the second answer reassures us that using HKDF with salt is encouraged)

So we have a lot of contradictions here ... I don't like trusting the internet in general. I'd like to trust you two guys here, since I've learned a lot of stuff from you, one way or another. But I'd also like us to be completely sure about it.

I'm starting to think of another approach: keep the salt secret, appended to the key. It would double the required storage, but at least that isn't a security risk.

[defuse]

You absolutely must HMAC the IV in the normal case. The only possible exception is with the weird salting thing because changing the salt would change the HMAC key, but I'm still not sure that it's secure.

[defuse]

Salt shouldn't be kept secret. If a salt is secret, it's not a salt, it's another key.

[narfbg]

Sure, I get that ... point being, it wouldn't be used as a key itself.

[defuse]

Yeah, what I mean is if the security depends on it being secret, then it is a "key", regardless of whether you pass it as the "key" parameter of a cipher or MAC.

[defuse]

Breaking out the whiteboard. 😃