-
Notifications
You must be signed in to change notification settings - Fork 432
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
Investigate/implement Randen RNG #462
Comments
On the negative side, it is very new, the paper is even not yet published, it is only fast with hardware support, and I suppose it needs a couple of years to build up trust in it. Maybe we should hold off on getting exited. |
According to a Reddit comment, it works for most hardware that is less than 10 years old. |
Without much security review I don't think it has a lot of use to us (even if it is fast), so opening this is premature I guess. |
If it is faster than PCG and similar, it is still interesting as a non-CSPRNG! |
Yes, but with the caveat that it is more complicated to implement and has certain hardware dependencies. I'm not saying we won't consider including an implementation in Rand (it's definitely interesting), but it's not of particular interest (and we have too many open issues). |
Agreed, this issue is kind of a duplicate of #299 anyway. |
The Randen RNG is supposed to be secure, very fast, relatively small state (apparently 264 bytes) and backtracking resistant, which could make it a good candidate for
ThreadRng
.It would of course be preferable to have a Rust implementation.
We should further investigate the security claims before use.
The text was updated successfully, but these errors were encountered: