Hacker News Reader

Comment by deanCommie | Hacker News Reader

> Cryptography has rules, which are both simpler and more fundamental than we might think.

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.

View on HN

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

> 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

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)

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.

> As long as you are using C...

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.

> Replacing pointer arithmetic where it's needed with array indexing stands out the most but there's other issues.

What situations do you run into where array indexing is not an acceptable substitute for pointer arithmetic?

For the record, implementing Monocypher was not one of them. I use arrays everywhere.

The one borderline case I can cite is wiping memory. I go by sizeof() and access each byte.

> 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).

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.

> 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.

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?

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/

[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

> 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!

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.

At least it's only 12 more years until the patents on OCB3 expire. We're almost at the halfway point.

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)?

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:p...

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.

>> 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.

Reply on news.ycombinator.com