5

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?

e-sushi
  • 17,891
  • 12
  • 83
  • 229
David Carboni
  • 153
  • 5
  • 1
    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. $;;;;$ –  May 30 '14 at 08:58
  • @RickyDemer, what's the advantage? – otus May 30 '14 at 09:32
  • @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. – Henrick Hellström May 30 '14 at 09:35
  • @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. – otus May 30 '14 at 09:39
  • @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. – Henrick Hellström May 30 '14 at 09:49
  • @otus : $:$ Also, even though "revocations and trust chains are much more complicated than simply replacing the trusted key", they also provide more security "than simply replacing the trusted key", $\hspace{.28 in}$ since they make the "updates" usually not need any external authentication mechanism. $\hspace{1.07 in}$ –  May 30 '14 at 16:30
  • @RickyDemer: Then again, you need some authentication mechanism for actual software updates anyway, but yes I can see there are some advantages. Still, I wouldn't call the advice invalid (even if it isn't universally applicable) – especially if it lets you avoid linking in OpenSSL. – otus May 30 '14 at 17:47
  • @otus : $;;;$ You need that since you need some authentication essentially everywhere. $:$ The point is $\hspace{.41 in}$ to make as much of the authentication as possible (including "actual software updates") internal. $\hspace{.58 in}$ –  May 30 '14 at 18:06

3 Answers3

6

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.

otus
  • 32,132
  • 5
  • 70
  • 165
  • 1
    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. – Matt Nordhoff May 31 '14 at 04:24
  • @MattNordhoff, I updated the answer to make that explicit. – otus May 31 '14 at 08:43
  • 2
    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. – hunter May 31 '14 at 16:52
  • @hunter True, unless the improved security model of SHA-3 provides a significant advantage, e.g. for protection against length extension attacks. – Maarten Bodewes Jun 03 '14 at 14:52
  • 1
    @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. – otus Jun 03 '14 at 16:11
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.)

D.W.
  • 36,365
  • 13
  • 102
  • 187
  • 1
    Ironically, in the few days since this post serious bugs have been found in both OpenSSL and GnuTLS. Always a judgement call, but using (not inventing!) a simpler protocol is a valid alternative. – otus Jun 07 '14 at 12:47
  • @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? – D.W. Jun 07 '14 at 19:20
  • My solution is to use TLS with an application layer tunnel negotiated inside it. That way you get the best of both worlds. – Ella Rose Apr 17 '16 at 18:04
3

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

Nathan Kidd
  • 131
  • 2