Hertzbleed: impact and mitigations

[fscoto]

Yingchen Wang et al. recently released a Hertzbleed: Turning Power Side-Channel Attacks Into Remote Timing Attacks on x86.

In essence, frequently boosting on mainstream AMD and Intel CPUs causes (remotely) measurable differences in execution speeds with apparently practical exploitation, even for seemingly constant-time operations like addition depending on the involved numbers. No microcode patches seem to be planned and from the description it seems there can't be meaningful OS-level mitigations.

Intel provides guidance on mitigation in software, which boils down to techniques about power side channel mitigation. In other words, power side channel mitigations are likely going to become de facto parts of networked threat models. The performance impact is likely to be catastrophic.

Open research questions:

1. Is Monocypher going to mitigate Hertzbleed?
2. How much effort is involved in patching up the X25519, Ed25519, Elligator and Poly1305 code in particular?
3. If Monocypher mitigates Heartbleed, should the unmitigated code be behind some kind of #define for e.g. embedded applications with CPUs that cannot exhibit this frequency boosting behavior?
4. Since the expected changes may be highly invasive, would another audit be useful if not required?

[LoupVaillant]

And cryptographers worry about quantum computing…

Tentative answers:

1. Not before someone else (Libsodium, Dalek, libdecaf…) lays out a clear action plan.
2. This is probably unfixable, even in theory. What we need is constant-power operations, and to my knowledge modern CPUs simply don't have those. Not even bitwise logic. Even if it is fixable, the slowdowns are likely prohibitive.
3. I suspect the necessary changes to be so huge that we need a new dedicated edition of Monocypher for this.
4. It would be required. I'm confident I can write code that produces the right results, but I know nothing about the constant-power side channel.

In any case, there's not much I can do right now, so I suggest we leave this issue open and wait for the dust to settle.

[fscoto]

Can we treat this as wontfix/no action required for 4.0.0? If we wanted to make breaking changes, now before 4.0.0 would be the time and it seems nobody else has made a move despite the novel threat model.

[LoupVaillant]

Indeed this won't be fixed for 4.0.0. It's "only" been 8 months since we knew of the issue so I didn't dare close it outright, but… Benevolent dictator (me) hereby says this won't be fixed for 4.0.0.

Now I can add the label and close this right now (we can always re-open this issue later), or I can wait this summer. But to be honest I'm not expecting any new result in the coming months.