-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Verify JitterRng on hosted platforms #65
Comments
It sounds like it's impossible to get nanosecond-resolution time in Javascript anyway, so JitterRng is not useful for WASM. |
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 |
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 |
What about WASM run outside of browser in e.g. node.js? There’s a way to get nanosecond-precision time in javascript through 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. |
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. |
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:
The text was updated successfully, but these errors were encountered: