FWIW, I agree with Ben here: if the true cryptographically secure random numbers force this complexity onto users, then we should settle for something close but not quite that bulletproof.
-Chris > On Oct 4, 2017, at 6:15 PM, Xiaodi Wu via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On Wed, Oct 4, 2017 at 18:42 Ben Cohen <ben_co...@apple.com> wrote: >> >>> On Oct 4, 2017, at 9:20 AM, Xiaodi Wu via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> If trapping is OK, then surely returning Optional is superior; any user who >>> is OK with trapping can make that decision for themselves by writing >>> `random()!`. Everyone else can then see clearly that trapping is a >>> possibility, which is important. >> >> It’s important not to underestimate both the extent to which using `!` >> scares people, _and_ the extent to which beginners use it inappropriately. >> Both of these mean that it’s very important the standard library not include >> anything that makes force-unwrapping a common/routine operation (looking at >> you, UnsafeBufferPointer.baseAddress). > > I agree; however, if given the choice of `random()` potentially trapping or > `random()!` potentially trapping, I would argue that the latter is strictly > superior to the former. If the latter option scares people, the former should > scare people more, and its nicer appearance is a bug, not a feature. > >> Given that arc4random, the recommended source of random numbers on Darwin, >> is always successful, requiring a force-unwrap when the user is using the >> default source doesn’t seem like the right move. > > Always successful for some values of successful. We cannot design our way out > of physics. > > Chris has indicated—and I agree—that the default random facilities should do > the right thing in terms of cryptographic security. Since arc4random is > guaranteed to be successful but the underlying hardware cannot be guaranteed > to always have the entropy to make it secure, it must follow that some > invocations of arc4random produce results unsuitable for cryptographic use. > > To reiterate, this is one of several options. When there isn’t enough entropy > for secure random numbers, the function can: > > - block > - return an insecure result > - return nil > - throw > - trap > > This is an exhaustive list, as far as I can tell. None of these options are > entirely desirable, but it is inescapable that one of these is the default, > go-to design for Swift; of course, alternatives can be offered, but the > question is, what should we tell the novice user to reach for? > >> >>>> On Wed, Oct 4, 2017 at 11:09 David Waite <da...@alkaline-solutions.com> >>>> wrote: >>>> >>>>> On Oct 4, 2017, at 4:05 AM, Xiaodi Wu via swift-evolution >>>>> <swift-evolution@swift.org> wrote: >>>>> >>>>> >>>>> I agree with Felix’s concern, which is why I brought up the question, but >>>>> ultimately the issue is unavoidable. It’s not down to global instance or >>>>> not. If your source of random numbers is unseedable and may mix in >>>>> additional entropy at any time, then it may fail at any time because when >>>>> a hardware restart might happen may be transparent to the process. The >>>>> user must know about this or else we are laying a trap (pun intended). >>>> >>>> I'm of the mindset (which might be controversial) that we should attempt >>>> to expose legacy and cryptographically secure random number generators, >>>> even a mixed algorithmic/entropy source like /dev/urandom, but that we >>>> should not expose /dev/random at all. If someone is trying to use >>>> /dev/random legitimately (such as to generate one-time-pads) they will >>>> have to take into account that systems like linux still use algorithmic >>>> entropy to drive /dev/random. If someone really has this sort of use case, >>>> they have exceeded the bounds of the system randomness protocol. >>>> >>>> Without /dev/random support as a requirement, the only failure cases I >>>> know of are reading too much random data in one operation (which could be >>>> solved by repeated calls) or calling before sufficient entropy has been >>>> set up in /dev/urandom (such as in a system startup process). I'd be fine >>>> with the second one being a special case, and such systems needing to know >>>> use of the /dev/urandom -backed generator before randomness has been set >>>> up will trap or return predictable information on certain platforms. >>>> >>>> -DW >> >>> _______________________________________________ >> >>> >>> 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
