SecureZeroMemory with RtlGenRandom and Warnings

[AtropineTears]

Not sure if this is the correct place to discuss this or whether this is a problem at all.

In Microsoft's documentation for RtlGenRandom, it states:

When you have finished using the random number, free the RandomBuffer buffer by calling the SecureZeroMemory function.

Is this done/called automatically in this crate?

Also, it has a warning:

The RtlGenRandom function is available for use in the operating systems specified in the Requirements section. It may be altered or unavailable in subsequent versions. Instead, use the CryptGenRandom function.

And CryptGenRandom is deprecated. I already read the issue thread about why you don't want to use BCryptGenRandom rn because it doesn't support Windows XP, but I honestly think the change should be made soon. BCryptGenRandom works on minimum of Windows Vista.

[josephlr]

Is this done/called automatically in this crate

Nope, this crate specifically implements one function:

pub fn getrandom(dest: &mut [u8]) -> Result<(), Error>

and that's it. Things like SecureZeroMemory are orthogonal to this crate, and would be be handled by a "Secure Buffer Mangement" crate like secstr. That crate's SecVec<u8> implements BorrowMut<[u8]>, so it can be used with getrandom like any u8 array or Vec<u8>.

Both securely managing secrets in memory and generating good random bytes are tricky problems, but they are different problems. Keeping them in separate crates seems to be the best bet.

And CryptGenRandom is deprecated. I already read the issue thread about why you don't want to use BCryptGenRandom rn because it doesn't support Windows XP, but I honestly think the change should be made soon. BCryptGenRandom works on minimum of Windows Vista.

I think discussion around this are best handled in #65 (so that everyone involved will see it).

[newpavlov]

Regarding deprecation of RtlGenRandom see this message. There is a proposal to use getrandom inside std, so as long as Windows XP (and preferably Vista) support is not officially dropped by Rust, we have to stay conservative.

I think we can close this issue in favor of #65?

[AtropineTears]

Yes, I'll close the issue and any further discussion can be done on #65