Feature Discussion: Generic Seeds

[onkoe]

Before coming across this great library, I was about to spin my own noise crate! Thanks for saving me the hassle - this seems fantastic!

However, I do have a weird feature request that only might make sense. I would love to be able to provide theoretically infinite seeds, such as vectors/arrays of values - or even a string slice, to the generator.

Do you know if this is viable from an implementation standpoint? You don't need to worry about implementing it - I don't think it's widely interesting. However, I'm definitely interested!

From what I can tell, rand_chacha happily implements Seed for any byte slice, so you can give it any kind of data to get random data back. That should allow it to work for sources that use core::utils::ptable::PermutationTable, at least if seed also allowed anything serializable to [u8].

Once again, thanks for the great library! 🦀✨

[cookiephone]

Thanks for the praise! Currently, seeding is implemented using ChaCha12Rng::seed_from_u64. As you said, this could be changed to support any byte slice in principle.

One thing to keep in mind however is, that there are still a theoretically finite amount of possible configurations of the permutation table, even if the seed was more flexible. Specifically it would be the factorial of the permutation table size. This is set through a constant to 256, meaning a finite set of 256! possible permutations.

In that sense, it might indeed make sense to allow for more flexibility when seeding. After all u64 does not nearly cover enough states to do a permutation table of that size justice.

[cookiephone]

Upon further inspection, chacha is using 32 byte seeds. This is by no means perfectly generalizable, and without generic const expressions I don't think I can create a nice API for more genuinely mostly arbitrary seeds. However, I have whipped up something that at least exposes the full API of the underlying chacha RNG. That means, seeds can still be u64, but may also be of type [u8; 32]. With this, the RNG can be harnessed to its full potential, even though the user is still responsible for actually building a suitable 32 byte seed should they choose to not use a u64.

This is done by introducing a Seed trait which is implemented for u64 and [u8; 32] respectively. I then use that in the permutation table implementation to construct the RNG with the appropriate seeding function.

I'll wait a bit to see if there are some more suggestions or ideas here. If not, I'll go ahead and merge+publish this with the minor semver bump it entails as version 1.1.2 :)