Table of contents

Links

• Percival, 2009 [visited 2019-07-03T21:40:34Z]
• Ptacek, 2015 [visited 2019-07-03T21:39:43Z]
• Latacora, 2018 [visited 2019-07-03T21:38:31Z]

Results (ordered as in the texts)

Encrypting Data

You care about this if: you’re hiding information from users or the network.

	Percival, 2009	Ptacek, 2015	Latacora, 2018
Do:	AES-CTR; append HMAC alternatively: AES-GCM	Nacl/libsodium default Chacha20-Poly1305 AES-GCM All of them: AEAD (authenticated encryption with associated data)	KMS XSalsa20+Poly1305
If you can get away with it:	-	-	AES-CTR + polynomial MAC as NMR (nonce-misuse resistance) schemes, MRAE (misuse-resistant AE (authenticated encryption)) schemes: GCM-SIV Deoxys-II
Avoid:	ECB mode padding and unpadding of partial blocks (ciphertext stealing (CTS)) CTR mode without HMAC	AES-CBC AES-CTR by itself (without HMAC) block ciphers with 64-bit blocks Blowfish (instance of the former) OFB mode RC4

You might ask why use “Encrypt-then-MAC”? Or more precisely: There exist three possible ways how one could combine encryption and MAC:

• Encrypt-and-MAC: The ciphertext is generated by encrypting the plaintext; a MAC of the plaintext is appended.
• MAC-then-encrypt: A MAC of the plaintext is appended to the plaintext and then this “elongated” text is encrypted.
• Encrypt-and-MAC: The ciphertext is generated by encrypting the plaintext; a MAC of the encrypted plaintext is appended.

Under Encrypt-then-MAC [published 2009-06-24; visited 2021-02-25T00:03:17Z], Colin Percival gives an explanation why Encrypt-then-MAC should be used.

Symmetric key length

You care about this if: you’re using cryptography.

	Percival, 2009	Ptacek, 2015	Latacora, 2018
Do:	256 bit
If you can get away with it:	128 bit	-	-
Avoid:	-	constructions with huge keys cipher “cascades” key sizes < 128 bit

Symmetric signatures

You care about this if: you’re securing an API, encrypting session cookies, or are encrypting user data but, against medical advice, not using an AEAD construction.

	Percival, 2009	Ptacek, 2015	Latacora, 2018
Do:	HMAC
Avoid:	custom constructions	custom “keyed hash” constructions HMAC-MD5 HMAC-SHA1 complex polynomial MACs encrypted hashes CRC

Hashing/HMAC algorithm

You care about this if: you always care about this.

	Percival, 2009	Ptacek, 2015	Latacora, 2018
Do:	SHA-256 (SHA-2) SHA-512 (SHA-2) [mentioned implictly]	SHA-2
If you can get away with it:	-	SHA-512/256
Future prospect:	Plan update to SHA-3 within next 5-10 years	-	-
Avoid:	SHA-1 [mentioned implcitly] MD5 [mentioned implcitly]	SHA-1 MD5 MD6

Random IDs

You care about this if: you always care about this.

	Percival, 2009	Ptacek, 2015	Latacora, 2018
Do:	Use 256-bit random numbers.	Use 256-bit random numbers from /dev/urandom.
If you can get away with it:	Use 128-bit random numbers.	-	-
Avoid:	-	userspace random number generators   havaged prngd egd /dev/random	userspace random number generators the OpenSSL RNG havaged prngd egd /dev/random

Password handling

You care about this if: you accept passwords from users or, anywhere in your system, have human-intelligible secret keys.

	Percival, 2009	Ptacek, 2015	Latacora, 2018
Do:	scrypt     PBKDF2 erase the plaintext password from memory.	scrypt   bcrypt PBKDF2	scrypt Argon2 bcrypt PBKDF2
Avoid:	store users' passwords MD5	don't use password hashes at all SHA-2 SHA-1 MD5	not using a real secure password hash build elaborate password-hash-agility scheme SHA-3 SHA-2 SHA-1 MD5

Links:

• Argon2
• bcrypt
• PBKDF2
• scrypt

Asymmetric encryption

You care about this if: you need to encrypt the same kind of message to many different people, some of them strangers, and they need to be able to accept the message asynchronously, like it was store-and-forward email, and then decrypt it offline. It’s a pretty narrow use case.

	Percival, 2009	Ptacek, 2015	Latacora, 2018
Do:	RSAES-OAEP with hash function: SHA-256 mask generation function: MGF1+SHA256 public exponent: 65537 = 216 + 1	NaCl	Nacl/libsodium (box / crypto_box)
If you can get away with it:	-	RSA-OAEP if you have to use RSA	-
Avoid:	PKCS #1 v1.5	PKCS #1 v1.5 RSA ElGamal Merkle-Hellman knapsacks	Systems designed after 2015 that use PKCS #1 v1.5 RSA ElGamal Merkle-Hellman knapsacks

Asymmetric signatures

You care about this if: you’re designing a new cryptocurrency. Or, a system to sign Ruby Gems or Vagrant images, or a DRM scheme, where the authenticity of a series of files arriving at random times needs to be checked offline against the same secret key. Or, you’re designing an encrypted message transport.

	Percival, 2009	Ptacek, 2015	Latacora, 2018
Do:	RSASSA-PSS with hash function: SHA-256 mask generation function: MGF1+SHA256 public exponent: 65537 = 216 + 1	TODO	TODO
Avoid:	TODO	TODO	TODO

Diffie-Hellman

You care about this if: you’re designing an encrypted transport or messaging system that will be used someday by a stranger, and so static AES keys won’t work.

	Percival, 2009	Ptacek, 2015	Latacora, 2018
Do:	TODO	TODO	TODO
Avoid:	TODO	TODO	TODO

Website security

You care about this if: you have a website.

	Percival, 2009	Ptacek, 2015	Latacora, 2018
Do:	TODO	TODO	TODO
Avoid:	TODO	TODO	TODO

Client-server application security

You care about this if: the previous recommendations about public-key crypto were relevant to you.

	Percival, 2009	Ptacek, 2015	Latacora, 2018
Do:	TODO	TODO	TODO
Avoid:	TODO	TODO	TODO

Online backups

You care about this if: you bother backing things up.

	Percival, 2009	Ptacek, 2015	Latacora, 2018
Do:	Tarsnap

Results (ordered by agreement)

TODO