Crypto Best Practices

crypto

Symmetric Encryption

The only way to encrypt today is authenticated encryption, or "AEAD".
ChaCha20-Poly1305 is faster in software than AES-GCM. AES-GCM will be faster
than ChaCha20-Poly1305 with AES-NI. Poly1305 is also easier than GCM for library
designers to implement safely. AES-GCM is the industry standard.

Use, in order of preference:

1. The NaCl/libsodium default
2. Chacha20-Poly1305
3. AES-GCM

Avoid:

1. AES-CBC, AES-CTR by itself
2. Block ciphers with 64-bit blocks such as Blowfish
3. OFB mode
4. RC4, which is comically broken

Symmetric Key Length

See The Physics of Brute
Force to understand
why 256-bit keys is more than sufficient. But rememeber: your AES key is far
less likely to be broken than your public key pair, so the latter key size
should be larger if you're going to obsess about this.

Use:

1. Minimum- 128-bit keys
2. Maximum- 256-bit keys

Avoid:

1. Constructions with huge keys
2. Cipher "cascades"
3. Key sizes under 128 bits

Symmetric Signatures

If you're authenticating but not encrypting, as with API requests, don't do
anything complicated. There is a class of crypto implementation bugs that arises
from how you feed data to your MAC, so, if you're designing a new system from
scratch, Google "crypto canonicalization bugs". Also, use a secure compare
function.

Use: HMAC

Avoid:

1. HMAC-MD5
2. HMAC-SHA1
3. Custom "keyed hash" constructions
4. Complex polynomial MACs
5. Encrypted hashes
6. Anything CRC

Hashing/HMAC Algorithm

If you can get away with it you want to use hashing algorithms that truncate
their output and sidesteps length extension attacks. Meanwhile: it's less likely
that you'll upgrade from SHA-2 to SHA-3 than it is that you'll upgrade from
SHA-2 to BLAKE2, which is faster than SHA-3, and SHA-2 looks great right now, so
get comfortable and cuddly with SHA-2.

Use, in order of preference:

1. HMAC-SHA-512/256
2. HMAC-SHA-512/224
3. HMAC-SHA-384
4. HMAC-SHA-224
5. HMAC-SHA-512
6. HMAC-SHA-256

Alternately, use in order of preference:

1. BLAKE2
2. SHA3-512
3. SHA3-256

Avoid:

1. HMAC-SHA-1
2. HMAC-MD5
3. MD6
4. EDON-R

Random IDs

When creating random IDs, numbers, URLs, nonces, initialization vectors, or
anything that is random, then you should always use
/dev/urandom.

Use: /dev/urandom

Create: 256-bit random numbers

Avoid:

1. Userspace random number generators
2. /dev/random

Password Hashing

When using scrypt for password hashing, be aware that It is very sensitive to
the
parameters,
making it possible to end up weaker than bcrypt, and suffers from time-memory
trade-off (source #1 and
source #2). When using
bcrypt, make sure to use the following algorithm to prevent the leading NULL
byte
problem
and the 72-character password limit:

bcrypt(base64(sha-512(password)))

I'd wait a few years, until 2020 or so, before implementing any of the Password
Hashing Competition candidates, such as Argon2.
They just haven't had the time to mature yet.

Use, in order of preference:

1. scrypt
2. bcrypt
3. sha512crypt
4. sha256crypt
5. PBKDF2

Avoid:

1. Plaintext
2. Naked SHA-2, SHA-1, MD5
3. Complex homebrew algorithms
4. Any encryption algorithm

Asymmetric Encryption

It's time to stop using vanilla RSA, and start using NaCl/libsodium. Of all the
cryptographic "best practices", this is the one you're least likely to get
right on your own. NaCl/libsodium has been designed to prevent you from making
stupid mistakes, it's highly favored among the cryptographic community, and
focuses on modern, highly secure cryptographic primitives.

It's time to start using ECC. Here are several reasons you should stop using
RSA and switch to elliptic curve software:

• Progress in attacking RSA --- really, all the classic multiplicative group
  primitives, including DH and DSA and presumably ElGamal --- is proceeding
  faster than progress against elliptic curve.
• RSA (and DH) drag you towards "backwards compatibility" (ie: downgrade-attack
  compatibility) with insecure systems. Elliptic curve schemes generally don't
  need to be vigilant about accidentally accepting 768-bit parameters.
• RSA begs implementors to encrypt directly with its public key primitive,
  which is usually not what you want to do: not only does accidentally
  designing with RSA encryption usually forfeit forward-secrecy, but it also
  exposes you to new classes of implementation bugs. Elliptic curve systems
  don't promote this particular foot-gun.
• The weight of correctness/safety in elliptic curve systems falls primarily on
  cryptographers, who must provide a set of curve parameters optimized for
  security at a particular performance level; once that happens, there aren't
  many knobs for implementors to turn that can subvert security. The opposite
  is true in RSA. Even if you use RSA-OAEP, there are additional parameters to
  supply and things you have to know to get right.

If you have to use RSA, do use RSA-OAEP. But don't use RSA. Use ECC.

Use: NaCl/libsodium

Avoid:

1. RSA-PKCS1v15
2. RSAES-OAEP
3. RSASSA-PSS with MGFI-256,
4. Really, anything RSA
5. ElGamal
6. OpenPGP, OpenSSL, BouncyCastle, etc.

Asymmetric Key Length

As with symmetric encryption, asymmetric encryption key length is a vital
security parameter. Academic, private, and government organizations provide
different recommendations with mathematical formulas to approimate the minimum
key size requirement for security. See BlueKcrypt's Cryptographyc Key Length
Recommendation for other recommendations and dates.

To protect data up through 2020, it is recommended to meet the minimum
requirements for asymmetric key lengths:

See also the NSA Fact Sheet Suite B
Cryptography
and RFC 3766 for additional
recommendations and math algorithms for calculating strengths based on calendar
year.

Personally, I don't see any problem with using 2048-bit RSA/DH group and 256-bit
ECC/DH key lengths. So, my recommendation would be:

Use:

1. 256-bit minimum for ECC/DH Keys
2. 2048-bit minimum for RSA/DH Group

Avoid: Not following the above recommendations.

Asymmetric Signatures

In the last few years there has been a major shift away from conventional DSA
signatures and towards misuse-resistent "deterministic" signature schemes, of
which EdDSA and RFC6979 are the best examples. You can think of these schemes
as "user-proofed" responses to the Playstation 3 ECDSA flaw, in which reuse of
a random number leaked secret keys. Use deterministic signatures in preference
to any other signature scheme.

Use, in order of preference:

1. NaCl/libsodium
2. Ed25519
3. RFC6979 (deterministic DSA/ECDSA)

Avoid:

1. RSA-PKCS1v15
2. RSASSA-PSS with MGF1+SHA256
3. Really, anything RSA
4. Vanilla ECDSA
5. Vanilla DSA

Diffie-Hellman

This is the trickiest one. Here is roughly the set of considerations:

• If you can just use Nacl, use Nacl. You don't even have to care what Nacl
  does.
• If you can use a very trustworthy library, use Curve25519; it's the modern
  ECDH curve with the best software support and the most analysis. People
  really beat the crap out of Curve25519 when they tried to get it standardized
  for TLS. There are stronger curves, but none supported as well as Curve25519.
• But don't implement Curve25519 yourself or port the C code for it.
• If you can't use a very trustworthy library for ECDH but can for DH, use
  DH-2048 with a standard 2048 bit group, like Colin says, but only if you can
  hardcode the DH parameters.
• But don't use conventional DH if you need to negotiate parameters or
  interoperate with other implementations.
• If you have to do handshake negotiation or interoperate with older software,
  consider using NIST P-256, which has very widespread software support.
  Hardcoded-param DH-2048 is safer than NIST P-256, but NIST P-256 is safer
  than negotiated DH. But only if you have very trustworthy library support,
  because NIST P-256 has some pitfalls. P-256 is probably the safest of the
  NIST curves; don't go down to -224. Isn't crypto fun?
• If your threat model is criminals, prefer DH-1024 to sketchy curve libraries.
  If your threat model is governments, prefer sketchy curve libraries to
  DH-1024. But come on, find a way to one of the previous recommendations.

It sucks that DH (really, "key agreement") is such an important crypto building
block, but it is.

Use, in order of preference:

1. NaCl/libsodium
2. 2048-bit Diffie-Hellman Group #14

Avoid:

1. conventional DH
2. SRP
3. J-PAKE
4. Handshakes and negotiation
5. Elaborate key negotiation schemes that only use block ciphers
6. srand(time())

Website security

By "website security", we mean "the library you use to make your web server
speak HTTPS". Believe it or not, OpenSSL is still probably the right decision
here, if you can't just delegate this to Amazon and use HTTPS elastic load
balancers, which makes this their problem not yours.

Use:

• OpenSSL, LibreSSL, or BoringSSL if you run your own site
• Amazon AWS Elastic Load Balancing if Amazon does

Avoid:

1. PolarSSL
2. GnuTLS
3. MatrixSSL

Client-server application security

What happens when you design your own custom RSA protocol is that 1-18 months
afterwards, hopefully sooner but often later, you discover that you made a
mistake and your protocol had virtually no security. A good example is Salt
Stack. Salt managed to deploy e=1 RSA.

It seems a little crazy to recommend TLS given its recent history:

• The Logjam DH negotiation attack
• The FREAK export cipher attack
• The POODLE CBC oracle attack
• The RC4 fiasco
• The CRIME compression attack
• The Lucky13 CBC padding oracle timing attack
• The BEAST CBC chained IV attack
• Heartbleed
• Renegotiation
• Triple Handshakes
• Compromised CAs

Here's why you should still use TLS for your custom transport problem:

• Many of these attacks only work against browsers, because they rely on the
  victim accepting and executing attacker-controlled Javascript in order to
  generate repeated known/chosen plaintexts.
• Most of these attacks can be mitigated by hardcoding TLS 1.2+, ECDHE and
  AES-GCM. That sounds tricky, and it is, but it's less tricky than designing
  your own transport protocol with ECDHE and AES-GCM!
• In a custom transport scenario, you don't need to depend on CAs: you can
  self-sign a certificate and ship it with your code, just like Colin suggests
  you do with RSA keys.

Use: TLS

Avoid:

1. Designing your own encrypted transport, which is a genuinely hard
   engineering problem;
2. Using TLS but in a default configuration, like, with "curl"
3. Using "curl"
4. IPSEC

Online backups

Of course, you should host your own backups in house. The best security is the
security where others just don't get access to your data. There are many tools
to do this, all of which should be using OpenSSH or TLS for the transport. If
using an online backup service, use Tarsnap. It's withstood the test of time.

Use: Tarsnap

Avoid:

1. Google
2. Apple
3. Microsoft
4. Dropbox
5. Amazon S3