4 ms·

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

by M4v3R 12y ago

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?

zokier 12y ago
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.
tptacek 12y ago
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.
- cperciva 12y ago
  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.
  - pbsd 12y ago
    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.)
    - cperciva 12y ago
      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.
  - seanewest 12y ago
    neophilia: love of or enthusiasm for what is new or novel
cperciva 12y ago
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.
- tptacek 12y ago
  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.
  - archwisp 12y ago
    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.

by M4v3R 12y ago

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?

zokier 12y ago

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.

tptacek 12y ago

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.

cperciva 12y ago
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.
- pbsd 12y ago
  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.)
  - cperciva 12y ago
    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.
- seanewest 12y ago
  neophilia: love of or enthusiasm for what is new or novel

cperciva 12y ago

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.

tptacek 12y ago
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.
- archwisp 12y ago
  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.