On Sat, Apr 26, 2014 at 9:39 AM, Geoffroy Couprie <[email protected]> wrote: > Before writing production ready crypto code, some things must be tested > carefully, like the ability to write constant time code, or a "secure" > buffer implementation (wiped before freeing it). Constant time code is > possible in theory (the Rust-crypto has an AES implementation with > precautions for that), but I do not know what could be messed up by LLVM > optimizations there. > > Still, with the possibility of dropping some assembly directly where it is > needed, it is a great platform for crypto experimentation.
Even in plain C it is very hard to make any guarantees from the source code level. The C abstract machine doesn't promise how much time things take and the compiler is free to make optimizations that change the timing, though at the moment doing 'the obvious thing' for constant timeness seems to mostly not get broken by the optimizer there really are no promises, and an upgraded toolchain could change the behavior— which is especially bad because its difficult to construct reliable tests for constant-timeness. And all this before you start worrying about how the cpu pipeline might leak timing information even if all the instructions are supposed to be constant time, or the leakage from power analysis which seem impossible to close without specially constructed hardware. One of the things that is less hopeless and may inform the language spec (and library) is writing code that can keep all data structures that keep secret keys in mlocked and zeroed-after-use memory that comes along with doing crypto but which aren't the crypto themselves. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
