On 05/28/2018 12:14 AM, sarn wrote:
On Monday, 28 May 2018 at 06:22:02 UTC, Adam Wilson wrote:
On 05/27/2018 08:52 PM, sarn wrote:
On Monday, 28 May 2018 at 02:25:20 UTC, Adam Wilson wrote:
I like it. But it does require more space. We need three salts and three lengths in the header. One for the PBKDF2 KDK, one for the MAC key, and one for the encryption key.

HKDF-Expand doesn't need a salt.  You just need one salt to make the KDK (whether you use PBKDF2 or HKDF-Extract for that) and no extra salts for deriving the encryption and MAC key.

Strictly speaking, it's is Optional but Strongly Recommended per RFC5869-3.1

There's HKDF-Expand and there's HKDF-Extract.  HKDF-Extract takes an optional salt and HKDF-Expand doesn't use a salt at all (take a closer look at that RFC).  That OpenSSL routine is the combination of the two, so that's why it takes the salt.

I understand that. But the way I read the first paragraph of 3.1 is that yes, it can work without a Salt, but HKDF, in general, is strongly suggested to be used with a salt. If we are really concerned about bytes we could reuse the salt for all three steps (KDK/MAC/KEY), but TBH, I'm not worried about disk usage.

Let me ask the question a different way. What is the reason NOT to use 2 different salts for the MAC and KEY generation steps?

--
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;

Reply via email to