Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drivers and Supported Encryption Primitives #7

Open
paragonie-scott opened this issue Jan 5, 2016 · 8 comments
Open

Drivers and Supported Encryption Primitives #7

paragonie-scott opened this issue Jan 5, 2016 · 8 comments

Comments

@paragonie-scott
Copy link
Member

@paragonie-scott paragonie-scott commented Jan 5, 2016

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

This comment has been minimized.

Copy link

@riking riking commented Jan 5, 2016

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

This comment has been minimized.

Copy link
Member Author

@paragonie-scott paragonie-scott commented Jan 5, 2016

@CodesInChaos

This comment has been minimized.

Copy link

@CodesInChaos CodesInChaos commented Jan 5, 2016

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

@paragonie-scott

This comment has been minimized.

Copy link
Member Author

@paragonie-scott paragonie-scott commented Jan 5, 2016

Good point. I'm thinking:

  • Libsodium
    • KDF: Argon2, with the default parameters
  • OpenSSL
@CodesInChaos

This comment has been minimized.

Copy link

@CodesInChaos CodesInChaos commented Jan 5, 2016

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

This comment has been minimized.

Copy link
Member Author

@paragonie-scott paragonie-scott commented Jan 5, 2016

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

@paragonie-scott

This comment has been minimized.

Copy link
Member Author

@paragonie-scott paragonie-scott commented Jan 5, 2016

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

This comment has been minimized.

Copy link
Member Author

@paragonie-scott paragonie-scott commented Jan 8, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.