3 ms·
> Does 25519 suffer from key/data-dependant execution time? I mean, when implemented naively, yes, but the industry has been aware of timing attacks for decade
by vitus 2y ago
> Does 25519 suffer from key/data-dependant execution time?
I mean, when implemented naively, yes, but the industry has been aware of timing attacks for decades such that this is table stakes for any crypto implementations.
From the article:
> We also do our best to execute the algorithms in constant time, to thwart side-channel attacks that infer secret information from the durations of computations.
https://github.com/awslabs/s2n-bignum https://github.com/awslabs/s2n-bignum (where most of the heavy lifting is done, per the article) further explicitly states that "Each function is moreover written in a constant-time style to avoid timing side-channels."
- justinwsmith 2y agoThe next paragraph makes a slightly stronger statement about its constant-time'ness: > Our implementations of x/Ed25519 are designed with constant time in mind. They perform exactly the same sequence of basic CPU instructions regardless of the input values, and they avoid any CPU instructions that might have data-dependent timing.
- deathanatos 2y ago> but the industry has been aware of timing attacks for decades such that this is table stakes for any crypto implementations. When I see CVE-fests like — https://people.redhat.com/~hkario/marvin/ https://people.redhat.com/~hkario/marvin/ — … I just do not come away with that impression. [Widely used] Cryptographic Rust crates offering "constant time" operations in "pure Rust" — but Rust has no primitives for doing constant time operations, so it's only through hopes and prayers that it might actually work, and with no guarantee anywhere that it actually should. (Other, less timing attack related stuff, but e.g., major companies still not supporting anything beyond RSA.)