Should next_u32, next_u64 and fill_bytes be equivalent?

[vks]

This is currently not specified in the documentation, but user might implicitly assume next_u32, next_u64 and fill_bytes are equivalent.

It might make sense to have them not equivalent:

• For some RNGs, next_u32 could be implemented using a faster mixing function than next_u64 (see splitmix64).
• For fast-key erasure RNGs, every call to fill_bytes will erase the key, making all three methods generate different bytes in general (see Key erasure AES variant #299).

Either way, whether they are equivalent or not should probably be documented.

[dhardy]

I believe this only affects three things:

• Reproducibility. For example, using next_u64 instead of fill_bytes for 8 bytes may or may not have different results. Also, if a user calls next_u32 followed by next_u64 but then switches the order of the two calls, this may or may not change the results. I think the current documentation basically says this stuff is up to the implementation.
• Quality. It's entirely possible for one method to produce low-quality output while another is better. If so this is probably a defect in the generator.
• Speed.

But given that the documentation of RngCore already says this, do we need to change anything?

Three different methods for generating random data are provided since the optimal implementation of each is dependent on the type of generator. There is no required relationship between the output of each; e.g. many implementations of fill_bytes consume a whole number of u32 or u64 values and drop any remaining unused bytes.

[vks]

But given that the documentation of RngCore already says this, do we need to change anything?

You are right, I somehow missed this part, sorry.