Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Can't constant-time multiplication techniques somehow fall victim to that level of visbility?

(If we can track details like contention for integer units in the CPU, why don't we just peek at what bits are churning through the registers?)



No; the core goal of side-channel-free algorithms (of which constant time algorithms are a subset) is that the instructions executed by the CPU should not depend on secret data.

Spinning until a fixed time is reached could conceivably leak information if another thread can time math-unit bandwidth; it would be able to distinguish the spinwait from bona-fide mathematical computation.

However, no (known) method accessible to code running on the machine can distinguish between an adder unit summing zeroes versus key data.


Can't we throw a few math instructions into the spin loop?


-> Can we throw exactly the same number of math (micro)operations into the spin loop?

-> Can we just make sure the exact same operation operations occur?


The first idea seems way easier to achieve and maintain. It can be implemented at higher level around a complex, lumped operation, like calculating a signature, without having to go into all of that operation's subroutines to change everything to constant time. We could conceivably drop it into any language, wrapping it around any crypto, while treating that as a black-box.


Could also be faster. That is to say, variable-time calculations likely have a worst case time that is better than for the equivalent fixed-time calculations, since we just write the obvious code for the CPU using its normal instructions and optimize as usual. If we are able to box the padded time fairly tightly to the worst case, we are better off performance-wise than with the fixed-time implementations.


The first is a real vulnerability on systems with hyperthreading (https://github.com/bbbrumley/portsmash)

On the other hand, as far as I know, looking at register content requires debugging rights, or would have to depend on a defect in the CPU.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: