Tony Arcieri

Per #855 I guess this shouldn't apply to anything in the `backend` module since that contains documentation which is published to docs.rs (or at least, we should wait for that...

We can do both, and have a type alias which is used to define the associated type

x25519-dalek has moved to: https://github.com/dalek-cryptography/curve25519-dalek/tree/main/x25519-dalek If you feel this issue has not yet been addressed, please request this issue be moved to that repo by leaving a comment, or open...

I really don't understand the motivation for this or why you're making it a public function.Something like this seems like a potential replacement for the existing `atomic_fence` function. Can you...

I'm not sure I understand the issue in https://github.com/RustCrypto/stream-ciphers/pull/491 or what it's even trying to do... zeroize the entire keystream it generates?

I'm still not sure I follow... what calls the `drop` method of `Generator`, and what's the problem with that? Where exactly is the "hack"?

How is... ```rust impl Drop for ChachaRng { fn drop(&mut self) { self.0.zeroize(); zeroize::observe(self); } } ``` ...any different from... ```rust impl Drop for ChachaRng { fn drop(&mut self) {...

So the problem is that `rand_core` is shipping a half-assed version of zeroize internally, and you want a band-aid to make it more robust?

Perhaps `rand_core` could just implement volatile writes? I'm not sure this proposed approach is any less of a hack than what exists currently. I do still think something like this,...

I'm a bit worried about the notion that there's a user pulling in one crate which is expected to do some otherwise insecure zeroing, then separately pulling in `zeroize` to...