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;
