3 ms·
> to avoid various timing attacks that could be introduced by optimization Assembler only goes so far. Until you figure out how the processor's front end will
by frutiger 10y ago
> to avoid various timing attacks that could be introduced by optimization
Assembler only goes so far. Until you figure out how the processor's front end will decode the machine code and run the underlying RISC program, or how the hypervisor will schedule your program on some shared machines (e.g. in EC2) you're susceptible to a different class of side-channel attacks.
- deleted 10y ago[deleted]
- tptacek 10y agoThis is true but not relevant to the discussion: whatever side channel problems you'd have in pure assembly, you're practically certain to have more of them if you implement crypto in a high-level language with an aggressive optimizer.
- frutiger 10y agoNote I never disagreed with GGP's premise - I'm only pointing out that you can go further than assembler.
- bradleyjg 10y agoIs there any way to write programs that bypass the processor's front end for most the processors in use? If not, it what sense is it true that "you can go further than assembler"?
- frutiger 10y agoYou don't have much choice with commodity hardware - but you could perform crypto on hardware/chips where the behavior is completely specified. Note that this is not very practical, and impractical crypto is almost as good as no crypto.
- makomk 10y agoThis is often, though not always, the case with deeply embedded processors of the kind BearSSL seems to be designed for. There's generally some way to get predictable cycle-exact performance on them because it matters for some embedded applications.