1
$\begingroup$

In this article: http://www.bsdcan.org/2010/schedule/attachments/135_crypto1hr.pdf

He has said:

  • AVOID: Poly1305. If your name is Daniel Bernstein, go ahead and use this Otherwise, you’re never going to produce a secure and correct implementation
  • DON’T: Use modes which provide both encryption and authentication
  • PROBABLY AVOID: Elliptic Curve signature schemes
$\endgroup$

closed as primarily opinion-based by fkraiem, e-sushi Feb 20 '17 at 17:25

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

3
$\begingroup$

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

$\endgroup$
3
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ The interesting part of the question is the somewhat over the top recommendation about Poly1305. It would be good to have even a speculative answer to that part. $\endgroup$ – otus Feb 19 '17 at 11:04
  • $\begingroup$ My speculation was that other implementations are easier - that is, easier to get right both functionally and from a side channel perspective. $\endgroup$ – Thomas M. DuBuisson Feb 19 '17 at 18:31

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