Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

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?

share|improve this question
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. $\;\;\;\;$ –  Ricky Demer May 30 at 8:58
    
@RickyDemer, what's the advantage? –  otus May 30 at 9: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 at 9: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 at 9: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 at 9:49

2 Answers 2

up vote 4 down vote accepted

Let's see:

  • AES CTR + MAC: still good advice. His recommendation of 256-bit keys clashes with Schneier's (also 2009) recommendation of 128-bit due to the weaker key schedule with 256-bit keys. Neither choice is broken, however.

  • HMAC-SHA-256 as MAC: still good advice. SHA-3 is still not finalized.

  • 256-bit random UIDs: 256-bits isn't going to risk collisions, like ever.

  • PBKDF2 or scrypt: still good advice, although there's now a competition looking for a better hashing scheme.

  • RSAES-OAEP: I'm torn here. It's a secure choice for public key encryption, but like he says it's easy to get wrong. A good elliptic curve would be as secure, probably faster, and ECC keys are much smaller.

  • 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's bad advice even after five years.

The rest are not really about cryptography per se.

share|improve this answer
    
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 at 4:24
    
@MattNordhoff, I updated the answer to make that explicit. –  otus May 31 at 8: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 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 - owlstead Jun 3 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 3 at 16:11

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.)

share|improve this answer
    
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 7 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 7 at 19:20

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.