SecureD Futures (v2.0)

[sarn]

On Sunday, 27 May 2018 at 10:27:45 UTC, Adam Wilson wrote:
> struct cryptoHeader {
>     ubyte hdrVersion;	// The version of the header
>     ubyte encAlg;	// The encryption algorithm used
>     ubyte hashAlg;	// The hash algorithm used
>     uint  kdfIters;	// The number of PBKDF2 iterations
>     ubyte authLen;	// The length of the authentication value
>     ubyte saltLen;	// The length of the PBKDF2 salt
>     ubyte ivLen;	// The length of the IV
>     ulong encLen;	// The length of the encrypted data
>     ulong adLen;	// The length of the additional data
> }

Should there be any kind of key identifier, or do you consider 
that a separate issue?

> - MacKey = PBKDF2 over EncKey once using same inputs as EncKey

How about this?

Use PBKDF2 to generate a key-derivation-key (KDK), then use 
HKDF-Expand (https://tools.ietf.org/html/rfc5869) to derive the 
encryption key and MAC key separately.

I think that's more standard.  I don't know how much it matters 
in practice, but a lot of cryptographers don't like generating 
MAC/encryption keys from each other directly.

Also, it's probably safer to use HKDF-Extract instead of using 
raw keys directly when not using PBKDF2.