3 ms·

Very small one, but (taken from [1]): http://goo.gl/M8XThn http://goo.gl/M8XThn vs http://goo.gl/RZZf1N http://goo.gl/RZZf1N [1] https://cryptocoding.net/index

by pbsd 11y ago

Very small one, but (taken from [1]): http://goo.gl/M8XThn http://goo.gl/M8XThn vs http://goo.gl/RZZf1N http://goo.gl/RZZf1N [1] https://cryptocoding.net/index.php/Coding_rules#Compare_secret_strings_in_constant_time https://cryptocoding.net/index.php/Coding_rules#Compare_secr...

tedunangst 11y ago
Interesting. Looks like it affects all version of llvm (at least those that compile). I guess with LTO the result could be the same, but asking to always inline seems like asking the compiler to fuse operations, and then it sees shortcuts. Dunno.
- pbsd 11y ago
  `always_inline` is only there to make -O0 smaller for presentation purposes. It has no impact on -O2. The trick here is that -march=i386 predates CMOV, and that LLVM specializes code emitting for bool (and _Bool). If the secret bit were an uint32_t, there wouldn't be a branch anymore.
  - tedunangst 11y ago
    Oh! I did not look closely enough to see that this was c++ with bool. Now I am even less worried. :)
    - pbsd 11y ago
      Yeah, I'm not too worried either. There is one class of cryptographic code, however, that is entirely unsuitable to distribute in Bitcode---DPA/EM-protected code. EM attacks on middle-end ARM chips have been demonstrated recently [1, 2]. Protecting against these attacks usually involves splitting the computation into 2 or more "shares" (see, for example, [3]); these require strict control of which register each word goes into, and which registers overwrite which. This cannot be enforced in Bitcode---or any other bytecode, for that matter---and direct assembly must be used. [1] https://eprint.iacr.org/2015/561 https://eprint.iacr.org/2015/561 [2] http://cr.yp.to/talks/2014.09.25-2/slides-dan+tanja-20140925-2-4x3.pdf http://cr.yp.to/talks/2014.09.25-2/slides-dan+tanja-20140925... [3] http://keccak.noekeon.org/NoteSideChannelAttacks.pdf http://keccak.noekeon.org/NoteSideChannelAttacks.pdf

by pbsd 11y ago

tedunangst 11y ago

Interesting. Looks like it affects all version of llvm (at least those that compile). I guess with LTO the result could be the same, but asking to always inline seems like asking the compiler to fuse operations, and then it sees shortcuts. Dunno.

pbsd 11y ago
`always_inline` is only there to make -O0 smaller for presentation purposes. It has no impact on -O2. The trick here is that -march=i386 predates CMOV, and that LLVM specializes code emitting for bool (and _Bool). If the secret bit were an uint32_t, there wouldn't be a branch anymore.
- tedunangst 11y ago
  Oh! I did not look closely enough to see that this was c++ with bool. Now I am even less worried. :)
  - pbsd 11y ago
    Yeah, I'm not too worried either. There is one class of cryptographic code, however, that is entirely unsuitable to distribute in Bitcode---DPA/EM-protected code. EM attacks on middle-end ARM chips have been demonstrated recently [1, 2]. Protecting against these attacks usually involves splitting the computation into 2 or more "shares" (see, for example, [3]); these require strict control of which register each word goes into, and which registers overwrite which. This cannot be enforced in Bitcode---or any other bytecode, for that matter---and direct assembly must be used. [1] https://eprint.iacr.org/2015/561 https://eprint.iacr.org/2015/561 [2] http://cr.yp.to/talks/2014.09.25-2/slides-dan+tanja-20140925-2-4x3.pdf http://cr.yp.to/talks/2014.09.25-2/slides-dan+tanja-20140925... [3] http://keccak.noekeon.org/NoteSideChannelAttacks.pdf http://keccak.noekeon.org/NoteSideChannelAttacks.pdf