ietf
[Top] [All Lists]

Re: Randomness sources for the IETF 2015-2016 Nomcom Selection

2015-06-23 15:51:57
On Tue, Jun 23, 2015 at 2:40 PM, Christian Huitema 
<huitema(_at_)microsoft(_dot_)com>
wrote:

Picking out of a hat is random enough. It's just not very verifiable.
I'm not saying
that Harald would manipulate the draw, but some people might and we won't
be able to prove to them that the process was not manipulated.

This thread is really fun. Don't we all love engineering and
over-engineering?

As Yoav said, the process was designed to provide a verifiable equivalent
to picking names from a hat. The main thread here is manipulation by the
person doing the picking, so we designed a verifiable process. And since we
are engineers, we had some fun picking verifiable outside sources of
randomness. But really, this is about emulating picking from a hat in a way
that let any observer verify the picking.

In theory, since we are picking 10 names out of a pool maybe 100 to 200
volunteers at most, we would need 44 to 55 bits of entropy. The lotteries
in Harald's list provide about 74 such bits. The debt numbers' entropy are
less easy to compute, and depending on your assumptions add 10 to 50 other
bits. As many have pointed out, it is extremely unlikely that any of those
numbers might be manipulated for the sole purpose of influencing the nom
com selection. So basically, we are good.

But it is fun.


Remember that we are a standards body and that part of the point here is to
develop building blocks that other people can build on.

Let us for the sake of argument assume that the NIST source is perfectly
random.

Let us further assume that collusion between NIST and some subset of n IETF
persons can be considered 'infeasible'.

I think that we can pretty easily develop a protocol involving commitments
that provides a provably fair process even if just one of the participants
does not default.


Of course this is over-engineered for picking the NOMCON. But it isn't
over-engineered for purposes such as picking crypto constants.
<Prev in Thread] Current Thread [Next in Thread>