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 points to AES-GCM, the most popular AEAD mode, as an example of how AEAD modes can be more susceptible to side-channel attacks than AES-CTR+HMAC-SHAx. I don't think this is a strong argument for a couple reasons:
* AES-GCM is so far as I can tell no practical cryptographer's preferred AEAD mode; "whipping boy" might be a better role to ascribe to it.
* AES-GCM's side-channel issues are due principally to a hardware support concern (GMAC, AES-GCM's answer to HMAC, requires modular binary polynomial multiplication, which in pure software is table-driven, which creates a cache timing channel). That hardware support concern might be receding, and platforms that don't have AES-GCM might prefer a different AEAD mode anyways.
* Modern AEAD modes, of the sort being entered into CAESAR, have resilience against side channels as a design goal.
* But the most important rejoinder to Colin's preference for HMAC-SHAx over AEAD modes is this: HMAC-SHAx is responsible for more side-channel flaws than any other construction. Practically every piece of software that has implemented HMAC-SHAx has managed to introduce the obvious timing channel in comparing the candidate to the true MAC for a message. What's worse is, using AES-CTR+HMAC-SHAx in practice means that the developer has to code the HMAC validation themselves; it's practically an engraved invitation to introduce a new timing leak. Almost nobody codes their own AES-GCM.
I also think Colin is wrong about ECC, particular versus RSA.
RSA might be the most error prone cryptographic primitive available to developers. There are two big reasons for this:
* RSA has fussy padding requirements. The current best practices for RSA encryption and signing are OAEP and PSS (huge credit to Colin for getting this right in 2010). If you want to form an opinion about RSA, go read up on OAEP and ask yourself (honestly) if you would come up with anything resembling OAEP if you were called on to encrypt with RSA. Developers as a rule do not use OAEP; instead, most new software still uses PKCS1v15 padding, which introduces susceptibility to terrible vulnerabilities that can often be easily exploited in the wild. Even better are the Javascript developers who build RSA from first principles and skip the padding altogether (the fact that RSA padding is a requirement and not an annoyance to be avoided is why Nate Lawson says we should call it "RSA armoring" and not "RSA padding").
* RSA easily supports a direct encryption transform, which is widely used in practice. ECC software as a general rule does not synthesize an encryption transform from the ECDLP; instead, ECC software uses the ECDLP to derive a key, and then uses something like AES to actually encrypt data. You might be thinking, "that's how RSA software works too". But RSA in practice is subtly different: you can, for instance, easily encrypt a credit card number directly using RSA, or build a crappy key exchange protocol where the client encrypts (doesn't derive or sign, but encrypts) a key for the server. RSA and conventional DLP crypto therefore offer (encrypt, key-exchange, sign); ECC in practice offers just (key-exchange, sign). That's one less dimension of things developers have to get right in ECC cryptosystems.
Colin is smarter than me and much better trained in cryptography than I am. All I do is find and exploit crypto bugs in real software. I am usually as nervous as any of you are to challenge Colin about crypto, but I think I can win these two arguments. (Spoiler alert: Colin doesn't think so).
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 was skipping the details because Thomas and I have had this argument here at least a dozen times, and I figured that people were getting sick of it by now. To summarize the arguments:
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.
I love your summary about cat-sharing startups vs. C code for internet-facing daemons, but the cat-sharing people can't usually afford our rates for crypto work; most of my experience comes from code built by people with lots of experience.
Also, if you asked me who was more likely to get crypto right, the Django web guy or the C daemon guy, I'd bet on the Django guy every time. Betting against crypto implemented in C is like betting when you've made a full house on the flop: all in.
First off, do not interpret my comments as trying to provide any sort of advice to anyone. I am merely expressing frustration.
I have to agree with Colin's [1] point.
The standard libraries for the languages I see in assessments most often just don't include AEAD constructions. And when public libraries exist, they haven't been properly assessed.
Can you be more specific? Because this assertion didn't ring true to me based on my own experience, and less than 5 minutes of Googling appears to refute it:
* OpenSSL supports AEAD through CCM and GCM (and OpenSSL's GCM uses PCLMUL and shouldn't have the obvious cache leak)
* Botan supports AEAD through OCB, GCM, CCM, EAX, and SIV(!).
* Java JCE with the Bouncycastle provider (extremely popular) does AEAD with GCM, CCM, and OCB
* .NET stack languages get AEAD through CCM or GCM.
* Crypto++ supports AEAD with GCM, CCM, and EAX.
* Golang supports AEAD through GCM in the standard library (I did implement a crappy OCB myself, but the go.crypto package probably has a better one).
What bases aren't covered here? Bear in mind that most languages get their crypto through bindings to OpenSSL.
Sorry for the slow reply. I haven't looked into setting up notifications for replies. (if that exists on HN?)
But .NET probably represents the largest block of applications I see. Seconded by (shudder) CF. I don't really have any hope for CF but crypto is hardly it's biggest problem.
As far as .NET goes, my first point was that the standard library does not support it; true in this case. I'm aware of CLR and Bouncy Castle as external libraries but neither of them inspires me with confidence.
Supposedly, CLR was released by Microsoft but why didn't they include it in the standard library or release any associated security assessment reports? Were there any?
I've heard the name Bouncy Castle thrown around quite a bit but that's about it. When I dig through their websites, it leaves me with a feeling not unlike trying to find information about Truecrypt. Granted, I haven't followed their project(s) very closely. But because of that feeling, I honestly trust OpenSSL more because people are scared about it.
So, maybe I'm just missing something but this is where I've arrived. Please correct me if I'm way off base.
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.
Academics do love their new fancy stuff. Here's the thing: elliptic curve cryptography is not particularly new anymore. I'd buy this neophilia argument if it were concerning pairings, ideal lattices, or the stuff people are doing with these nowadays (FHE, obfuscation, etc).
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.)
I don't think it's fair to compare on the basis of years alone. Elliptic curves weren't getting nearly as much attention back when there were a dozen patents covering everything.
I think that in this case where the persons mostly agree to disagree, both solutions are usable. You could bicker endlessly about superiority of one over another, but seems like picking either one is not massive mistake.
The slide starting on PDF page 83 seems wrong? If I know (x, E_k(x)) for some x (or even without knowing them), then I can trivially compute (x', E_{k'}(x')) for k' and x' of my choosing.
Somewhat disappointing, since this slide is the only one in the presentation containing anything cryptographically "meaty".
I can trivially compute (x', E_{k'}(x')) for k' and x' of my choosing.
True, I oversimplified a bit. I was referring to situations where you don't know k' and x', e.g., x' = x and k' = k ^ \epsilon for some value \epsilon.
Not if E is ideal. The point is that an ideal block cipher is not vulnerable to related key attacks. It should be indistinguishable from a random permutation. Selected uniformly from S_n, where n is the cardinality of the key space.
I would love to know your opinion about ARX ciphers.
Direct implementation of AES from specification can be attacked using cache-timing side-channel. ARX ciphers are much easier to implement in software and also because they run in constant time, and are therefore immune to timing attacks.
What is your opinion of ARX ciphers Chacha20 (from Daniel J. Bernstein ) and Threefish, Skein hash (Bruce Schneier, Niels Ferguson) ?
I have a probably stupid question for you regarding ECC: in general, is ECC cryptography safe from attacks such as "Dual_EC_DRBG",where the curve itself was (potentially) constructed specifically to be breakable? I.e. if I use one of the publicly recommended curves, am I safe or could the curve also be broken by its author?
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 points to AES-GCM, the most popular AEAD mode, as an example of how AEAD modes can be more susceptible to side-channel attacks than AES-CTR+HMAC-SHAx. I don't think this is a strong argument for a couple reasons:
* AES-GCM is so far as I can tell no practical cryptographer's preferred AEAD mode; "whipping boy" might be a better role to ascribe to it.
* AES-GCM's side-channel issues are due principally to a hardware support concern (GMAC, AES-GCM's answer to HMAC, requires modular binary polynomial multiplication, which in pure software is table-driven, which creates a cache timing channel). That hardware support concern might be receding, and platforms that don't have AES-GCM might prefer a different AEAD mode anyways.
* Modern AEAD modes, of the sort being entered into CAESAR, have resilience against side channels as a design goal.
* But the most important rejoinder to Colin's preference for HMAC-SHAx over AEAD modes is this: HMAC-SHAx is responsible for more side-channel flaws than any other construction. Practically every piece of software that has implemented HMAC-SHAx has managed to introduce the obvious timing channel in comparing the candidate to the true MAC for a message. What's worse is, using AES-CTR+HMAC-SHAx in practice means that the developer has to code the HMAC validation themselves; it's practically an engraved invitation to introduce a new timing leak. Almost nobody codes their own AES-GCM.
I also think Colin is wrong about ECC, particular versus RSA.
RSA might be the most error prone cryptographic primitive available to developers. There are two big reasons for this:
* RSA has fussy padding requirements. The current best practices for RSA encryption and signing are OAEP and PSS (huge credit to Colin for getting this right in 2010). If you want to form an opinion about RSA, go read up on OAEP and ask yourself (honestly) if you would come up with anything resembling OAEP if you were called on to encrypt with RSA. Developers as a rule do not use OAEP; instead, most new software still uses PKCS1v15 padding, which introduces susceptibility to terrible vulnerabilities that can often be easily exploited in the wild. Even better are the Javascript developers who build RSA from first principles and skip the padding altogether (the fact that RSA padding is a requirement and not an annoyance to be avoided is why Nate Lawson says we should call it "RSA armoring" and not "RSA padding").
* RSA easily supports a direct encryption transform, which is widely used in practice. ECC software as a general rule does not synthesize an encryption transform from the ECDLP; instead, ECC software uses the ECDLP to derive a key, and then uses something like AES to actually encrypt data. You might be thinking, "that's how RSA software works too". But RSA in practice is subtly different: you can, for instance, easily encrypt a credit card number directly using RSA, or build a crappy key exchange protocol where the client encrypts (doesn't derive or sign, but encrypts) a key for the server. RSA and conventional DLP crypto therefore offer (encrypt, key-exchange, sign); ECC in practice offers just (key-exchange, sign). That's one less dimension of things developers have to get right in ECC cryptosystems.
Colin is smarter than me and much better trained in cryptography than I am. All I do is find and exploit crypto bugs in real software. I am usually as nervous as any of you are to challenge Colin about crypto, but I think I can win these two arguments. (Spoiler alert: Colin doesn't think so).