I recently proposed a patch to change the documentation of
SystemRandomNumberGenerator to affirmatively state that it is cryptographically secure on all platforms, and that it will crash on any platform where it cannot provide that guarantee.
The aspiration is that this RNG should be cryptographically secure, provide reasonable performance, and should be thread safe. If a vendor is unable to provide these goals, they should document it clearly.
This is a pretty unfortunate clause, so I'd like to get feedback on whether the community (and in particular the core team) are interested in a pitch to supplement SE-0202 that improves matters.
My primary issue with this language is that it explicitly allows for
SystemRandomNumberGenerator to be backed by a non-CSPRNG implementation. This has the implicit effect of meaning that
SystemRandomNumberGenerator's suitability for cryptographic use applies on a per-platform basis. As a result, any library wanting to use a CSPRNG is forced to make a choice between three options:
- Guard the use of
if @availableguards to attempt to restrict its use to platforms and Swift versions where the standard library guarantees that
SystemRandomNumberGeneratoris a CSPRNG.
- Copy the code of
SystemRandomNumberGeneratorand reinvent it in their library, ensuring that it will be a CSPRNG whenever their library is built.
SystemRandomNumberGeneratorand hope that no platform is ever written that doesn't make
SystemRandomNumberGeneratora CSPRNG, or their library will silently fail to meet its security requirements.
So I'd like to clarify: is it really the intent that
SystemRandomNumberGenreator is not supposed to guarantee cryptographic security? If that is, is there interest in an alternative version in the standard library that does provide that guarantee?