> Le 27 sept. 2017 à 17:29, Xiaodi Wu <xiaodi...@gmail.com> a écrit :
>
> What I was trying to respond to, by contrast, is the design of a hierarchy of
> protocols CSPRNG : PRNG (or, in Alejandro's proposal, UnsafeRandomSource :
> RandomSource) and the appropriate APIs to expose on each. This is entirely
> inapplicable to your examples. It stands to reason that a non-instantiable
> source of random numbers does not require a protocol of its own (a
> hypothetical RNG : CSPRNG), since there is no reason to implement (if done
> correctly) more than a single publicly non-instantiable singleton type that
> could conform to it. For that matter, the concrete type itself probably
> doesn't need *any* public API at all. Instead, extensions to standard library
> types such as Int that implement conformance to the protocol that Alejandro
> names "Randomizable" could call internal APIs to provide all the necessary
> functionality, and third-party types that need to conform to "Randomizable"
> could then in turn use `Int.random()` or `Double.random()` to implement their
> own conformance. In fact, the concrete random number generator type doesn't
> need to be public at all. All public interaction could be through APIs such
> as `Int.random()`.
If there is globally-available CSPRNG that people are encouraged to use, what
is the benefit of a CSPRNG : PRNG hierarchy? What is the benefit of clearly
identifying an algorithm as crypto-secure if the recommendation is that you use
*the* crypto-secure object/functions?
> Again, I'm not only talking about urandom. As far as I'm aware, every API to
> retrieve cryptographically secure sequences of random bits on every platform
> for which Swift is distributed can potentially return an error instead of
> random bits. The question is, what design for our API is the most sensible
> way to deal with this contingency? On rethinking, I do believe that
> consistently returning an Optional is the best way to go about it, allowing
> the user to either (a) supply a deterministic fallback; (b) raise an error of
> their own choosing; or (c) trap--all with a minimum of fuss. This seems very
> Swifty to me.
With Linux's getrandom, if you read from urandom (the default) and ask for as
much or less than 256 bytes, the only possible error is that urandom hasn't
been seeded <http://man7.org/linux/man-pages/man2/getrandom.2.html>. (With more
than 256 bytes, it also becomes possible for the system call to be interrupted
by a signal.) OpenBSD's getentropy is literally just arc4random running in the
kernel <https://github.com/openbsd/src/blob/master/sys/dev/rnd.c#L889>, and
will only fail if you ask for more than 256 bytes because it is a hard-coded
limit.
Ironically, I don't know how you get entropy on Darwin. If it's more failable
that this, I'd argue that it's time to improve a bit...
Félix
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
