Revise "not a crypto library" policy and SECURITY.md

[dhardy]

Attempt to slightly improve the wording left by #1514.

See also Reddit discussion.

[benjamin-lieser]

Users are expected to determine for themselves
whether rand's functionality meets their own security requirements.

I really like this, because it describes very well what rand is. It certainly can be used for crypto, but it requires the user to read the doc carefully and decide which part of rand to use.

[dhardy]

@newpavlov I updated the section on WASM. BTW the WASI & Emscripten links in the getrandom docs both appear to be outdated.

[dhardy]

More significant revisions of SECURITY.md included (some content copied from getrandom).

Also CC @josephlr

Also CC @dcmiddle, @vks and @tarcieri who commented on the previous PR.

[newpavlov]

BTW the WASI & Emscripten links in the getrandom docs both appear to be outdated.

Update PR: rust-random/getrandom#597

[dcmiddle]

Am I reading this correctly ...
Default means it will be seeded securely and automatically without any work by the caller.
SeedableRng relies on the caller providing a seed that is cryptographically secure from some other source, possibly from another RNG.

If so maybe this is more clear to have one SeedableRng bullet...

Suggested change

	- If the RNG implements `Default`, it may be default-constructed
	- If the RNG implements `SeedableRng`, it may be constructed and seeded using
	`SeedableRng::from_seed` with a cryptographically secure seed value
	- If the RNG implements `SeedableRng`, it may be constructed and seeded from
	another RNG which is itself cryptographically secure
	- If the RNG implements `Default`, it may be default-constructed
	- If the RNG implements `SeedableRng`, it may be constructed and seeded using
	`SeedableRng::from_seed` with a cryptographically secure seed value, possibly
	from another RNG which is itself cryptographically secure

[dhardy]

OsRng and ThreadRng can be default constructed and be secure.

Another way to read this is that a CryptoRng should not support Default if the result would be insecure.

I admit that there is potential for confusion here. Perhaps I should add to the first point:

Note that generators should only implement Default where a default-constructed instance is no more predictable than a securely seeded instance; for example OsRng (which is a stateless) supports Default construction.

[dhardy]

Perhaps I should also add doc to the *CryptoRng traits on Default.