Cryptography

See this site for the key length recommendations of various organizations.

RSA

• Use key sizes of at least 2048 bits, and 4096 bits for CAs or other security-critical use cases.
• Note that many hardware devices, such as TPMs, cannot store keys longer than 2048 bits.
• With TLS and OpenVPN, the key sizes affect the performance of only the negotiation handshake at the start of the connection and during renegotiation, which for OpenVPN happens once per hour.

Diffie-Hellman parameters

• At least 2048 bits. 1024 bit Diffie-Hellman can be cracked by nation states.
• Generate your own parameters whenever possible.

Elliptic Curve Diffie-Hellman (ECDH)

• See this list for safe curves, and this list for compatibility with TLS implementations.
• The NIST curves may contain NSA backdoors and are difficult to implement without vulnerabilities for side-channel attacks.
• Curve25519 (used in the X25519 Diffie-Hellmann key exchange)
  • A lot less prone to side-channel attacks than the NIST curves. Use this whenever you can.
  • Not supported by most browsers for certificates (as of 2023)
  • X25519 is supported by Firefox and Chrome
• prime256v1 = NIST P-256
  • Not as secure as the other options. Do not use this unless you have to for compatibility.
• secp384r1 = NIST P-384
  • The default for pfSense OpenVPN
  • Good compromise between security and performance
  • Compatible with most web browsers
  • If setting up an enterprise system with various clients, I’d go with this just to be sure about compatibility.
• secp521r1 = NIST P-521
  • Theoretically more secure than secp384r1, but not widely used. Chromium has dropped support for it, which is rather suspicious.
  • If setting up a highly secure system which has only a few users and where safe curves such as Curve25519 are not available, I’d go with this over secp384r1.

Hashing

• MS-CHAPv2
  • Based on NTLMv1 (not NTLMv2!) and is therefore broken and should not be used. Can be cracked in less than a day on modern hardware. However, its use is often necessary in e.g. Wi-Fi authentication for compatibility reasons. If using MS-CHAPv2 for e.g. Wi-Fi authentication, you must have proper certificate configuration! Otherwise, your clients are effectively broadcasting their passwords.
• NTLMv1
  • Totally broken and should not be used. Based on MD4 and DES. Susceptible to offline cracking, replay attacks and hash reuse.
• NTLMv2
  • Vulnerable and should not be used. Replaces the DES in NTLMv1 with HMAC-MD5 and includes timestamps, which helps with replay attacks and hash reuse. However, the algorithm is still weak for offline cracking.
• SHA-1
  • Broken and should not be used.
• SHA-256
  • Good enough,
• SHA-512
  • Theoretically more secure than SHA-256, but not worth it for online systems due to the longer hashes.
  • Windows 7 and 8 require an update to enable SHA512 for TLS 1.2