File: rfc2777.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (899 lines) | stat: -rw-r--r-- 30,064 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899






Network Working Group                                    D. Eastlake 3rd
Request for Comments: 2777                                      Motorola
Category: Informational                                    February 2000


              Publicly Verifiable Nomcom Random Selection

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   This document describes a method for making random selections in such
   a way that the unbiased nature of the choice is publicly verifiable.
   As an example, the selection of the voting members of the IETF
   Nominations Committee from the pool of eligible volunteers is used.
   Similar techniques would be applicable to other cases.

Acknowledgement

   Matt Crawford made major contributions to this document.

Table of Contents

   1. Introduction............................................2
   2. General Flow of a Publicly Verifiable Process...........2
   2.1 Determination of the Pool..............................2
   2.2 Publication of the Algorithm...........................2
   2.3 Publication of Selection...............................3
   3. Randomness..............................................3
   3.1 Sources of Randomness..................................3
   3.2 Skew...................................................4
   3.3 Entropy Needed.........................................4
   4. A Suggested Precise Algorithm...........................5
   5. Fully Worked Example....................................6
   6. Security Considerations.................................7
   7.  Reference Code.........................................8
   Appendix: History of NomCom Member Selection..............14
   References................................................15
   Author's Address..........................................15
   Full Copyright Statement..................................16



Eastlake                     Informational                      [Page 1]

RFC 2777              Verifiable Random Selection          February 2000


1. Introduction

   Under the IETF rules, each year 10 persons are randomly selected from
   among the eligible persons who volunteer to be the voting members of
   the nominations committee (NomCom) to nominate members of the
   Internet Engineering Steering Group (IESG) and the Internet
   Architecture Board (IAB) [RFC 2727].  The number of eligible
   volunteers in recent years has varied in the approximate range of 40
   to 60.

   It is highly desireable that the random selection of the voting
   NomCom be done in a unimpeachable fashion so that no reasonable
   charges of bias or favoritism can be brought.  This is for the
   protection of the IETF from bias and protection of the administrator
   of the selection (currently, the appointed non-voting NomCom chair)
   from suspicion of bias.

   A method such that public information will enable any person to
   verify the randomness of the selection meets this criterion.  This
   document gives an example of such a method.

2. General Flow of a Publicly Verifiable Process

   In general, a selection of NomCom members publicly verifiable as
   unbiased or similar selection could follow the three steps given
   below.

2.1 Determination of the Pool

   First, you need to determine the pool from which the selection is to
   be made.

   Volunteers are solicited by the appointed (non-voting) NomCom chair.
   Their names are then passed through the IETF Secretariat to check
   eligibility.  (Current eligibility criteria relate to IETF meeting
   attendance, records of which are maintained by the Secretariat.)  The
   full list of eligible volunteers is made public early enough that
   there is a reasonable time to resolve any disputes as to who should
   be in the pool, probably a week to ten days before the selection.

2.2 Publication of the Algorithm

   The exact algorithm to be used, including the public future sources
   of randomness, is made public.  For example, the members of the final
   list of eligible volunteers are ordered by publicly numbering them,
   several public future sources of randomness such as government run





Eastlake                     Informational                      [Page 2]

RFC 2777              Verifiable Random Selection          February 2000


   lotteries are specified, and an exact algorithm is specified whereby
   eligible volunteers are selected based on a strong hash function [RFC
   1750] of these future sources of randomness.

2.3 Publication of Selection

   When the prespecified sources of randomness produce their output,
   those values plus a summary of the execution of the algorithm for
   selection should be announced so that anyone can verify that the
   correct randomness source values were used and the algorithm properly
   executed.  A cut off time for any complaint that the algorithm was
   run with the wrong inputs or not faithfully executed should be
   specified to finalize the output and provide a stable NomCom.

3. Randomness

   The crux of the unbiased nature of the selection is that it is based
   exactly on random information which will be revealed in the future
   and thus can not be known to the person specifying the algorithm by
   which that random information will be used to select the NomCom
   members.   The random information must be such that it will be
   publicly revealed in a timely fashion.

   The random sources should not include anything that any reasonable
   person would believe to be under the control or influence of the IETF
   or its components, such as IETF meeting attendance statistics,
   numbers of documents issued, or the like.

3.1 Sources of Randomness

   Examples of good information to use are lottery winning numbers for
   specified runnings of specified lotteries.  Particularly for
   government run lotteries, great care is usually taken to see that
   they produce random quantities.  Even in the unlikely case one were
   to have been rigged, it would almost certainly be in connection with
   winning money in the lottery, not in connection with IETF use.

   Other possibilities are such things as the closing price of a stock
   on a particular day, daily balance in the US Treasury on a specified
   day, the volume of trading on the New York Stock exchange on a
   specified day, etc. (However, the reference code given below will not
   handle integers that are too large.) Sporting events can be used but
   only with care to specify exactly what quantities are being presumed
   random and what will be done if they are cancelled or delayed.

   It is important that the last source of randomness, chronologically,
   produce a substantial amount of the entropy needed.  If most of the
   randomness has come from the earlier of the specified sources, and



Eastlake                     Informational                      [Page 3]

RFC 2777              Verifiable Random Selection          February 2000


   someone has even limited influence on the final source, they might do
   an exhaustive analysis and exert such influence so as to bias the
   selection in the direction they wanted.  Thus it is best for the last
   source to be an especially strong and unbiased source of a large
   amount of randomness such as a government run lottery.

   It is best not to use too many different sources.  Every additional
   source increases the probability that it might be delayed or
   cancelled calling into play contingency plans or, worst of all,
   possibly creating a situation that was not anticipated.  This would
   either require arbitrary judgement by the Nomcom chair, defeating the
   randomness of the selection, or a re-run with a new set of sources,
   causing much delay.  Probably a good number of sources is three.

3.2 Skew

   Many of the sources of randomness suggested above produce data which
   is not uniformly distributed.  This is certainly true of stock prices
   and horse race results, for example.  However, use of a strong mixing
   function [RFC 1750] will extract the available entropy and produce a
   hash value whose bits, remainder modulo a small divisor, etc., are
   uniformly distributed.

3.3 Entropy Needed

   What we are doing is selection N items without replacement from a
   population of P items.  The number of different ways to do this is as
   follows, where "!" represents the factorial function:

                                    P!
                               -------------
                               N! * (P - N)!

   To do this in a completely random fashion requires as many random
   bits as the logarithm base 2 of that quantity.  Some sample
   calculated approximate number of random bits for the selection of 10
   nomcom members from various pool sizes is given below:

                  Random Selection of Ten Items From Pool

   Pool size     20   25   30   35   40   50   60   75  100
   Bits needed   18   22   25   28   30   34   37   40   44

   Using an inadequate number of bits means that not all of the possible
   selections would be available.  For a substantially inadequate amount
   of entropy, there would be substantial correlations between the
   selection of two members of the pool, for example.  However, as a
   practical matter, for pool sizes likely to be encountered in IETF



Eastlake                     Informational                      [Page 4]

RFC 2777              Verifiable Random Selection          February 2000


   nomcom membership selection, 40 bits of entropy should always be
   adequate.  Even if there is a large pool and theoretically more bits
   are needed for complete randomness, 40 bits of entropy will assure
   that the probability of selection of each pool member differs from
   that of other pool members, the correlation between the selection of
   any pair of pool members, etc., differs only insignificantly from
   that for completely random selection.

   An MD5 [RFC 1321] hash has 128 bits and therefore can produce no more
   than that number of bits of entropy.  However, this is three times
   what is likely to ever been needed for IETF nomcom membership
   selection.

4. A Suggested Precise Algorithm

   It is important that a precise algorithm be given for mixing the
   random sources specified and making the selection based thereon.
   Sources suggested above each produce either a single positive number
   (i.e., closing price for a stock) or a small set of positive numbers
   (many lotteries provide 6 numbers in the range of 1 through 40 or the
   like, a sporting event could produce the scores of two teams, etc.).
   A sample precise algorithm is as follows:

   For each source producing multiple numeric values, represent each as
   a decimal number terminated by a period (or with a period separating
   the whole from the fractional part) and without leading zeroes
   (except for a single leading zero if the integer part is zero) or
   trailing zeroes after the period.  Order them from smallest to the
   largest and concatenate them and follow the results by a "/".  For
   each source producing a single number, simply represent it as above
   with a trailing "/".  At this point you have a string for each
   source, say s1/, s2/, ...  Concatenate these strings in a pre-
   specified order and represent each character as its ASCII code
   producing s1/s2/.../.

   You can then produce a sequence of random values derived from a
   strong mixing of these sources by calculating the MD5 hash [RFC 1321]
   of this string prefixed and suffixed with a zero byte for the first
   value, the string prefixed and suffixed by a 0x01 byte for the second
   value, etc.  Treat each of these derived random values as a positive
   multiprecision integer.  If there are P eligible volunteers, select
   the first voting member by dividing the first derived random value by
   P and using the remainder plus one as the position of the selectee in
   the ordered list or volunteers.  Select the second voting member by
   dividing the second derived random value by P-1 and using the
   remainder plus one as the position of the selectee in the list with
   the first selectee eliminated.  Etc.




Eastlake                     Informational                      [Page 5]

RFC 2777              Verifiable Random Selection          February 2000


   It is recommended that alphanumeric random sources be avoided due to
   the greater difficulty in canonicalizing them in an independently
   repeatable fashion; however, if any are used, all white space,
   punctuation, and special characters should be removed and all letters
   set to upper case. This will leave only an unbroken sequence of
   letters A-Z and digits 0-9 which can be treated as a canonicalized
   number above and suffixed with a "/".

5. Fully Worked Example

   Assume the following ordered list of 25 eligible volunteers is
   published in advance of selection:

         1. John         11. Pollyanna       21. Pride
         2. Mary         12. Pendragon       22. Sloth
         3. Bashful      13. Pandora         23. Envy
         4. Dopey        14. Faith           24. Anger
         5. Sleepy       15. Hope            25. Kasczynski
         6. Grouchy      16. Charity
         7. Doc          17. Love
         8. Sneazy       18. Longsuffering
         9. Handsome     19. Chastity
        10. Cassandra    20. Smith

   Assume the following (fake example) ordered list of randomness
   sources:

    1. The People's Democracy of Betastani State Lottery six winning
       numbers (ignoring the seventh "extra" number) for 1 October 1998.
    2. Numbers of the winning horses at Hialeia for all races for the
       first day on or after x September 1998 on which at least two
       races are run.
    3. The Republic of Alphaland State Lottery daily number for 1
       October 1998 treated as a single four digit integer.
    4. Closing price of Example Corporation stock on the Lunar Stock
       Exchange for the first business day after x September 1998 when
       it trades.

   Randomness publicly produced:

       Source 1:  9, 18, 26, 34, 41, 45
       Source 2:  2, 5, 12, 8, 10
       Source 3:  9319
       Source 4:  13 11/16

   Resulting key string:

       9.18.26.34.41.45./2.5.8.10.12./9319./13.6875/



Eastlake                     Informational                      [Page 6]

RFC 2777              Verifiable Random Selection          February 2000


   The table below gives the hex of the MD5 of the above key string
   bracketed with a byte whose value is successively 0x00, 0x01, 0x02,
   through 0x09.  The divisor for the number size of the remaining pool
   at each stage is given and the index of the selectee as per the
   original number of those in the pool.

   index        hex value of MD5        div  selected
    1  746612D0A75D2A2A39C0A957CF825F8D  25  -> 12 <-
    2  95E31A4429ED5AAF7377A15A8E10CD9D  24  ->  6 <-
    3  AFB2B3FD30E82AD6DC35B4D2F1CFC77A  23  ->  8 <-
    4  06821016C2A2EA14A6452F4A769ED1CC  22  ->  3 <-
    5  94DA30E11CA7F9D05C66D0FD3C75D6F7  21  ->  2 <-
    6  2FAE3964D5B1DEDD33FDA80F4B8EF45E  20  -> 24 <-
    7  F1E7AB6753A773EFE46393515FDA8AF8  19  -> 11 <-
    8  700B81738E07DECB4470879BEC6E0286  18  -> 19 <-
    9  1F23F8F8F8E5638A29D332BC418E0689  17  -> 15 <-
   10  61A789BA86BF412B550A5A05E821E0ED  16  -> 22 <-

   Resulting selection, in order selected:

         1. Pendragon (12)     6. Anger (24)
         2. Grouchy (6)        7. Pollyanna (11)
         3. Sneazy (8)         8. Chastity (19)
         4. Bashful (3)        9. Hope (15)
         5. Mary (2)          10. Sloth (22)

6. Security Considerations

   Careful choice of should be made of randomness inputs so that there
   is no reasonable suspicion that they are under the control of the
   administrator.  Guidelines given above to use a small number of
   inputs with a substantial amount of entropy from the last shoud be
   followed.  And equal care needs to be given that the algorithm
   selected is faithfully executed with the designated inputs values.
   Publication of the results and a week or so window for the community
   of interest to duplicate the calculations should give a reasonable
   assurance against implementation tampering.

   To maintain the unpredictable character of selections, should a
   member of the nomcom need to be replaced due to death, resignation,
   expulsion, etc., new publicly announced future random sources should
   be used for the selection of their replacement.









Eastlake                     Informational                      [Page 7]

RFC 2777              Verifiable Random Selection          February 2000


7.  Reference Code

   This code makes use of the MD5 reference code from [RFC 1321] ("RSA
   Data Security, Inc. MD5 Message-Digest Algorithm").  The portion of
   the code dealing with multiple floating point numbers was written by
   Matt Crawford.

   /****************************************************************
    *
    *  Reference code for
    *      "Publicly Verifiable Nomcom Random Selection"
    *          Donald E. Eastlake 3rd
    *
    ****************************************************************/
   #include <limits.h>
   #include <math.h>
   #include <stdio.h>
   #include <stdlib.h>
   #include <string.h>

   #include "global.h"
   #include "MD5.h"

   /* local prototypes */
   int longremainder ( unsigned char divisor,
                       unsigned char dividend[16] );
   int getinteger ( char *string );
   double NPentropy ( int N, int P );


   /* limited to 16 inputs of up to sixteen integers each */
   /****************************************************************/

   main ()
   {
   int         i, j,  k, k2, err, keysize, pool, selection;
   unsigned char   unch, uc16[16], remaining, *selected;
   long int    temp, array[16];
   MD5_CTX ctx;
   char        buffer[257], key [800], sarray[16][256];

   pool = getinteger ( "Type size of pool:\n" );
   if ( pool > 255 )

       {
       printf ( "Pool too big.\n" );
       exit ( 1 );
       }



Eastlake                     Informational                      [Page 8]

RFC 2777              Verifiable Random Selection          February 2000


   selected = (unsigned char *) malloc ( pool );
   if ( !selected )
       {
       printf ( "Out of memory.\n" );
       exit ( 1 );
       }
   selection = getinteger ( "Type number of items to be selected:\n" );
   if ( selection > pool )
       {
       printf ( "Pool too small.\n" );
       exit ( 1 );
       }
   if ( selection == pool )
       {
       printf ( "All of the pool is selected.\n" );
       exit ( 0 );
       }
   err = printf ( "Approximately %.1f bits of entropy needed.\n",
                  NPentropy ( selection, pool ) + 0.1 );
   if ( err <= 0 ) exit ( 1 );
   for ( i = 0, keysize = 0; i < 16; ++i )
       {
       if ( keysize > 500 )
           {
           printf ( "Too much input.\n" );
           exit ( 1 );
           }
       /* get the "random" inputs. echo back to user so the user may
          be able to tell if truncation or other glitches occur.  */
       err = printf (
           "\nType #%d randomness or 'end' followed by new line.\n"
           "Up to 16 integers or the word 'float' followed by up\n"
           "to 16 x.y format reals.\n", i+1 );
       if ( err <= 0 ) exit ( 1 );
       gets ( buffer );
       j = sscanf ( buffer,
               "%ld%ld%ld%ld%ld%ld%ld%ld%ld%ld%ld%ld%ld%ld%ld%ld",
           &array[0], &array[1], &array[2], &array[3],
           &array[4], &array[5], &array[6], &array[7],
           &array[8], &array[9], &array[10], &array[11],
           &array[12], &array[13], &array[14], &array[15] );
       if ( j == EOF )
           exit ( j );
       if ( !j )
           if ( buffer[0] == 'e' )
               break;

           else



Eastlake                     Informational                      [Page 9]

RFC 2777              Verifiable Random Selection          February 2000


               {   /* floating point code by Matt Crawford */
               j = sscanf ( buffer,
                   "float %ld.%[0-9]%ld.%[0-9]%ld.%[0-9]%ld.%[0-9]"
                   "%ld.%[0-9]%ld.%[0-9]%ld.%[0-9]%ld.%[0-9]"
                   "%ld.%[0-9]%ld.%[0-9]%ld.%[0-9]%ld.%[0-9]"
                   "%ld.%[0-9]%ld.%[0-9]%ld.%[0-9]%ld.%[0-9]",
                   &array[0], sarray[0], &array[1], sarray[1],
                   &array[2], sarray[2], &array[3], sarray[3],
                   &array[4], sarray[4], &array[5], sarray[5],
                   &array[6], sarray[6], &array[7], sarray[7],
                   &array[8], sarray[8], &array[9], sarray[9],
                   &array[10], sarray[10], &array[11], sarray[11],
                   &array[12], sarray[12], &array[13], sarray[13],
                   &array[14], sarray[14], &array[15], sarray[15] );
               if ( j == 0 || j & 1 )
                   printf ( "Bad format." );
               else {
                    for ( k = 0, j /= 2; k < j; k++ )
                    {
                          /* strip trailing zeros */
                    for ( k2=strlen(sarray[k]); sarray[k][--k2]=='0';)
                          sarray[k][k2] = '\0';
                    err = printf ( "%ld.%s\n", array[k], sarray[k] );
                    if ( err <= 0 ) exit ( 1 );
                    keysize += sprintf ( &key[keysize], "%ld.%s",
                                         array[k], sarray[k] );
                    }
                    keysize += sprintf ( &key[keysize], "/" );
                    }
               }
       else
           {   /* sort values, not a very efficient algorithm */
           for ( k2 = 0; k2 < j - 1; ++k2 )
               for ( k = 0; k < j - 1; ++k )
                   if ( array[k] > array[k+1] )
                       {
                       temp = array[k];
                       array[k] = array[k+1];
                       array[k+1] = temp;
                       }
           for ( k = 0; k < j; ++k )
               { /* print for user check */
               err = printf ( "%ld ", array[k] );
               if ( err <= 0 ) exit ( 1 );
               keysize += sprintf ( &key[keysize], "%ld.", array[k] );
               }
           keysize += sprintf ( &key[keysize], "/" );
           }



Eastlake                     Informational                     [Page 10]

RFC 2777              Verifiable Random Selection          February 2000


       }   /* end for i */

   /* have obtained all the input, now produce the output */
   err = printf ( "Key is:\n %s\n", key );
   if ( err <= 0 ) exit ( 1 );
   for ( i = 0; i < pool; ++i )
       selected [i] = i + 1;
   printf ( "index        hex value of MD5        div  selected\n" );
   for (   unch = 0, remaining = pool;
           unch < selection;
           ++unch, --remaining )
       {
       MD5Init ( &ctx );
       MD5Update ( &ctx, &unch, 1 );
       MD5Update ( &ctx, (unsigned char *)key, keysize );
       MD5Update ( &ctx, &unch, 1 );
       MD5Final ( uc16, &ctx );
       k = longremainder ( remaining, uc16 );
   /* printf ( "Remaining = %d, remainder = %d.\n", remaining, k ); */
       for ( j = 0; j < pool; ++j )
           if ( selected[j] )
               if ( --k < 0 )
                   {
                   printf ( "%2d  "
   "%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X  "
   "%2d  -> %2d <-\n",
   unch+1, uc16[0],uc16[1],uc16[2],uc16[3],uc16[4],uc16[5],uc16[6],
   uc16[7],uc16[8],uc16[9],uc16[10],uc16[11],uc16[12],uc16[13],uc16[14],
   uc16[15], remaining, selected[j] );
                   selected[j] = 0;
                   break;
                   }
       }
   printf ( "\nDone, type any character to exit.\n" );
   getchar ();
   return 0;
   }

   /* prompt for an integer input */
   /****************************************************************/
   int getinteger ( char *string )
   {
   int     i, j;
   char    tin[257];

   while ( 1 )
   {
   printf ( string );



Eastlake                     Informational                     [Page 11]

RFC 2777              Verifiable Random Selection          February 2000


   printf ( "(or 'exit' to exit) " );
   gets ( tin );
   j = sscanf ( tin, "%d", &i );
   if (    ( j == EOF )

       ||  ( !j && ( ( tin[0] == 'e' ) || ( tin[0] == 'E' ) ) )
           )
       exit ( j );
   if ( j == 1 )
       return i;
   }   /* end while */
   }

   /* get remainder of dividing a 16 byte unsigned int
      by a small positive number */
   /****************************************************************/
   int longremainder ( unsigned char divisor,
                       unsigned char dividend[16] )
   {
   int i;
   long int kruft;

   if ( !divisor )
       return -1;
   for ( i = 0, kruft = 0; i < 16; ++i )
       {
       kruft = ( kruft << 8 ) + dividend[i];
       kruft %= divisor;
       }
   return kruft;
   }   /* end longremainder */

   /* calculate how many bits of entropy it takes to select N from P */
   /****************************************************************/
   /*             P!
     log  ( ----------------- )
        2    N! * ( P - N )!
   */

   double NPentropy ( int N, int P )
   {
   int         i;
   double      result = 0.0;

   if (    ( N < 1 )   /* not selecting anything? */
      ||   ( N >= P )  /* selecting all of pool or more? */
      )
       return 1.0;     /* degenerate case */



Eastlake                     Informational                     [Page 12]

RFC 2777              Verifiable Random Selection          February 2000


   for ( i = P; i > ( P - N ); --i )
       result += log ( i );
   for ( i = N; i > 1; --i )
       result -= log ( i );
   /* divide by [ log (base e) of 2 ] to convert to bits */
   result /= 0.69315;

   return result;
   }   /* end NPentropy */










































Eastlake                     Informational                     [Page 13]

RFC 2777              Verifiable Random Selection          February 2000


Appendix: History of NomCom Member Selection

   For reference purposes, here is a list of the IETF Nominations
   Committee member selection techniques and chairs so far:

           YEAR      CHAIR               SELECTION METHOD

        1993/1994  Jeff Case             Clergy
        1994/1995  Fred Baker            Clergy
        1995/1996  Guy Almes             Clergy
        1996/1997  Geoff Huston          Spouse
        1997/1998  Mike St.Johns         Algorithm
        1998/1999  Donald Eastlake 3rd   This Algorithm
        1999/2000  Avri Doria            This Alogrithm

   Clergy = Names were written on pieces of paper, placed in a
   receptacle, and a member of the clergy picked the Nomcom members.

   Spouse = Same as Clergy except chair's spouse made the selection.

   Algorithm = Algorithmic selection based on the same concepts as
   documented herein.

   This Algorithm = Algorithmic selection using the algorithm and
   reference code (but not the fake example sources of randomness)
   described herein.

























Eastlake                     Informational                     [Page 14]

RFC 2777              Verifiable Random Selection          February 2000


References

   RFC 1321  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
             April 1992.

   RFC 1750  Eastlake, D., 3rd, Crocker, S. and J. Schiller, "Randomness
             Recommendations for Security", RFC 1750, December 1994.

   RFC 2727  Galvin, J., "IAB and IESG Selection, Confirmation, and
             Recall Process: Operation of the Nominating and Recall
             Committees", BCP 10, RFC 2727, February 2000.

Author's Address

   Donald E. Eastlake, 3rd
   Motorola
   65 Shindegan Hill Road, RR #1
   Carmel, NY 10512 USA

   Phone:  +1-914-276-2668 (h)
           +1-508-261-5434 (w)
   Fax:    +1-508-261-4447 (w)
   EMail:  Donald.Eastlake@motorola.com




























Eastlake                     Informational                     [Page 15]

RFC 2777              Verifiable Random Selection          February 2000


Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Eastlake                     Informational                     [Page 16]