> Le 1 oct. 2017 à 07:24, Xiaodi Wu <xiaodi...@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
