[swift-evolution] [Proposal] Random Unification

[Félix Cloutier]

> Le 1 oct. 2017 à 07:24, Xiaodi Wu <xiaodi.wu at gmail.com> a écrit :
> It seems to me that a CSPRNG interface is useful if you need crypto-secure random numbers, but you can trust input from sources that don't come with the guarantees of the global CSPRNG, and from algorithms that you can't exhaustively list in advance. Does that sound right? Do you have a use case in mind, or an example of an application that has similar requirements?
> 
> TOTP, used for two-factor authentication, takes a shared secret as seed and generates a deterministic sequence of cryptographically secure one-time passwords.

That case was specifically called out in the message you were replying to: any algorithm would have to be agreed upon. What is the benefit of a CSPRNG protocol in that case? You know exactly which random number generator you'll be using, and in fact, you might be using one that isn't even considered crypto-secure anymore (like a hypothetical RC4Random would be, if Swift had been around for long enough) because users haven't upgraded their TOTP yet.

Besides, AFAIK, the common implementation of TOTP computes the HMAC of the timestamp with the shared secret as the key and doesn't involve random numbers. Do you have another example?

>> Yes, but again, what do you think of the possible Swift API design choices to accommodate these errors? We have to pick one, but none of them are very appealing.
> 
> Is that still the right thing to do then? How do these not very appealing alternatives compare against instance methods on Random objects, like random.any(1...6)?
> 
> I think I’m not stating my question clearly. Regardless of how you spell it, what do you think is the optimal behavior when requesting a random number fails for lack of entropy? Should we return nil, throw, trap, or block? One of these has to happen either when you try to initialize a generator or when you try to first use the global/thread-local generator.

With a design where the random number generator creates the number, then if you have a PRNG instance, you will always be able to generate a number. Requesting a random number can't fail for lack of entropy in that design.

The only failable part would be getting the PRNG instance: that never happens for a PRNG that you can seed, and the global crypto-secure one can go behind an Optional, or a Future if we want a waitable handle.

Félix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171001/1c5297fe/attachment.html>