SecureD Futures (v2.0)

[Adam Wilson]

Now that SecureD v1 is in the books I thought it would be worthwhile to 
explore what a second version could like. I specifically want to focus 
on expanding compatibility with other systems.

For example: AWS uses SHA2-256 for signing requests. As implemented 
today SecureD does not support this. However, this is one of the 
scenarios that falls under SecureD's mission of ease-to-use cryptography 
for non-transport layer security.

I am curious what people would like to see in SecureD moving forward and 
I would love to get your feedback on what works and what doesn't work in 
v1 of SecureD.

With this in mind here are my ideas for expanding SecureD's 
capabilities. I'll start with the idea that I think will be the least 
controversial.

1. Full support for SHA-2 and SHA-3 for Hashes and HMAC's.

This means the following modes would be supported:
SHA2: 224, 256, 384, 512, 512/224, 512/256
SHA3: 224, 256, 384, 512

The PBKDF2 implementation would also be updated to support the above 
hash functions.

Hash methods supporting salts will be added.

To maintain backwards compatibility with v1, methods that match the v1 
signatures and forward to the correct implementation would be provided 
as the v1 defaults are still secure.

This requires OpenSSL 1.1.1 at a minimum. Note that SHA3 support could 
be delayed until SecureD 2.1 if OpenSSL 1.1.1 is not available on a 
majority of systems prior to shipping 2.0. In such case OpenSSL 1.1.0 
would become the minimum supported version.

2. More Flexibility for Symmetric Encryption.

Currently SecureD only supports AES256-CTR-HMAC384 and the encrypted 
data is laid out as: HASH+IV+DATA. This is only useful in scenarios 
where the developer controls both the encryption and decryption of the 
data. Additionally, this does not support AEAD modes, only AE modes.

The first thing I would like to do is to support all AES, SHA2, and SHA3 
modes. I also want to add support for the CBC cipher mode with PCKS#7 
padding as that is the most common cipher mode in use.

One of the primary use cases for SecureD is long-term storage of data. 
To facilitate this requirement I would like to add a binary encoded 
header to each encrypted blob. This header would contain the necessary 
information to decode the blob (minus the key of course).

The header would cost 26 bytes per encrypted blob and would have the 
following layout:
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
}

The data layout would be: HEADER+AUTH+SALT+IV+ENC+AD
Any excluded elements would be marked as 0 in the header and completely 
excluded from the data layout.
The MAC would be computed as: HMAC(HEADER+SALT+IV+ENC+AD)

The full encryption process would be as follows:
- Create a PBKDF2 salt via RNG
- Create IV via RNG
- Create header from user inputs
- EncKey = PBKDF2 over RawKey unless hashAlg is None or kdfIters == 0
   - Use RawKey as-is if hashAlg is None or kdfIters == 0
- MacKey = PBKDF2 over EncKey once using same inputs as EncKey
- Encrypt data
- Compute HMAC(HEADER+SALT+IV+ENC+AD)
- Return RESULT(HEADER+AUTH+SALT+IV+ENC+AD)

Methods would be added to work with the following:
- Simple encrypted blobs (no header/auth/salt/iv/ad included)
- Creating and Verifying AE/AD MACs without headers
- Methods to read SecureD v1 encrypted data

Note that this plan is NOT compatible with the SecureD v1 encryption 
data layout and data would need to be re-encrypted.

3. Re-implement the OpenSSL Bindings

The Deimos/DUB bindings are ancient and do not support OpenSSL 1.1.x. We 
can re-implement the bindings taking care to only include the symbols we 
need.

4. Streams

I get asked about this, and, as much as I want to do this, it is not a 
simple topic. std.streams was removed and right now the only viable 
replacement is Vibe.D streams. But that means pulling in Vibe.D for a 
simple cryptography library. At this point that doesn't seem like the 
right idea. If someone is willing to step-up and do the work I'd be 
willing to look at it, but for now I want to wait on this, preferably 
for a standard/generic streams interface to be made available.

Please let know what you think! I am very interested to hear about what 
would make your life easier when working with SecureD an cryptography in 
general.

-- 
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;