This has been a sore point in a lot of discussions regarding compiler optimizations and cryptographic code, how compilers and compiler engineers are sabotaging the efforts of cryptographers in making sure there are no side-channels in their code. The issue has never been the compiler, and has always been the language: there was never a way to express the right intention from within C (or most other languages, really).

This primitive we're trying to introduce is meant to make up for this shortcoming without having to introduce additional rules in the standard.

▲

Asooka 9 minutes ago | parent | next [-]

There really ought to be a subset of C that lets you write portable assembly. One where only a defined set of optimisations are allowed and required to be performed, "inline" means always inline, the "register" and "auto" keywords have their original meanings, every stack variable is allocated unless otherwise indicated, every expression has defined evaluation order, every read/write from/to an address is carried out, nothing is ever reordered, and undefined behaviour is switched to machine-specific behaviour. Currently if you need that level of control, your only option is writing it in assembly, which gets painful when you need to support multiple architectures, or want fancy features like autocomplete or structs and functions.

▲

fanf2 9 hours ago | parent | prev | next [-]

What happened to the blog post? It was moved and now it has disappeared :-(

	▲	foresto 3 hours ago \| parent \| next [-]
		https://web.archive.org/web/20251125224147/https://blog.trai...
	▲	Meneth 8 hours ago \| parent \| prev [-]
		Archived copy here: https://archive.is/tIXt7

▲

jfindper 11 hours ago | parent | prev | next [-]

>how compilers and compiler engineers are sabotaging the efforts of cryptographers

I'm not exposed to this space very often, so maybe you or someone else could give me some context. "Sabotage" is a deliberate effort to ruin/hinder something. Are compiler engineers deliberately hindering the efforts of cryptographers? If yes... is there a reason why? Some long-running feud or something?

Or, through the course of their efforts to make compilers faster/etc, are cryptographers just getting the "short end of the stick" so to speak? Perhaps forgotten about because the number of cryptographers is dwarfed by the number of non-cryptographers? (Or any other explanation that I'm unaware of?)

▲

chowells 11 hours ago | parent | next [-]

It's more a viewpoint thing. Any construct cryptographers find that runs in constant time is something that could be optimized to run faster for non-cryptographic code. Constant-time constructs essentially are optimizer bug reports. There is always the danger that by popularizing a technique you are drawing the attention of a compiler contributor who wants to speed up a benchmark of that same construct in non-cryptographic code. So maybe it's not intended as sabotage, but it can sure feel that way when everything you do is explicitly targeted to be changed after you do it.

▲

stouset 11 hours ago | parent | prev | next [-]

It’s not intentional. The motivations of CPU designers, compiler writers, and optimizers are at odds with those of cryptographers. The former want to use every trick possible to squeeze out additional performance in the most common cases, while the latter absolutely require indistinguishable performance across all possibilities.

CPUs love to do branch prediction to have computation already performed in the case where it guesses the branch correctly, but cryptographic code needs equal performance no matter the input.

When a programmer asks for some register or memory location to be zeroed, they generally just want to be able to use a zero in some later operation and so it doesn’t really matter that a previous value was really overwritten. When a cryptographer does, they generally are trying to make it impossible to read the previous value. And they want to be able to have some guarantee that it wasn’t implicitly copied somewhere else in the interim.

▲

layer8 11 hours ago | parent | prev [-]

“Sabotage” can be used in a figurative sense that doesn’t insinuate intent. An adjacent example is “self-sabotage”, which doesn’t imply intent.

	▲	layer8 8 hours ago \| parent \| next [-]
		Since the sibling comment is dead and thus I can’t reply to it: Search for “unintentional sabotage”, which should illustrate the usage. Despite appearances, it isn’t an oxymoron. See also meaning 3a on https://www.merriam-webster.com/dictionary/sabotage.
	▲	jfindper 9 hours ago \| parent \| prev [-]
		[dead]

▲

fooker 11 hours ago | parent | prev [-]

> making sure there are no side-channels in their code

Any side effect is a side channel. There are always going to be side channels in real code running on real hardware.

Sure you can change your code, compiler, or, or even hardware to account for this but at it's core that is security by obscurity.