Verify JitterRng on hosted platforms

dhardy / rand

http://doc.rust-lang.org/rand

Other

2 stars 2 forks source link

Verify JitterRng on hosted platforms #65

Closed nagisa closed 6 years ago

nagisa commented 6 years ago

If my memory serves me well, the paper JitterRng was implemented according to was only really investigating the x86 platform and conclusions rely on some specific instructions working in a fairly specific way.

Since Rust supports targetting WASM now, we should make sure to check whether JitterRng produces quality entropy or, failing that, properly detects the failure and returns an error on hosted targets like wasm.

Specifically, of concern are:

Jitter caused by JIT translation during initial probing of the jitter quality (possible failure to detect low quality jitter as JIT translation most likely increases the jitter entropy);
Does jitter provide equally much of the entropy as on the bare-metal implementations in both "cold" (interpreted) and "warm" (JITed) states.

dhardy commented 6 years ago

It sounds like it's impossible to get nanosecond-resolution time in Javascript anyway, so JitterRng is not useful for WASM.

pitdicker commented 6 years ago

Apparently getting ns-resolution timings in Javascript is not allowed as a measure against timing attacks https://www.w3.org/TR/hr-time/#privacy-security. The test_timer function can detect this and gives a CoarseTimer error.

dhardy commented 6 years ago

Since @nagisa's report specifically mentions WASM, the issue is unfixable. As mentioned in the comment linked above WASM doesn't have a timer right now so there will be a compile error rather than a CoarseTimer error.

nagisa commented 6 years ago

What about WASM run outside of browser in e.g. node.js? There’s a way to get nanosecond-precision time in javascript through process.hrtime(), which is what I suppose code targetting wasm32-unknown-nodejs would call into as well.

Sure, we don’t have this target yet, but it would still be a good idea to keep this in mind for whenever rustc grows such a target.

dhardy commented 6 years ago

If by "keep in mind" you mean you wish to investigate yourself, go ahead. Otherwise it's only an open "issue". It's outside the scope of what I want to achieve myself so I will close this issue (there's already been a huge amount of scope creep); open an issue on the parent repo if you wish.