[swift-evolution] [Proposal] Random Unification

[Xiaodi Wu]

On Wed, Dec 20, 2017 at 13:13 Jens Persson <jens at bitcycle.com> wrote:

> Oh OK, I must have misunderstood this thread:
>
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171204/042034.html
> (
> "The strong opinion of the core team is that such an API should *not* be
> designed with an attempt to service people writing crypto code."
> "It is general goodness if generality for crypto use cases somehow falls
> out of the design.  However, the design for general use shouldn’t suffer
> because of that goal."
> )
>
> I assumed that the Random API would save the user from the trouble of
> making a good choice and implementation (fast and good quality) of a
> "standard" general purpose prng (as well as maybe a cryptographically
> secure one).
>

Providing a cryptographically secure PRNG is necessary but not sufficient
for cryptography. However, many ordinary uses of a general purpose PRNG
will assume that future “random” numbers cannot be guessed by observing a
small number of previous ones. Xoroshiro has its uses, but it would not be
the ideal basis for a general purpose PRNG, especially since we have easy
access to true randomness.

Also, the most commonly recommended ways of converting from eg 64 random
> bits to an int range or a floating point range are unnecessarily bad and
> slow, so I figured the webpage was worth a read, in addition to C++
> stdlib's implementation.
>

I agree it will be critical to ensure that random floating-point values are
truly uniform. All implementors would do well to study the state of the art.


> /Jens
>
>
> On Wed, Dec 20, 2017 at 4:55 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
>> xoroshiro128+ is not a cryptographically secure algorithm and would not
>> be incorporated into the Random API, though it is trivial to implement your
>> own; the proposal outlines sources of randomness that are cryptographically
>> secure.
>>
>>
>>
>> On Wed, Dec 20, 2017 at 09:46 Jens Persson via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>> I'd like to add a pointer to the information here:
>>> http://xoroshiro.di.unimi.it
>>>
>>> since AFAICS, the xoroshiro128+ generator and the method of "Generating
>>> uniform doubles in the unit interval" should probably be implemented in any
>>> modern general purpose Random API.
>>>
>>> Please correct me if there are more up to date (higher quality and
>>> faster) general purpose generators and ways of converting UInt64 bit
>>> patterns to floating point [0, 1).
>>>
>>> /Jens
>>>
>>>
>>>
>>> On Sun, Dec 3, 2017 at 4:50 AM, Dave Abrahams via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>>
>>>> I don’t have much to say about this other than that I think the
>>>> discussion seems way too narrow, focusing on spelling rather than on
>>>> functionality and composability.  I consider the “generic random number
>>>> library” design to be a mostly-solved problem, in the C++ standard
>>>> library (http://en.cppreference.com/w/cpp/numeric/random).  Whatever
>>>> goes into the Swift standard library does not need to have all those
>>>> features right away, but should support being extended into something
>>>> having the same general shape. IMO the right design strategy is to *implement
>>>> and use* a Swift version of C++’s facilities and only then consider
>>>> proposing [perhaps a subset of] that design for standardization in Swift.
>>>>
>>>> Sent from my iPad
>>>>
>>>> On Dec 2, 2017, at 5:12 PM, Kyle Murray via swift-evolution <
>>>> swift-evolution at swift.org> wrote:
>>>>
>>>>
>>>> On Dec 2, 2017, at 6:02 PM, Xiaodi Wu via swift-evolution <
>>>> swift-evolution at swift.org> wrote:
>>>>
>>>> Instead, we ought to make clear to users both the features and the
>>>> limitations of this API, to encourage use where suitable and to discourage
>>>> use where unsuitable.
>>>>
>>>>
>>>> I like that you're considering the balance here. I've been lightly
>>>> following this thread and want to add my thoughts on keeping crypto and
>>>> pseudorandomness out of the name of at least one random API intended
>>>> for general use.
>>>>
>>>> For someone who doesn't know or care about the subtleties of insecure
>>>> or pseudorandom numbers, I'm not sure that the name insecureRandom is
>>>> effectively much different than badRandom, at least in terms of the
>>>> information it conveys to non-experts. To Greg's point, that's the opposite
>>>> of the signal that the API name should suggest because it's what most
>>>> people should use most of the time. As you say, this API is being designed
>>>> for general use.
>>>>
>>>> There's a cost to adding extra complexity to names, too. I don't think
>>>> it's far-fetched to suspect that people who find insecureRandom in an
>>>> autocomplete listing or search will think "Where's the plain random
>>>> function?"... and then go looking for a community extension that will
>>>> inevitably provide a trivial alias: func random() { return
>>>> insecureRandom() }. That's the sort of adoption I'd expect from
>>>> something for new programmers, like Swift Playgrounds. Someone's
>>>> introduction to randomness in programming should probably involve no more
>>>> than a straightforward mapping from the elementary definition, rather than
>>>> forcing a teaching moment from more advanced math.
>>>>
>>>> I think there are better places for caveat information than in the API
>>>> names themselves; documentation being one clear destination. This is in
>>>> contrast with Unsafe*Pointer, where the safety element is critical
>>>> enough to be elevated to be more than caveat-level information. You can go
>>>> really far and create really cool things before these caveats start to
>>>> apply. Using randomness as a black box in an intro programming environment
>>>> seems like a much more common scenario than someone attempting to roll
>>>> their first crypto by only reading API names and hoping for the best.
>>>>
>>>> -Kyle
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171220/195ae0e2/attachment.html>