Comment by loup-vaillant | Hacker News Reader

Comment by loup-vaillant | Hacker News Reader

Parent Full thread

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

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

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

Reply on news.ycombinator.com