Can you clarify what you mean? You seem to imply that using multiple threads is not a good idea, but then also express that not using multiple threads is also not a good idea. What's left?
back
2 comments
I think encrypting independant packets on each thread is fine, what I believe he is refering to is encrypting a single packet on multiple threads. One of the many angles of attack against cryptography is side channel attacks, where for certain algorithms the path taken by the code depends on the value of the key/data. In which case you can leak some information by measuring the time it takes or power usage. Modern algorithms are carefully designed to not be path sensitive, which is hard enough when the algo executes on a single thread, but becomes really complex to manage on multiple threads. Just more opportunities to shoot oneself in the foot.
That's a fair argument, however we also want to exploit computational ressources. It's nothing new that clock speed stagnates but everything points to manycore architectures. Parallel crypto maybe hard but it is somewhat inevitable to research, investigate and implement.
Clock speed does not necessarily equal computational speed. I remember how ~15 years ago people predicted that single-core performance was not going to improve any longer, and that we would get more and more CPU cores over time.
My first multi-core machine was an Athlon64 X2 with two cores running at 2GHz. Today, my work laptop (ThinkPad L540) has a dual-core CPU (plus 2-way SMT) running at 2.6 GHz (3.2 GHz with TurboBost). But single-core performance has improved notably. Not as much as was common in the 1990s, but still. And for most desktop systems[1] more than two or four cores seem to be pointless, anyway, since they will sit idle most of the time.
[1] I am not talking about developer workstations, CAD machines or other high-end use cases, but the kind of machine where some office drone runs Outlook, Excel, and a web browser.
Most of this single core improvement, if I understand correctly, comes speculative execution and larger caches (rather than shorter pipelines), which -- in the context of crypto -- means that implementations go to great length to avoid the features that speed up execution, specifically BECAUSE they leak information.
Fair point.
Now, I know just enough about cryptography to know I know nearly nothing about it, so maybe someone can put this into context: Wouldn't a multi threaded crypto implementation open up a whole bunch of new potential attacks?
Good argument, but it is probably limited to the x86 architecture (and its contemporary grandchildren). In contrast, the OP explicitely mentions the Raspberry PI with its ARM CPU. This kind of RISC chips (more or less) secretly took over the world since virtually all mobile devices are equipped with such a SoC. It is common knowledge that these CPUs don't deliver the single core power of a desktop CPU but nevertheless parallelize. Without doubt it is worth in getting crypto fast(er) on such devices.
Fair point, I had not considered ARM and other low-power CPUs.
How many of those cores turbo boost to 3.2GHz though? Isn't it just one, even on the i5-8xxx laptop chips?
Probably. But I rarely push that computer to the point where it uses more than one core, except when I compress large amounts of data.
I think I understand that, but wouldn't you think that adding an "unknown fuzz" by sharing computation on 1-or-many threads makes it harder for an external party to do timing attack?
The attacker now has a lot more possible outcomes depending on the number of threads handling that packet. I seems, on the surface, as if more threads add complexity to the attacker.
Debugging multithreaded code is much harder than single threaded, especially because of all the race conditions that can happen: it makes our brains burn hot from all the possible outcomes from identical runs run one after the other. My intuition would lead me to believe that this complexity is also now added to the attacker's side - but perhaps I'm missing something.
A general rule of thumb is that any added complexity to crypto algorithms makes the attackers job easier in the end as accounting for all of the side channels becomes much harder.
Timing attacks are somewhat annoying and noisy to conduct over the Internet, but you can measure the time a process takes with a resolution down to ~15ns[0]. I bet there is all sorts of cross core cache errata that leaks more time than that.
[0]: https://www.cs.rice.edu/~dwallach/pub/crosby-timing2009.pdf
He's saying that it exacerbates an already complicated issue.