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
In this article: http://www.bsdcan.org/2010/schedule/attachments/135_crypto1hr.pdf
He has said:
(Note: this answer is partly an analysis of Colin's Percival's writings, and partly my own opinion. I use indirect speech for Percival's recommendations and direct speech for mine.)
These recommendations are geared towards someone who will write the whole code, including the cryptographic primitives. Before these slides, Colin Percival wrote a blog post and another one on Encrypt-then-MAC where he gives some rationale. His main rationale in favor of CTR+HMAC rather than AEAD modes is that AEAD modes are harder to implement correctly, and are not used much so get less review and testing. Seven years later, that's less true: more and more protocols support AEAD modes and more and more libraries support them.
Given the existence of open-source, well-maintained libraries that provide cryptographic primitives, there is hardly ever any excuse to writing your own implementation of AES or GCM. So use a good implementation, and worry only about using correctly. Under the assumption that you aren't writing your own primitives, Percival's main argument breaks down, and I put forward that you should use AEAD everywhere, because a very common mistake in practice is not to authenticate everything, or to combine encryption and authentication incorrectly. Encrypt-then-MAC is good if you don't make rookie mistakes, but AEAD somewhat channels you into not making these mistakes.
Percival also raises the issue of side channel resistance, but I think he's being too optimistic with respect to the difficulty of performing timing attacks. There have been a lot of publications on timing attacks in the past few years, and attackers are getting better and better at weeding out the noise and detecting fine differences. An algorithm that hides timing weaknesses is not enough, you need to avoid them altogether. “DON’T: Write code which leaks information via how long it takes to run.” — that's definitely good advice, and hard to follow. For example, “Key-dependent or plaintext-dependent table lookups” which he classifies as “AVOID” should be upgraded to “DON'T”. As for “DO: Consult a cryptographer if you’re planning on releasing a CPU which leaks information in new and exciting ways”, that's rather obsolete advice: today all common platforms can be considered to leak information in exciting ways. Client-side code runs on multicore mobile phones, colocated with ads running in browsers and apps of dubious provenance. Server-side code runs in shared data centers, colocated with whoever else paid $5/month to run their own code. And if you need timing-invariant code, you'd better get as much as possible of it from a well-vetted cryptographic library.
His recommendation “PROBABLY AVOID: Elliptic Curve signature schemes” was also briefly explained in the original blog post and reiterated in a 2013 blog post. Here the sole argument given is simplicity of implementation, and here again I would rather recommend using a well-vetted library. RSA-PSS is fine, but if you have a reason to want smaller signatures or faster operations, then by all means use ECC (over a prime field).
Regarding Poly1305, the argument seems to be again the difficulty of implementing it correctly. Well, you can use djb's reference code — but once again what you should really do is use a cryptographic library that provides it. DJB crypto is less common than NIST crypto, so you might want to stick with NIST crypto for the more widespread library support, and for the more widespread marketing acceptance.
First off, it sounds like you already have an opinion and should talk to Colin directly.
My take is, at least at the time, he was very much in favor of tried-and-true (and easy, relatively) encrypt-then-mac schemes. Namely, he advocated CTR+HMAC. This is easy and known to be secure. You pay for it a little by deriving more key material than otherwise needed, by more expensive computations, and by more algorithms. None of those things matter to most users in most settings.
In 2010 Poly1305, related AE schemes, and EdDSA were less well-known, less well standardized (which often serves as an implementation aid), and less widely implemented than good old AES-CTR and SHA2-256 (and RSA). Again, these are me casting about to explain Colin P. when in fact you could just ask him if you so desire.
