SecureD Futures (v2.0)

[Adam Wilson]

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;