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.
Arguably, that was because until recently our Chess and Go machines relied too heavily on extensive deep search. For much of the game Go has a branching factor at least an order of magnitude higher than Chess, and a Go game typically lasts many more moves than a Chess game, and the consequences of a bad move in Go can take a lot longer to become apparent than in Chess.
When DeepMind came alone with an approach that was not as heavily reliant on extensive deep search, their machines didn't seem to have much more difficulty with Go than with Chess.
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
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)
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.
These things mentioned are what frustrate me with crypto implementations in pure Rust, the attempts at constant time operations aren't that solid and everyone is going to war with the compiler to simply get basic functionality. Replacing pointer arithmetic where it's needed with array indexing stands out the most but there's other issues.
Honestly think just using C bindings and calling it day is the best way for anything going into production.
What situations do you run into where array indexing is not an acceptable substitute for pointer arithmetic?
The one borderline case I can cite is wiping memory. I go by sizeof() and access each byte.
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.
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/
[2] On Subnormal Floating Point and Abnormal Timing https://cseweb.ucsd.edu/~dkohlbre/papers/subnormal.pdf
[3] Predicting Secret Keys via Branch Prediction https://eprint.iacr.org/2006/288.pdf
[4] Exploiting I-Cache https://eprint.iacr.org/2007/164.pdf
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!
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.
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:p...
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.
> <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.
<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.