-
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
Adding zeroize
for BlockRng
and BlockRng64
#1374
Conversation
What about... adding pub struct BlockRng<R: BlockRngCore + ?Sized> {
results: R::Results,
index: usize,
/// The *core* part of the RNG, implementing the `generate` function.
#[cfg(not(feature = "zeroize"))]
pub core: R,
/// The *core* part of the RNG, implementing the `generate` function.
#[cfg(feature = "zeroize")]
pub core: R + ZeroizeOnDrop
} Just to ensure that the core implements it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By itself this code doesn't do anything at all, but having a feature-flag-dependant bound does complicate the API. We should consider simply making zeroize
a hard dependency.
@newpavlov thoughts please since you are also a maintainer of zeroize
?
/// Results element type, e.g. `u32`. | ||
#[cfg(not(feature = "zeroize"))] | ||
type Item; | ||
/// Results element type, e.g. `u32`. | ||
#[cfg(feature = "zeroize")] | ||
type Item: DefaultIsZeroes; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This has potential to cause unexpected broken builds.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my opinion, this is a wrong use of zeroize
. I don't think rand_core
needs any particular zeroize support. It's not worth to zeroize the index
field and zeroization of core
and results
fields should be handled by RNG implementation crates.
We don't care about the index, no, but what about |
Right now it's an associated type selected by an implementation crate, so it could use |
In the wrapper? This requires making |
No, it's not needed. The |
👍 |
Regarding #1348 and #934
This appears to work with my working branch of
chacha20
without any breaking changes for libraries that use a[Item; N]
. Also, I just discovered that using-C target-cpu=native
can optimize the code in such a way that the difference between the performance of using pointers and a buffer is about 0.5%... so I think I'm going to close out #1367