I strongly recommend building the padded room.
Average to good engineers (which I assume is intended to be a proxy for
“engineers who know about CSPRNGs and have considered their personal threat
model”) know enough to work out what kind of RNG they have available and to use
the one most appropriate to their use-case. That means if the default is “slow
and cryptographically-secure” but they need “fast and not
cryptographically-secure", they’ll know enough to opt-out. If the default is
“fast and not cryptographically-secure”, they’ll also know enough not to
opt-out. In all cases the cost to this engineer of using the default is 20
minutes (the time required to find out what the default is), and the cost of
using not-the-default is 20 minutes and a few lines of code. Marginal.
The hypothetical least competent engineer, by definition, does not know enough
to check what RNG they have available. If the default is “slow”, they’ll get
“slow”: in the worst case, their code will be slower than it needs to be
because they could have used “fast” instead. If the default is “fast”, they’ll
get “fast”: in the worst case, their code will be vulnerable to attack. This
user will never swap away from the default, so the question is which failure
mode is preferable. I’d say it seems pretty obvious that “my program is slow”
is a better failure mode than “my program is vulnerable to data exfiltration”.
It’s completely worth it, IMO, to cost engineers that know what they’re doing
with an RNG a small amount of time to save us from the errors made by engineers
who don’t know. But it’s a false dichotomy to say that not having a padded room
is only a danger to the engineer writing the program: as Equifax has
demonstrated, we’re all on the hook for their work.
> On 11 Oct 2017, at 10:02, Kevin Nattinger via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> IMO, if we have the extensions on Int(eger)/Float(ingPoint)/Array
> (RandomAccessSequence?), they should just be for convenience and with a sane
> default RNG*, and users that need more should just use methods on the RNGs
> directly.
>
> *: I don't think the default necessarily needs to be a CSRNG; if there's a
> fast one, fine. Are we building a padded room for the least competent
> engineer or a tool for the average to good engineer to use efficiently?
>
>> On Oct 11, 2017, at 9:08 AM, Jeremy Pereira via swift-evolution
>> <swift-evolution@swift.org> wrote:
>>
>> I’m a bit late to the party on this one, but has anybody considered the fact
>> that you need a way for the user of the interface to override the default
>> random number source?
>>
>> For example, some applications require a cryptographically secure source,
>> others might eschew perfect entropy for speed. Still others might want
>> repeatability e.g. Minecraft lets you enter a seed when it does the World
>> generation so you can go back and play the same World again and again. For
>> unit testing, you might want to replace the random number generator with a
>> sequence of hard coded values so you can exactly control the code path that
>> the test takes.
>>
>> So if you have a protocol that describes an API for generating random
>> numbers called RNG, the extension on Int would look something like
>>
>> extension Int {
>> init(randomInRange: Countable{Closed}Range<Int>, rng: RNG = /* a CS random
>> number generator */)
>> }
>>
>>> On 7 Oct 2017, at 04:24, Chris Lattner via swift-evolution
>>> <swift-evolution@swift.org> wrote:
>>>
>>>
>>>> On Oct 5, 2017, at 10:58 AM, Nate Cook via swift-evolution
>>>> <swift-evolution@swift.org> wrote:
>>>>
>>>> The edge case is really the same (empty ranges), it’s about what we do
>>>> with the edge case. If we include the methods on integer types, usage will
>>>> look like this:
>>>>
>>>> let x = Int.random(in: 0..<5) // 3
>>>> let y = Int.random(in: 0..<0) // runtime error
>>>>
>>>> If we only have the collection methods, usage will look like this:
>>>>
>>>> let x = (0..<5).random()! // 3
>>>> let y = (0..<0).random()! // runtime error
>>>
>>> These aren’t the forms I was suggesting, what I meant was:
>>>
>>> extension Int {
>>> init(randomInRange: Countable{Closed}Range<Int>)
>>> }
>>>
>>> which gives:
>>> let x = Int(randomInRange: 0..<5)
>>>
>>> The point of this is that you’re producing an Int (or whatever type).
>>> Regardless of whether the initializer is failable or not, this is the
>>> preferred way of creating a new value with some property: it is an
>>> initializer with a label.
>>>
>>> -Chris
>>>
>>>
>>> _______________________________________________
>>> 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
