3 ms·

It's a bit surprising that the article didn't mention ensuring constant time algorithms are used. If latency or the emissions of the CPU (etc. externally observ

It's a bit surprising that the article didn't mention ensuring constant time algorithms are used. If latency or the emissions of the CPU (etc. externally observable) are data dependent on something secret, that secret might leak through the side channel. One way to combat these side channels is to use constant time multiplication, loop conditions (including functions that might return early, like memcmp), etc. Is it possible for Rust to have any new or surprising mechanisms that cause loss of constant time execution? (Of course also other aspects can leak than the CPU instruction execution latency itself. For example cache effects might be measurable.)

GordonS 8y ago
I've only read about the relevance of constant-time comparisons in relation to comparisons, such as checking that a calculated hash is the same as a stored hash - could you elaborate on how it applied to symmetric encryption?
- vardump 8y ago
  Some operations, such as integer multiplication and division have data dependent latency. Depends on CPU model. See for example this page: https://bearssl.org/ctmul.html https://bearssl.org/ctmul.html > could you elaborate on how it applied to symmetric encryption? Non-constant time multiplication is mostly (only?) an issue with asymmetric crypto.
- fpgaminer 8y ago
  If an implementation isn't constant time it can potentially leak information about the key. i.e. the relative length of time it takes to encrypt may be dependent on properties of the key. So an attacker that can measure how long it takes you to encrypt something can begin to derive the key. Similar attacks occur when your encryption uses lookup tables depending on key bits, uses different amounts of power, etc. It's a surprisingly effective attack surface, and why the industry is moving away from older style schemes like AES and towards ARX based constructions like ChaCha.
nicoburns 8y ago
> Is it possible for Rust to have any new or surprising mechanisms that cause loss of constant time execution? I believe it's certainly possible. And the precise consequences of writing this code in Rust have yet to be fully explored. The `ring` (Rust port/fork of BoringSSL) library still links to constant-time primitives implemented in C.
jpfed 8y ago
>Is it possible for Rust to have any new or surprising mechanisms that cause loss of constant time execution? The ubiquitous assumption that all code should be executed as fast as possible isn't new or Rust-specific but it will be a continuing source of security surprises for the foreseeable future.

GordonS 8y ago

I've only read about the relevance of constant-time comparisons in relation to comparisons, such as checking that a calculated hash is the same as a stored hash - could you elaborate on how it applied to symmetric encryption?

vardump 8y ago
Some operations, such as integer multiplication and division have data dependent latency. Depends on CPU model. See for example this page: https://bearssl.org/ctmul.html https://bearssl.org/ctmul.html > could you elaborate on how it applied to symmetric encryption? Non-constant time multiplication is mostly (only?) an issue with asymmetric crypto.
fpgaminer 8y ago
If an implementation isn't constant time it can potentially leak information about the key. i.e. the relative length of time it takes to encrypt may be dependent on properties of the key. So an attacker that can measure how long it takes you to encrypt something can begin to derive the key. Similar attacks occur when your encryption uses lookup tables depending on key bits, uses different amounts of power, etc. It's a surprisingly effective attack surface, and why the industry is moving away from older style schemes like AES and towards ARX based constructions like ChaCha.

nicoburns 8y ago

> Is it possible for Rust to have any new or surprising mechanisms that cause loss of constant time execution? I believe it's certainly possible. And the precise consequences of writing this code in Rust have yet to be fully explored. The `ring` (Rust port/fork of BoringSSL) library still links to constant-time primitives implemented in C.

jpfed 8y ago

>Is it possible for Rust to have any new or surprising mechanisms that cause loss of constant time execution? The ubiquitous assumption that all code should be executed as fast as possible isn't new or Rust-specific but it will be a continuing source of security surprises for the foreseeable future.