Expose PRNG functions

[masonforest]

What

Expose prng_reseed, u64_in_inclusive_range and vec_shuffle in the SDK.

Why

Exposing the PRNG functions in the SDK allows users to utilize randomness provided by the host in their smart contracts.

Known limitations

N/A

Close #969

---

I added tests for sha256 and verify_sig_ed25519 while I was in here. Let me know if those changes should be moved to a separate PR. I considered adding a PRNG module separate from the crypto module. I decided to keep them under crypto because there are only three functions. Also this is also similar getRandomValues is a function implemented within the Web Crypto API in browsers.

[jayz22]

Thanks for contributing @masonforest !
Just a couple of suggestions on env sameness check.
Overall it looks great and thanks for adding the additional tests.

[jayz22]

Thanks!

[graydon]

Sorry I'm late to the game on this one. The code of this is I think probably fine (I don't see anything problematic) but it's essential that the PRNG functions not live in a module called crypto, and that they instead be very clearly marked and documented as not providing cryptographically strong randomness of the sort cryptographic applications need. The P in PRNG and the term pseudo should be prominent, ideally every function should retain prng_... as a prefix, and documentation should repeat in big blinking letters that this is non-cryptographic, non-random, pseudorandom generation based on strictly public information.

In other words, the analogy you're making to WebCrypto's getRandomValues function -- which provides access to an OS's cryptographically strong random number source -- is dangerously wrong and we should be extremely clear to users to ensure they never make that mistake -- if they do they will fatally undermine their code.

I am happy to write a block comment describing the potential contexts where these functions are appropriate, but they are very inappropriate for cryptographic uses.

[masonforest]

Thank you for the feedback @graydon and thank you for all you've done for the open source community.

it's essential that the PRNG functions not live in a module called crypto

I moved these functions to a new module called Prng which is more appropriate and added the prng prefix to all of the functions.

I am happy to write a block comment describing the potential contexts where these functions are appropriate, but they are very inappropriate for cryptographic uses.

Could you post that comment here? Or feel free to add it yourself before merge. If there is somewhere this is documented which I can synthesize into a block comment I'd be happy to do that as well. Otherwise, I think I've done all I'm able to do here.

[leighmcculloch]

Thanks @masonforest for leading the charge on this. I'm going to make the changes above, and some other additions, and see if we can slide this into the next release.

i became an author

[dmkozh]

A general comment on the 'not secure' comments: while I understand what these are trying to convey, I think these are somewhat misleading and might lead to users using even worse approaches to randomness (e.g. seeding with ledger seq/timestamp as they do now).

I think what the comments mostly imply is that one shouldn't try to e.g. generate private keys with this. However, the main factor for that is the observability/reproducibility, which makes such usages impossible, no matter how good initial entropy is.

So I think it's worth to at least state that while this is imperfect, is is as good for randomness, as it can get given the restrictions of running in blockchain.

[leighmcculloch]

@graydon I'd appreciate your review of this, but I'm going to merge this now. Could circle back on it before we cut the next release?

Dismissing @graydon's comments because I think we've addressed the concern of signalling loud and clear that this is not a secure RNG, but a pseudo RNG.