Key Exchange/Hybrid Encryption

「 Overview 」




Recommended 「 In Order 」

Curve25519 / X25519

Curve448 / X448

Pre-shared Symmetric Keys

This approach allows for post-quantum security and can
be combined alongside an asymmetric key exchange.

However, using pre-shared keys can be difficult since the key must be kept secret,
whereas public keys are meant to be public and can therefore be easily shared.




Avoid 「 Unordered | All Unsuitable 」


RSA ( Plain | PKCS#1 v1.5 | KEM | OAEP )

ElGamal

NIST Curves ( P-256 | P-384 | P512 )

Although P-256 is probably the most popular curve, the seeds for these curves
haven’t been explained, which is not a good look considering that Dual EC DRBG
was a NIST standard despite containing an NSA Backdoor .


Furthermore, these curves:


These should only be used for interoperability reasons.

Other Curves

Such as Curve41417

These are often rarely used/available compared
to Curve25519 / X25519, P-256, P-384, and P-512.

Please see the SafeCurves tables for a security comparison of most curves.

〔 SRP 〕 〔 J-PAKE 〕 〔 PAKE 〕

Note that these are only for password-based authenticated key exchange.

SRP has an Odd Design , no security proof, leaks the salt to untrusted users, requires
more bandwidth and computation than ECDH , and old versions contained vulnerabilities.

Some PAKEs require the user to store the password on the server or
reveal the salt to an attacker, allowing for Pre Computation Attack .

Furthermore, very few cryptographic libraries include PAKEs, which makes good
ones, like OPAQUE , difficult to recommend until they receive more adoption.

Post Quantum Algorithms

However, it will eventually make sense to switch to one in the future.

For now, if post-quantum security is a goal, then use a pre-shared symmetric key if possible.




Notes


「 1 」

Handling of different keys

Public: Should be shared
Private: Must be kept secret

↳ Check point 9 for details about secure storage of private keys

「 2 」

Never hard-code private keys into source code

These can be easily retrieved.

「 3 」

Hybrid Encryption Algorithms

Make use of the recommended Symmetric Encryption Algorithms
when using one of the recommended Hybrid Encryption algorithms

For example: X25519 + ChaCha20-Poly1305

「 4 」

Shared Secret KDFs

Use one of the recommended Non-Password Based KDFs on the shared secret.

Shared secrets are not suitable for use as secret keys directly
because they aren’t uniformly random.

Moreover, you should derive unique keys each time by using the salt
and context parameters, as explained in Key Derivation Functions.

「 5 」

When using counter nonces for encryption, use different
keys for different directions in a Client ⬌ Server scenario

After computing the shared secret,
you can use a non-password based KDF
to derive two 256-bit keys as follows:

HKDF-SHA512 (
    Info : Client Public Key | Server Public Key
    Input Keying Material : Shared Secret
    Output Length : 64
    Salt : null
)

Splitting the output in two.

One key should be used by the client for sending data to the server, and
the other should be used by the server for sending data to the client.

Both keys need to be calculated by the client and server.

This approach allows counter nonces to be used safely for encryption
without having to wait for an acknowledgment after every message.

「 6 」

X25519 and X448 public keys can be distinguished from random data

If you need to obfuscate public keys so that they’re indistinguishable
from random noise, then you need to use Elligator 2 .

Note that other metadata (the number of bytes in a packet)
can reveal the use of cryptography too, so you should consider
padding such information using a scheme like PADME.

「 7 」

Use an authenticated key exchange in most non-interactive / offline protocols

The Noise protocol framework K and X one-way handshake Patterns ,
as explained here, are perfect for non-interactive / offline protocols.

These achieve sender and recipient authentication whilst preventing a compromise
of the sender’s private key leading to an attacker being able to decrypt the ciphertext.

「 8 」

Opt for forward secrecy when possible in interactive / online protocols

This prevents a compromise of a long-term private key leading to a compromise
of a session key, which is the strongest security guarantee you can achieve.

This can be implemented using the Noise KK or IK interactive handshakes.

「 9 」

Store Private Keys Encrypted

When storing a private key in a file, you should always
encrypt it with a strong password for protection at rest.

Things become more complicated for interactive/online scenarios,
with physical or virtual hardware security modules (HSMs) and key
vaults, such as AWS Key Management Service (KMS),
sometimes being used.

These types of solutions are generally regarded as more secure than storing keys in encrypted configuration files and allow for easy key rotation, but using a KMS requires trusting a third party.

「 10 」

Key Pairs Should Be Rotated

If a private key has or may have been compromised, then a new key pair should be generated.

Similarly, you should consider rotating your keys
after a set period of time (a cryptoperiod) has elapsed.



「 Overview 」