I'm a big fan of Colin Percival's "Cryptographic Right Answers" post.
This was written in 2009, which is a long time ago in Internet years.
Is the advice still valid or, if not, can someone point me to more up-to-date information?
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It only takes a minute to sign up.Sign up to join this community
For the clearly cryptographic recommendations:
AES CTR + MAC: still good advice, though AES-GCM is a good alternative. His recommendation of 256-bit keys clashes with Schneier's (also 2009) recommendation of 128-bit due to the weaker 256-bit key schedule. Neither choice is broken, however.
HMAC-SHA-256 as MAC: still good advice. While SHA-3 has been published, it has not yet seen as much use and SHA-2 remains unbroken.
256-bit random UIDs: 256-bits is not going to risk collisions, like ever.
PBKDF2 or scrypt: still fine. Although PHC chose Argon2 as a possible successor, it does not have much uptake yet.
RSAES-OAEP: I am torn here. It is a secure choice for public key encryption, but like he says it is easy to get wrong. A good elliptic curve would be as secure, faster, and ECC keys are much smaller. Not bad advice.
RSASSA-PSS: unlike the above, this is fairly simple. However, signature size is also large compared to ECC. Secure, but not always the Right Answer, as he says.
Diffie-Hellman on group #14. Still good advice.
So none of it is bad advice even after seven years.
By and large, his advice remains good.
I spotted only two recommendations where I would have a slightly different recommendation:
I disagree with his advice about client-server application security. My recommendation would be to use TLS, and just use it properly. I understand his concerns (it is complex), but my experience is that when developer build their own protocol for client-server application security, they tend to introduce security problems -- and my sense is that the frequency of that kind of failure mode is higher than the frequency with which serious bugs are found in SSL code.
For encrypting data, today I would recommend using authenticated encryption (e.g., AES-GCM or EAX or a similar scheme), because it's slightly easier to use -- but there's nothing wrong with his suggestion of Encrypt-then-MAC using AES-CTR and SHA256-HMAC.
(His argument against using authenticated encryption schemes is that they are new, complicated, and rarely-used. That might have been valid in 2009, but I don't think it's as valid or persuasive today. So that's one spot where my advice would differ from his article.)