3 ms·
C does not make any guarantees about timing. It's not considered "observable behavior" by the standard. The usual way to create constant-time code for C is to
by SAI_Peregrinus 4y ago
C does not make any guarantees about timing. It's not considered "observable behavior" by the standard.
The usual way to create constant-time code for C is to inspect the output assembly for a number of (compiler, options, host system, target system) tuples and verify that it will take constant time on all of them. Even that isn't enough in general, since there are other side-channels. The "Hertzbleed" attack exploits variable execution time in "constant time" code due to CPU dynamic frequency scaling being dependent on the input (secret) data. That effectively means that power side-channels are remotely observable.
- tialaramex 4y ago> The usual way to create constant-time code for C is to inspect the output assembly Sure, I hoped that sort of thing was implicit in what I wrote, some people do it, perhaps they should not, but they clearly feel like it's their best option. In particular for the context: writing this code in Rust doesn't help and would usually make it harder. If we don't want to hand roll machine code, maybe somebody should make yet another "it's C but for the 21st century" language with constant time output as a deliberate feature, like maybe the const flag on your functions means produce constant time machine code or error - rather than "You can execute this function at compile time". (Not necessarily a serious syntactic suggestion, just spit-balling).
- SAI_Peregrinus 4y agoThe problem is that ISAs don't support any sort of side-channel resistance mode, so even hand-rolling assembly (or machine code) won't fix every possible leak. If such a mode could be added, then any language could add appropriate intrinsics to set it. More likely is that cryptography-specific instructions (like AES-NI or ARM's SHA hash instructions) will get added for more relevant operations.