SecureD Futures (v2.0)

[Adam Wilson]

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;