I disagree with two big points in this talk, but I'm sorry to say they're the same two things I disagreed with last time, so this is going to be a boring comment. First, dedicated AEAD cipher modes are superior to manually composing AES-CTR and HMAC-SHAx. AEAD modes provide both authentication and encryption in a single construction. AES-CTR+HMAC-SHAx involves joining two constructions to do the same thing. Colin poi…
You are entitled to your opinions, no matter how wrong they are. ;-)
Everything you need to know about cryptography in 1 hour (2010) [pdf]
61–70 of 104 posts
Re: Everything you need to know about cryptography in 1 hour (2010) [pdf]
#62Earlier quoted context omitted.
"And I still maintain that recommendation. CTR+HMAC is far more robust against side channel attacks than any AE mode." -- https://twitter.com/cperciva/status/475360367191674881
I think Colin has a hard row to hoe with this argument, given how often HMAC implementations cough up timing vulnerabilities. Even if you're stuck with GCM, GCM has the advantage of having mercifully few implementations. Everyone writes their own HMAC verifiers (badly).
Re: Everything you need to know about cryptography in 1 hour (2010) [pdf]
#63Earlier quoted context omitted.
You are entitled to your opinions, no matter how wrong they are. ;-)
This lets me down a little bit. If two guys that I consider to be very knowledgeable on this topic disagree on some key things, how am I supposed to get most of this right?
Re: Everything you need to know about cryptography in 1 hour (2010) [pdf]
#64Earlier quoted context omitted.
You are entitled to your opinions, no matter how wrong they are. ;-)
This lets me down a little bit. If two guys that I consider to be very knowledgeable on this topic disagree on some key things, how am I supposed to get most of this right?
Re: Everything you need to know about cryptography in 1 hour (2010) [pdf]
#65Would be interested in hearing more detail about your objections to both Poly1305 and ECC.
Too many ways to screw things up, not enough decades of cryptographic analysis, and there are simpler tools available which have been around for longer. This is subject to the caveat that ECC offers benefits under certain specific conditions (e.g., you need small signatures or a small ASIC die area); but in those situations you want to talk to a cryptographer anyway. My talk was providing guidelines for software deve…
Re: Everything you need to know about cryptography in 1 hour (2010) [pdf]
#66Earlier quoted context omitted.
This lets me down a little bit. If two guys that I consider to be very knowledgeable on this topic disagree on some key things, how am I supposed to get most of this right?
I am not as knowledgeable on these topics as Colin. But in this weird specific set of cases, I think my take is also closer to the conventional wisdom among cryptographic engineers; if you got a panel of them to stand in for me, I think their comment would sound close to mine.
Re: Everything you need to know about cryptography in 1 hour (2010) [pdf]
#67Earlier quoted context omitted.
You are entitled to your opinions, no matter how wrong they are. ;-)
This lets me down a little bit. If two guys that I consider to be very knowledgeable on this topic disagree on some key things, how am I supposed to get most of this right?
Both CTR+HMAC and combined AEAD modes, correctly implemented and correctly used, will keep you safe against existing published attacks. Thomas takes the view that "correctly implemented and correctly used" is a problem, and I'll accept that he's right to recommend AEAD modes in that case (as long as you have a good cryptographic library[1] available to you).
I take the view that if you can't take CTR and HMAC and put them together correctly, there's no way the rest of your code is ever going to be secure, so you've already lost; so I focus on the "against existing published attacks" side of things, look at the places where novel cryptographic attacks tend to be found, and opt for combining two very simple and well-understood constructions.
The same story plays out for RSA vs. ECC: Thomas is worried about the fact that people have made dumb mistakes when using RSA, while I figure that if you're going to make those dumb mistakes (especially after my talk) you're going to write code which is otherwise insecure anyway, so I focus on the places where I think it is more likely that attacks will be found in the future[2].
If you're a high school student with two years of Python experience and you want to add some cryptography to your cat photo sharing startup, listen to Thomas. If you're a senior developer with 20 years of experience writing C code for internet-facing daemons, and the code you write is going to be used by democracy activists in China, listen to me.
[1] I'm not convinced that such a thing exists right now. [2] Or, alternatively, where attacks may have already been found, but not published.
Re: Everything you need to know about cryptography in 1 hour (2010) [pdf]
#68He doesn't know how to write even simple mathematics. E.g., he uses symbols n and k without definition. Without careful definitions right there in the context, such symbols mean nothing. He is not clear enough about what he means by x . His lack of precision in his writing lowers confidence in the quality of what he has written.
He doesn't know how to write even simple mathematics. Umm...
Re: Everything you need to know about cryptography in 1 hour (2010) [pdf]
#69On the other hand, why is the author using "i++" in a preamble of a for loop?
Re: Everything you need to know about cryptography in 1 hour (2010) [pdf]
#70Earlier quoted context omitted.
I am not as knowledgeable on these topics as Colin. But in this weird specific set of cases, I think my take is also closer to the conventional wisdom among cryptographic engineers; if you got a panel of them to stand in for me, I think their comment would sound close to mine.
I think you're right about me being in a minority here. I also think there's an unfortunate amount of neophilia in the cryptographic community, partly because you don't get publications by not doing anything new.
Elliptic curves were proposed, and have since been studied in the context of cryptography, in 1985. They're 30 years old! For comparison, finite field discrete-log Diffie-Hellman is 38 years old, and RSA is 37. The latter have been severely beaten down in the ensuing decades that followed, whereas elliptic curves have stayed (modulo special cases, but those also exist for DH/RSA) resistant to every non-generic attack so far. I would say ECC has a better track record, and could be considered the conservative choice.
It could be argued that the underlying problem, integer factorization and FF discrete log, has been studied for much longer than the ECDLP. Maybe. Some basic algorithms go centuries back, but I would argue that the field has only seen real progress starting in the mid-1970s, with CFRAC and Pollard's algorithms. It can be counter-argued that elliptic curves as a subject have only existed for around 100 years, so they are still underdeveloped. Again, maybe.
There is indeed a new wave of interest in elliptic curves, and it is still fueling many publications every year. But these are mostly performance engineering at this point: Edwards curves are not fundamentally different from what Miller proposed in 1985, as far as the ECDLP is concerned. I would not recommend the wonkier stuff like GLS/GLV curves, though, nor curves over extension fields or of higher genus: that would be too neophiliac, even for me.
(I realize that I'm not gonna change your (or probably anyone's) mind, but you make it sound like elliptic curves are much more of a novelty than they really are. I don't disagree too much about the AEAD vs CTR+HMAC issue.)