On Wed, Dec 20, 2017 at 13:13 Jens Persson <j...@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...@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@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@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@swift.org> wrote: >>>> >>>> >>>> On Dec 2, 2017, at 6:02 PM, Xiaodi Wu via swift-evolution < >>>> swift-evolution@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@swift.org >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >> >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
