Drivers and Supported Encryption Primitives

[paragonie-scott]

We should restrict which primitives can be used with each driver.

A proposed rough draft is below; this only affects the permitted primitives in the initial version of the library. All messages are version tagged.

• Libsodium
  • Asymmetric key exchange: X25519 (crypto_kx())
  • Asymmetric signatures: Ed25519 (crypto_sign())
  • Asymmetric encryption: Key exchange then symmetric encryption (crypto_box())
  • Symmetric encryption: Xsalsa20-Poly1305 (crypto_secretbox())
  • Symmetric authentication: HMAC-SHA512/256 (crypto_auth())
  • AEAD: ChaCh20Poly1305 (crypto_aead_chacha20poly1305_*())
  • Key splitting: HKDF-BLAKE2b
  • Key derivation (from passwords): Argon2 (crypto_pwhash_*())
• OpenSSL
  • Asymmetric key exchange:
  • 2048-bit Diffie Hellman over Group 14 (openssl_dh_compute_key())
  • 256-bit ECDH over NIST P-256
  • Asymmetric signatures:
  • 2048-bit RSASSA-PSS with SHA256 + MGF1+SHA256, e = 65537
  • 256-bit ECDSA over NIST P-256
  • Asymmetric encryption (not sure which would be better):
  • 2048-bit RSAES-OAEP with SHA256 + MGF1+SHA256, e = 65537
  • Diffie Hellman then symmetric encryption
  • Symmetric encryption: AES-CTR + HMAC-SHA2
  • Symmetric authentication: HMAC-SHA2
  • AEAD: AES-GCM
  • Key splitting: HKDF-HMAC-SHA-2
  • Key derivation (from passwords): PBKDF2-SHA2 with 86000 iterations

[riking]

What is the interface for libsodium keygen and key loading/storage?

In my Golang program I store my libsodium keys as base64 in a .json config file as MyPrivate MyPublic TheirPublic, to provide a data point.

[paragonie-scott]

My own libsodium project does this: https://github.com/paragonie/halite/blob/master/src/KeyFactory.php#L412-L425

[CodesInChaos]

I don't see a KDF. Key exchange is pretty useless without a way for deriving symmetric keys from the shared secret.

[paragonie-scott]

Good point. I'm thinking:

• Libsodium
  • KDF: Argon2, with the default parameters
• OpenSSL
  • PBKDF2-SHA256 with 86,000 rounds (as per this NCC article)

[CodesInChaos]

I was mainly thinking about a key based KDF, namely HKDF-HMAC-SHA-2. I consider it an essential tool when designing not trivial crypto.

[paragonie-scott]

Oh yeah, I was going to use HKDF to split keys anyway. Let me make a quick edit to the original.

[paragonie-scott]

Updated the OP to remove CBC mode, add a line item for AEAD under OpenSSL, and spell out the different KDF methods that will be used.

Key splitting will generally be HKDF with a 256-bit salt (stored with the IV/nonce in the ciphertext, covered by the MAC).

[paragonie-scott]

Removing "2048-bit RSAES-OAEP with SHA256 + MGF1+SHA256, e = 65537" from the list in favor of DH-2048 then AES-CTR+HMAC-SHA2.

Reason: API simplicity. Libsodium uses X25519 then Xsalsa20+Poly1305, which is all of: sane, secure, simple, and easy to reason about.

Using RSA encryption means we'd have to use RSA keys in some instances as diffie hellman keys to keep a compatible interface. This is probably a bad idea. Also, RSA encryption means either forcing ECB mode or reinventing CBC mode, but certainly incurring massive performance penalties.

So, we'll still use RSA (or ECDSA, if openssl supports that) for signing, but encryption will just be DH+AES+HMAC.