Draft 02: More Security Considerations Randomness

[kyzer-davis]

As per Brendan Moran, notes on this will be delivered on the emailer to add to security considerations.

[kyzer-davis]

Possibly add reference that points too:
https://github.com/peteroupc/peteroupc.github.io/blob/master/random.md

[fabiolimace]

Perhaps you could use this sentence structure:

Implementations MUST ${verb_phrase} unless explicitly stated otherwise.

We see this structure in some specifications like this paragraph in RFC-4648:

Implementations MUST reject the encoded data if it contains
characters outside the base alphabet when interpreting base-encoded
data, unless the specification referring to this document explicitly
states otherwise.

In this case, a possible instance of this structure is:

Implementations MUST use a cryptographically-secure PRNG unless the documentation explicitly states otherwise.

In other words, if the implementer uses a Xorshift generator, they MUST make that clear in the documentation.

Does that make sense to you?

[kyzer-davis]

@fabiolimace the problem with using a MUST is there is no alternative and by adding "unless the documentation explicitly states otherwise" it sort of goes against the defined MUST.

SHOULD verbiage allows an alternative assuming you know the risks and have a good reason for doing so. e.g some old machine/library that can only do PRNG and not CSPRNG.

I also don't see any reference to RFC 4648 in our doc? What made you look at that spec?

[fabiolimace]

I understand. The SHOULD modal allows for an alternative approach.

I think it would be nice if the user of the code could know when the implementation isn't using a PRNG as recommended by the spec, especially when the code is closed and it's not possible to verify this. EDIT: sorry no one would do it.

By the way, I was reading this RFC-4648 and I randomly remembered this issue. Let's forget it. :)