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?
$\begingroup$
$\endgroup$
8
-
1$\begingroup$ His advice for Client-server application security is not valid. $\:$ One should instead distribute the signature verification key for one's own offline certificate authority with the client code, and not trust any other certificate authority as a root. $\;\;\;\;$ $\endgroup$– user991May 30, 2014 at 8:58
-
$\begingroup$ @RickyDemer, what's the advantage? $\endgroup$– otusMay 30, 2014 at 9:32
-
$\begingroup$ @otus: In order to avoid having to replace all client software due to private key compromise, the client software should include the public key corresponding to the private key that stands the least risk of becoming compromised. $\endgroup$– Henrick HellströmMay 30, 2014 at 9:35
-
$\begingroup$ @HenrickHellström, but until you update the clients with a revocation list they aren't going to know that the compromised key should no longer be trusted. So you need to distribute updates, somehow, anyway and revocations and trust chains are much more complicated than simply replacing the trusted key. $\endgroup$– otusMay 30, 2014 at 9:39
-
$\begingroup$ @otus: true, using a CA provides no advantage in case you know the server private key is compromised. However, an educated guess is that most of the time a private key is compromised the owner is blissfully unaware of the situation, which is why certificates are normally set to expire. Expiration requires a CA, in order to be handled transparently by the client software. $\endgroup$– Henrick HellströmMay 30, 2014 at 9:49
|
Show 3 more comments
3 Answers
$\begingroup$
$\endgroup$
5
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.
-
1$\begingroup$ To clarify: AES-CTR authenticated with HMAC-SHA256 using Encrypt-then-MAC is still a Good Idea. (AEADs like AES-GCM or AES-OCB are also a Good Idea. As Percival wrote then, it was and still is complicated and debatable, and the field is still evolving. You have to be different kinds of careful in every case.) Unauthenticated AES-CTR -- or unauthenticated anything else -- is always an awful idea. $\endgroup$ May 31, 2014 at 4:24
-
$\begingroup$ @MattNordhoff, I updated the answer to make that explicit. $\endgroup$– otusMay 31, 2014 at 8:43
-
2$\begingroup$ Even if SHA-3 were finalized, I still wouldn't recommend switching to it. SHA-2 has seen far more analysis and is still going strong today. $\endgroup$– hunterMay 31, 2014 at 16:52
-
$\begingroup$ @hunter True, unless the improved security model of SHA-3 provides a significant advantage, e.g. for protection against length extension attacks. $\endgroup$– Maarten Bodewes ♦Jun 3, 2014 at 14:52
-
1$\begingroup$ @owlstead, even then the choice is between HMAC-SHA-2 vs. SHA-3. The latter is probably faster with short messages, but that's it. $\endgroup$– otusJun 3, 2014 at 16:11
$\begingroup$
$\endgroup$
3
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.)
-
1
-
$\begingroup$ @otus, absolutely! You make a very timely and accurate point. The challenge is to find a simpler protocol that one can recommend to developers to provide a secure channel. I'm not aware of one; but maybe you have some suggestions? $\endgroup$– D.W.Jun 7, 2014 at 19:20
-
$\begingroup$ My solution is to use TLS with an application layer tunnel negotiated inside it. That way you get the best of both worlds. $\endgroup$ Apr 17, 2016 at 18:04
$\begingroup$
$\endgroup$
In 2015 and later 2018 this list was updated by industry-respected practitioners: https://web.archive.org/web/20211203145011/https://latacora.micro.blog/2018/04/03/cryptographic-right-answers.html
There are minor updates from the 2009 version.
They discussed the 2018 recommendations here https://news.ycombinator.com/item?id=16748400
