On 05/27/2018 05:11 PM, sarn wrote:
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?
hashAlg is used for everything related to key derivation. Salts and IVs
are random.
- 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.
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.
Something like this:
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 kdkSLen; // The length of the KDK Salt
ubyte macSLen; // The length of the MAC Salt
ubyte keySLen; // The length of the KEY Salt
ubyte ivLen; // The length of the IV
ulong encLen; // The length of the encrypted data
ulong adLen; // The length of the additional data
ubyte authLen; // The length of the authentication value
}
Also, it's probably safer to use HKDF-Extract instead of using raw keys
directly when not using PBKDF2.
It is. And we could dot that if you stick to the default encrypt/decrypt
routines. I want to expand the symmetric capabilities of SecureD so I am
going to rebuild the encrypt/decrypt routines as a composition of
smaller methods. That will allow users to either use the default
encryption (simple) or if they have to interoperate with other systems,
use the component methods to perform their operations. I am not looking
to cover all scenarios though, just the common ones. If you have
something truly unusual, you'll still need to drop down the base crypto
libraries.
--
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;
