Core Team vs Random number API discussion

Hi All,

FYI, the Core Team had a brief discussion about the direction of the random number API design being discussed.

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. Such clients will have requirements that are difficult to predict or that are hard to provide in general (e.g. “must run in constant time”). These clients are also relatively few, compared the community of people who benefit from a good "general use" random number API.

As such, the core team strongly encourages the random number API design process to focus on building the best possible "general use" API, without worrying about the needs of crypto experts.

Beyond that, the core team did not discuss what the exact shape of the API should look like: it believes the community should continue hashing it out. We just wanted to remove one big constraint from that design process.

Thanks,

-Chris & Swift Core Team

I agree with this decision, but I would also add the provision that the random number API be designed in such a way that those with special crypto needs can easily extend the existing random number framework to meet their needs. (Specify their own seed, use their own crypto implementation, etc).

I’m sure this is already being considered having read most of the Random Unification email chain, but just thought I’d make sure it was specifically mentioned. I’d hate to leave a group of coders out in the dark (no matter how small that group may be).

···

On Dec 6, 2017, at 4:16 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Hi All,

FYI, the Core Team had a brief discussion about the direction of the random number API design being discussed.

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. Such clients will have requirements that are difficult to predict or that are hard to provide in general (e.g. “must run in constant time”). These clients are also relatively few, compared the community of people who benefit from a good "general use" random number API.

As such, the core team strongly encourages the random number API design process to focus on building the best possible "general use" API, without worrying about the needs of crypto experts.

Beyond that, the core team did not discuss what the exact shape of the API should look like: it believes the community should continue hashing it out. We just wanted to remove one big constraint from that design process.

Thanks,

-Chris & Swift Core Team

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

So, my read of the decision is that when the core teams says the API should
be designed “without worrying about the needs of crypto experts,” they mean
exactly that we should stop worrying about how easy or hard it is to extend
for those users.

···

On Wed, Dec 6, 2017 at 18:34 Jacob Williams via swift-evolution < swift-evolution@swift.org> wrote:

I agree with this decision, but I would also add the provision that the
random number API be designed in such a way that those with special crypto
needs can easily extend the existing random number framework to meet their
needs. (Specify their own seed, use their own crypto implementation, etc).

I’m sure this is already being considered having read most of the Random
Unification email chain, but just thought I’d make sure it was specifically
mentioned. I’d hate to leave a group of coders out in the dark (no matter
how small that group may be).

> On Dec 6, 2017, at 4:16 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:
>
> Hi All,
>
> FYI, the Core Team had a brief discussion about the direction of the
random number API design being discussed.
>
> 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. Such
clients will have requirements that are difficult to predict or that are
hard to provide in general (e.g. “must run in constant time”). These
clients are also relatively few, compared the community of people who
benefit from a good "general use" random number API.
>
> As such, the core team strongly encourages the random number API design
process to focus on building the best possible "general use" API, without
worrying about the needs of crypto experts.
>
> Beyond that, the core team did not discuss what the exact shape of the
API should look like: it believes the community should continue hashing it
out. We just wanted to remove one big constraint from that design process.
>
> Thanks,
>
> -Chris & Swift Core Team
>
>
> _______________________________________________
> 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

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.

-Chris

···

On Dec 6, 2017, at 3:47 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

So, my read of the decision is that when the core teams says the API should be designed “without worrying about the needs of crypto experts,” they mean exactly that we should stop worrying about how easy or hard it is to extend for those users.

On Wed, Dec 6, 2017 at 18:34 Jacob Williams via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I agree with this decision, but I would also add the provision that the random number API be designed in such a way that those with special crypto needs can easily extend the existing random number framework to meet their needs. (Specify their own seed, use their own crypto implementation, etc).

I’m sure this is already being considered having read most of the Random Unification email chain, but just thought I’d make sure it was specifically mentioned. I’d hate to leave a group of coders out in the dark (no matter how small that group may be).

> On Dec 6, 2017, at 4:16 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
> Hi All,
>
> FYI, the Core Team had a brief discussion about the direction of the random number API design being discussed.
>
> 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. Such clients will have requirements that are difficult to predict or that are hard to provide in general (e.g. “must run in constant time”). These clients are also relatively few, compared the community of people who benefit from a good "general use" random number API.
>
> As such, the core team strongly encourages the random number API design process to focus on building the best possible "general use" API, without worrying about the needs of crypto experts.
>
> Beyond that, the core team did not discuss what the exact shape of the API should look like: it believes the community should continue hashing it out. We just wanted to remove one big constraint from that design process.
>
> Thanks,
>
> -Chris & Swift Core Team
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

So, my read of the decision is that when the core teams says the API should be designed “without worrying about the needs of crypto experts,” they mean exactly that we should stop worrying about how easy or hard it is to extend for those users.

Touche. I guess it does mean that, I think it’s a shame to not make something like this extensible for pro users. However since it is a small subset of people who would probably be able to create their own crypto stuff anyways I guess it really doesn’t matter how extensible it is and that the focus should be to get something that *most* people will be able to use easily.

···

On Dec 6, 2017, at 4:47 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Wed, Dec 6, 2017 at 18:34 Jacob Williams via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I agree with this decision, but I would also add the provision that the random number API be designed in such a way that those with special crypto needs can easily extend the existing random number framework to meet their needs. (Specify their own seed, use their own crypto implementation, etc).

I’m sure this is already being considered having read most of the Random Unification email chain, but just thought I’d make sure it was specifically mentioned. I’d hate to leave a group of coders out in the dark (no matter how small that group may be).

> On Dec 6, 2017, at 4:16 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
> Hi All,
>
> FYI, the Core Team had a brief discussion about the direction of the random number API design being discussed.
>
> 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. Such clients will have requirements that are difficult to predict or that are hard to provide in general (e.g. “must run in constant time”). These clients are also relatively few, compared the community of people who benefit from a good "general use" random number API.
>
> As such, the core team strongly encourages the random number API design process to focus on building the best possible "general use" API, without worrying about the needs of crypto experts.
>
> Beyond that, the core team did not discuss what the exact shape of the API should look like: it believes the community should continue hashing it out. We just wanted to remove one big constraint from that design process.
>
> Thanks,
>
> -Chris & Swift Core Team
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution