5 ms·

> Cryptography has rules, which are both simpler and more fundamental than we might think. <Proceeds to describe Cryptography in a way that confirms that it is

> Cryptography has rules, which are both simpler and more fundamental than we might think. <Proceeds to describe Cryptography in a way that confirms that it is exactly as complex as I set it out in my head> e.g. from just the first pagraph: > " Never ignore timings, they're part of most threat models." > On most CPUs, the timing side channel can be eliminated by removing all secret dependent branches and all secret dependent indices. > Some CPUs also have variable time arithmetic operations. > Watch out for multiplications and shifts by variable amounts in particular. Yeah dude, stuff like this is EXACTLY what most people don't want to think about, and shouldn't have to think about, and which is why the guidance is "don't roll your own". I reject his premise as well that this guidance prevents good people from pursuing Crypto as a field of study - as far as I can tell it's not discouraging anyone with actual interest in it.

vore 6y ago
> Also be careful around compilers and interpreters. No mainstream language specifies how to make constant time code, so your tools could insert secret dependent branches where the source code had none. High level languages in particular tend to have variable time arithmetic. In practice, low level languages like C are fairly reasonable, but I've seen exceptions. This is by definition not simple if the very tools you're using can cause what you think is correct to be wrong and dangerous!
wildmanxx 6y ago
>> Cryptography has rules, which are both simpler and more fundamental than we might think. > <Proceeds to describe Cryptography in a way that confirms that it is exactly as complex as I set it out in my head> This. Soooooo much this.
gregmac 6y ago
> Yeah dude, stuff like this is EXACTLY what most people don't want to think about, and shouldn't have to think about, and which is why the guidance is "don't roll your own". I'd even go a step further and say a lot of the problem is that people don't even know about this as a thing to even consider thinking about. Unknown unknowns are the dangerous bit. Does this article cover every aspect of the things you need to consider? I know enough about it to say both I don't know and I highly doubt it.
- zrm 6y ago
  There's also the matter that they keep adding things to the list. Remember three years ago when we didn't know we had to worry about Spectre?
  - ljhsiung 6y ago
    Minor nitpick, but "three years ago" the crypto world still did "worry" about Spectre and general transient execution attacks [1][2][3][4]. To me, the biggest thing about Spectre et al. wasn't the proof that CPU uArch can negatively impact security. Rather, it's the proof of information leakage from other processes and privilege modes, which is a drastically heightened vector than cryptography. [1] https://ts.data61.csiro.au/projects/TS/cachebleed/ https://ts.data61.csiro.au/projects/TS/cachebleed/ https://ts.data61.csiro.au/projects/TS/cachebleed/ https://ts.data61.csiro.au/projects/TS/cachebleed/ [2] On Subnormal Floating Point and Abnormal Timing https://cseweb.ucsd.edu/~dkohlbre/papers/subnormal.pdf https://cseweb.ucsd.edu/~dkohlbre/papers/subnormal.pdf [3] Predicting Secret Keys via Branch Prediction https://eprint.iacr.org/2006/288.pdf https://eprint.iacr.org/2006/288.pdf [4] Exploiting I-Cache https://eprint.iacr.org/2007/164.pdf https://eprint.iacr.org/2007/164.pdf
loup-vaillant 6y ago
Oh, I did not mean to say it would be a piece of cake. Yes, side channels can be a nightmare to track down. But it's not a matter of knowing cryptography. It's a matter of knowing your platform. The rule (don't let data flow from secrets to the side channel), remains dead simple. Think Go (the board game). The rules are much simpler than Chess, and the game itself arguably deeper (for instance, effective Go AIs appeared much later than effective Chess AIs). > Yeah dude, stuff like this is EXACTLY what most people don't want to think about, and shouldn't have to think about Selecting yourself out is fine. And apparently you're doing it for all the right reasons: too much investment, not worth your time. One of my goals was to address the "how hard can it be?" eyes wide would be cryptographer. Well, this hard. More or less. > I reject his premise as well that this guidance prevents good people from pursuing Crypto as a field of study - as far as I can tell it's not discouraging anyone with actual interest in it. I confess I'm not quite sure about this one. I'll just note that we've seen people bullied out of some fields. (I recall stories of women being driven out on competitive gaming that way.) A constant stream of "don't roll your own crypto" is not exactly bullying, but I can see it be a tad discouraging. To give you an example, here's the kind of mockery I have to face, even now. https://twitter.com/bascule/status/1287113393439035392 https://twitter.com/bascule/status/1287113393439035392
- dependenttypes 6y ago
  > Yes, side channels can be a nightmare to track down I think that this is extremely overrated. As long as you are using C (rather than some weird language), avoid branches with secrets, avoid indexing arrays with secrets, and avoid *, division, and mod with secrets it should be fine. > https://twitter.com/bascule/status/1287113393439035392 https://twitter.com/bascule/status/1287113393439035392 Low quality posts like that which encourage dunking on people rather than discussion are what made me stop using twitter. Extremely disgusting on his part, I am sorry that you have to deal with this sort of bullying. (I also did not find any signed shift despite the claim of the person responding)
  - loup-vaillant 6y ago
    Agreed, timings are not too hard to address in C. Though I confess I gave up on multiplication. Monocypher's manual warns users about that, but I can't avoid it without incurring unacceptable slowdowns on most platforms. The other side channels however I gave up on them: only custom silicon can meaningfully squash the energy consumption side channel for instance. Software approaches are in my opinion brittle mitigations at best. About Twitter, I may have overplayed it: I don't use it, so I mostly don't see these things, which in reality are really infrequent. The worst I got was at the time I disclosed the signature vulnerability. It was like a dozen tweets, and only a couple were openly mocking (for the anecdote, I only saw those tweets a year later). In any case, I don't give them much weight: writing this kind of drivel requires some degree of ignorance about my work.
bjoli 6y ago
This reminds me of when I tried implementing AES-GCM. AES-OCB3 was fine. I just read the paper on ocb3 and it worked. GCM on the other hand took me a gazillion tries, and even though I ended up more or less copying a reference implementation I still got weird edge case errors.
- beefhash 6y ago
  At least it's only 12 more years until the patents on OCB3 expire. We're almost at the halfway point.
  - bjoli 6y ago
    I tried reading the patents, and one is expired due to non-payment and the other expires (or rather: anticipated expiration) next year. How does the system work? Can Rogaway just revive that patent (which is the one valid longer)?
    - beefhash 6y ago
      Oh. I see what's going on, and I was wrong about this. US7949129B2 expired because he didn't pay the patent fees. US8321675B2 claims priority to a patent from 2001. Claiming priority is a way to broaden an existing patent by saying “it's this, but improved”; however, this also means inheriting the expiry date of the patent claiming priority to. So yeah, that one's expiring next year already. Holy cow, thanks for making me check. Another, related patent that he notes in the FAQ[1] is 8,107,620, which won't expire until 2029 unless IBM forgets to pay patent fees. Hard to tell if it really applies to OCB3 though. [1] https://www.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm#patent:phil https://www.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm#patent:p...
      - bjoli 6y ago
        The Jutla patent would apply to any AEAD scheme, and I haven't heard about IBM hunting AES-GCM users. So, 2021 might be the year! Edit: I was incorrect about the Jutla patent. It seems to only apply to patents that are CBC- or ECB-like. GCM should be fine.

vore 6y ago

> Also be careful around compilers and interpreters. No mainstream language specifies how to make constant time code, so your tools could insert secret dependent branches where the source code had none. High level languages in particular tend to have variable time arithmetic. In practice, low level languages like C are fairly reasonable, but I've seen exceptions. This is by definition not simple if the very tools you're using can cause what you think is correct to be wrong and dangerous!

wildmanxx 6y ago

>> Cryptography has rules, which are both simpler and more fundamental than we might think. > <Proceeds to describe Cryptography in a way that confirms that it is exactly as complex as I set it out in my head> This. Soooooo much this.

gregmac 6y ago

> Yeah dude, stuff like this is EXACTLY what most people don't want to think about, and shouldn't have to think about, and which is why the guidance is "don't roll your own". I'd even go a step further and say a lot of the problem is that people don't even know about this as a thing to even consider thinking about. Unknown unknowns are the dangerous bit. Does this article cover every aspect of the things you need to consider? I know enough about it to say both I don't know and I highly doubt it.

zrm 6y ago
There's also the matter that they keep adding things to the list. Remember three years ago when we didn't know we had to worry about Spectre?
- ljhsiung 6y ago
  Minor nitpick, but "three years ago" the crypto world still did "worry" about Spectre and general transient execution attacks [1][2][3][4]. To me, the biggest thing about Spectre et al. wasn't the proof that CPU uArch can negatively impact security. Rather, it's the proof of information leakage from other processes and privilege modes, which is a drastically heightened vector than cryptography. [1] https://ts.data61.csiro.au/projects/TS/cachebleed/ https://ts.data61.csiro.au/projects/TS/cachebleed/ https://ts.data61.csiro.au/projects/TS/cachebleed/ https://ts.data61.csiro.au/projects/TS/cachebleed/ [2] On Subnormal Floating Point and Abnormal Timing https://cseweb.ucsd.edu/~dkohlbre/papers/subnormal.pdf https://cseweb.ucsd.edu/~dkohlbre/papers/subnormal.pdf [3] Predicting Secret Keys via Branch Prediction https://eprint.iacr.org/2006/288.pdf https://eprint.iacr.org/2006/288.pdf [4] Exploiting I-Cache https://eprint.iacr.org/2007/164.pdf https://eprint.iacr.org/2007/164.pdf

loup-vaillant 6y ago

Oh, I did not mean to say it would be a piece of cake. Yes, side channels can be a nightmare to track down. But it's not a matter of knowing cryptography. It's a matter of knowing your platform. The rule (don't let data flow from secrets to the side channel), remains dead simple. Think Go (the board game). The rules are much simpler than Chess, and the game itself arguably deeper (for instance, effective Go AIs appeared much later than effective Chess AIs). > Yeah dude, stuff like this is EXACTLY what most people don't want to think about, and shouldn't have to think about Selecting yourself out is fine. And apparently you're doing it for all the right reasons: too much investment, not worth your time. One of my goals was to address the "how hard can it be?" eyes wide would be cryptographer. Well, this hard. More or less. > I reject his premise as well that this guidance prevents good people from pursuing Crypto as a field of study - as far as I can tell it's not discouraging anyone with actual interest in it. I confess I'm not quite sure about this one. I'll just note that we've seen people bullied out of some fields. (I recall stories of women being driven out on competitive gaming that way.) A constant stream of "don't roll your own crypto" is not exactly bullying, but I can see it be a tad discouraging. To give you an example, here's the kind of mockery I have to face, even now. https://twitter.com/bascule/status/1287113393439035392 https://twitter.com/bascule/status/1287113393439035392

dependenttypes 6y ago
> Yes, side channels can be a nightmare to track down I think that this is extremely overrated. As long as you are using C (rather than some weird language), avoid branches with secrets, avoid indexing arrays with secrets, and avoid *, division, and mod with secrets it should be fine. > https://twitter.com/bascule/status/1287113393439035392 https://twitter.com/bascule/status/1287113393439035392 Low quality posts like that which encourage dunking on people rather than discussion are what made me stop using twitter. Extremely disgusting on his part, I am sorry that you have to deal with this sort of bullying. (I also did not find any signed shift despite the claim of the person responding)
- loup-vaillant 6y ago
  Agreed, timings are not too hard to address in C. Though I confess I gave up on multiplication. Monocypher's manual warns users about that, but I can't avoid it without incurring unacceptable slowdowns on most platforms. The other side channels however I gave up on them: only custom silicon can meaningfully squash the energy consumption side channel for instance. Software approaches are in my opinion brittle mitigations at best. About Twitter, I may have overplayed it: I don't use it, so I mostly don't see these things, which in reality are really infrequent. The worst I got was at the time I disclosed the signature vulnerability. It was like a dozen tweets, and only a couple were openly mocking (for the anecdote, I only saw those tweets a year later). In any case, I don't give them much weight: writing this kind of drivel requires some degree of ignorance about my work.

bjoli 6y ago

This reminds me of when I tried implementing AES-GCM. AES-OCB3 was fine. I just read the paper on ocb3 and it worked. GCM on the other hand took me a gazillion tries, and even though I ended up more or less copying a reference implementation I still got weird edge case errors.

beefhash 6y ago
At least it's only 12 more years until the patents on OCB3 expire. We're almost at the halfway point.
- bjoli 6y ago
  I tried reading the patents, and one is expired due to non-payment and the other expires (or rather: anticipated expiration) next year. How does the system work? Can Rogaway just revive that patent (which is the one valid longer)?
  - beefhash 6y ago
    Oh. I see what's going on, and I was wrong about this. US7949129B2 expired because he didn't pay the patent fees. US8321675B2 claims priority to a patent from 2001. Claiming priority is a way to broaden an existing patent by saying “it's this, but improved”; however, this also means inheriting the expiry date of the patent claiming priority to. So yeah, that one's expiring next year already. Holy cow, thanks for making me check. Another, related patent that he notes in the FAQ[1] is 8,107,620, which won't expire until 2029 unless IBM forgets to pay patent fees. Hard to tell if it really applies to OCB3 though. [1] https://www.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm#patent:phil https://www.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm#patent:p...
    - bjoli 6y ago
      The Jutla patent would apply to any AEAD scheme, and I haven't heard about IBM hunting AES-GCM users. So, 2021 might be the year! Edit: I was incorrect about the Jutla patent. It seems to only apply to patents that are CBC- or ECB-like. GCM should be fine.