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;
