Pull request to start building guidelines around writing crypto software in a post-Spectre world:
https://github.com/HACS-workshop/spectre-mitigations/pull/2 …
Can see the initial draft guidelines here:
https://github.com/chandlerc/spectre-mitigations/blob/4aa1019f6add0940611152f8cc5cc4d873f36691/crypto_guidelines.md …
@cryptojedi - as promised. =D Comments / feedback very welcome.
I think rule #2 is unclear. It would be great to see 1 or more real-world examples of code breaking it.
-
-
Imagine a switch on non-secret data like the round number or an input "constants" to an optimized code sequence. While the switch, speculatively or normally executed, leaks nothing, a variant #2 attack can send control to a leaking gadget w/ secrets already in loaded. Boom.
-
(maybe there are algos where the round number is secret, I have no idea, but the point remains the same. Attacker can upgrade a "safe" switch/jump-table/indirect-call into a leak via Spectre)
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.