INTERNET-DRAFT                                    Donald E. Eastlake 3rd
                                                                Motorola
OBSOLETES: RFC 2777                                        November 2001
Expires May 2002




              Publicly Verifiable NomCom Random Selection
              -------- ---------- ------ ------ ---------
              <draft-eastlake-rfc2777bis-selection-01.txt>



Status of this Memo

   This draft is intended to become an Informational RFC.  Distribution
   of this document is unlimited. Comments should be sent to the author.

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.  Internet-Drafts are
   working documents of the Internet Engineering Task Force (IETF), its
   areas, and its working groups.  Note that other groups may also
   distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.



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.










D. Eastlake 3rd                                                 [Page 1]


INTERNET-DRAFT        Verifiable Random Selection          November 2001


Acknowledgements

   Matt Crawford made major contributions to this document and comments
   by Bernard Aboba, Theodore Ts'o and others have been incorporated.



Table of Contents

      Status of this Memo........................................1
      Abstract...................................................1

      Acknowledgements...........................................2
      Table of Contents..........................................2

      1. Introduction............................................3
      2. General Flow of a Publicly Verifiable Process...........3
      2.1 Determination of the Pool..............................3
      2.2 Publication of the Algorithm...........................3
      2.3 Publication of Selection...............................4
      3. Randomness..............................................4
      3.1 Sources of Randomness..................................4
      3.2 Skew...................................................5
      3.3 Entropy Needed.........................................5
      4. A Suggested Precise Algorithm...........................6
      5. Handling Real World Problems............................7
      5.1 Uncertainty as to the Pool.............................7
      5.2 Vacancies in NomCom....................................8
      5.3 Randomness Ambiguities.................................9
      6. Fully Worked Example....................................9
      7. Security Considerations................................11
      8. Reference Code.........................................12

      Appendix A: History of NomCom Member Selection............18
      Appendix B: Changes from RFC 2777.........................18

      References................................................19
      Author's Address..........................................19
      File name and Expiration..................................19













D. Eastlake 3rd                                                 [Page 2]


INTERNET-DRAFT        Verifiable Random Selection          November 2001


1. Introduction

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

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

   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 selection administrator.  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 should be made public early enough that a
   reasonable time can be given to resolve any disputes as to who should
   be in the pool, probably a week to ten days.



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


D. Eastlake 3rd                                                 [Page 3]


INTERNET-DRAFT        Verifiable Random Selection          November 2001


   list of eligible volunteers are ordered by publicly numbering them,
   some public future sources of randomness such as government run
   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 pre-specified 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
   in an exact, predetermined fashion on random information which will
   be revealed in the future and thus can not be known to the person
   specifying the algorithm. That random information will be used to
   control the selection.  The random information must be such that it
   will be publicly and unambiguously revealed in a timely fashion.

   The random sources must 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 winning lottery numbers for
   specified runnings of specified lotteries.  Particularly for
   government run lotteries, great care is 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 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 also be used. (Experience has indicated that stock prices


D. Eastlake 3rd                                                 [Page 4]


INTERNET-DRAFT        Verifiable Random Selection          November 2001


   and/or volumes are a poor source of unambiguous data due to their not
   trading on some days, mergers, delistings, splits, multiple markets,
   etc.)  In all cases, great care must be taken to specify exactly what
   quantities are being presumed random and what will be done if their
   issuance is 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
   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 one or more sources might be
   delayed, cancelled, or just plain screwed up somehow, calling into
   play contingency provisions or, worst of all, creating a situation
   that was not anticipated.  This would either require arbitrary
   judgement by the selection administrator, defeating the randomness of
   the selection, or a re-run of with a new set of sources, causing much
   delay.  A good number of sources is three. Ten is probably too many.



3.2 Skew

   Some of the sources of randomness produce data which is not uniformly
   distributed.  This is certainly true of volumes, 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


D. Eastlake 3rd                                                 [Page 5]


INTERNET-DRAFT        Verifiable Random Selection          November 2001


   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 could be a correlation between the selection of two
   different members of the pool, for example.  However, as a practical
   matter, for pool sizes likely to be encountered in IETF 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 be needed for IETF NomCom membership
   selection.  A stronger hash such as SHA-1 [RFC 3174] can be used if
   desired.



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 produce either a single positive number
   (i.e., NY Stock Exchange volume in thousands of shares) 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:

   1. 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.

   2. Order them from smallest to the largest and concatenate them and
      suffix the result with a "/".  For each source producing a single
      number, simply represent it as above with a suffix "/". (This
      sorting is necessary because the same lottery results, for
      example, are sometimes reported in the order numbers were drawn


D. Eastlake 3rd                                                 [Page 6]


INTERNET-DRAFT        Verifiable Random Selection          November 2001


      and sometimes in numeric order.)

   3. 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 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.  Then totally order the pool of listed
   volunteers as follows: If there are P volunteers, select the first by
   dividing the first derived random value by P and using the remainder
   plus one as the position of the selectee in the published list.
   Select the second by dividing the second derived random value by P-1
   and using the remainder plus one as the position in the list with the
   first selected person eliminated.  Etc.

   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. Handling Real World Problems

   In the real world, problems can arise in following the steps and flow
   outlined in Sections 2 through 4 above. Some problems that have
   actually arisen are described below with recommendations for handling
   them.



5.1 Uncertainty as to the Pool

   Every reasonable effort should be made to see that the published pool
   from which selection is made is of certain and eligible persons.
   However, especially with compressed schedules or perhaps someone
   whose claim that they volunteered and are eligible has not been
   resolved by the deadline, or a determination that someone is not
   eligible which occurs after the publication of the pool, it may be
   that there are still uncertainties.

   The best way to handle this is to maintain the announced schedule,
   INCLUDE in the published pool all those whose eligibility is


D. Eastlake 3rd                                                 [Page 7]


INTERNET-DRAFT        Verifiable Random Selection          November 2001


   uncertain and to keep the published pool list numbering IMMUTABLE
   after its publication. If someone in the pool is later selected by
   the algorithm and random input but it has been determined they are
   ineligible, they must be skipped and the algorithm used further to
   make an additional selection. Thus the uncertainty only effects one
   selection and in general no more than a maximum of N selections where
   there are N uncertain pool members.

   Other courses of action are far worse. Actual insertion or deletion
   of entries in the pool after its publication changes the length of
   the list and totally scrambles who is selected, possibly changing
   every selection. Insertion into the pool raises questions of where to
   insert: at the beginning, end, alphabetic order, ... Any such choices
   by the selection administrator after the random numbers are known
   destroys the public verifiability of fair choice. Even if done before
   the random numbers are known, such dinking with the list after its
   publication just doesn't smell good.  There should be clear fixed
   public deadlines and someone who challenges their absence from the
   pool after the published deadline should have their challenge
   automatically denied for tardiness.



5.2 Vacancies in NomCom

   The ordering produced by the algorithm may needs to go used beyond
   the exact number to be select to allow for ineligibles, those who
   back out when actually contacted and asked to affirm their
   willingness to serve and maintain NomCom confidentiality, and those
   that can't be contacted.

   Yes, it has actually occurred that an eligible volunteer has been
   selected and found to be uncontactable, despite repeated good faith
   efforts over a period of weeks by email, telephone, and postal mail,
   including trying to go through their employer. There really isn't
   much choice in such as case other than to treat them as not
   consenting and go on to the next person selected. So, it might be a
   good idea in early announcements to make it clear that volunteers
   need to be contactable during, say, the week after the last random
   number is available. (Many enthusiastic volunteers have, in the past,
   spontaneously told the selection administrator how to contact them if
   they were going to be on vacation, etc.)

   Vacancies occurring in the NomCom after it has been established and
   is in operation are a little different.  It is generally recommended
   that the original ordering of the eligible pool be followed and the
   next volunteer according to the original algorithm and random inputs
   be contacted. Using new announced future random number inputs to
   select from the remainder of the pool is not recommended as it may be
   impractical due to delays. Asking for a new pool of volunteers would


D. Eastlake 3rd                                                 [Page 8]


INTERNET-DRAFT        Verifiable Random Selection          November 2001


   be even worse and should be avoided except in the extraordinary case,
   unlikely to ever occur, where the eligible pool has been depleted or
   is nearly so. If the NomCom is near to finishing its work, it may not
   be worth filling a vacancy.



5.3 Randomness Ambiguities

   The best good faith efforts have been made to specify precise and
   unambiguous sources of randomness. These sources are made public in
   advance and there has not been objection to them. However, it has
   happened that when the time comes to actually get and use this
   randomness, the real world has thrown a curve ball and it isn't quite
   clear what data to use. Problems have particularly arisen in
   connection with stock prices, volumes, and obscure financial exchange
   rates or indices. If volumes that were published in thousands are
   published in hundreds, you have a rounding problem. Prices that were
   quoted in fractions or decimals can change to the other. If you take
   care of every contingency that has come up in the past, you can be
   hit with a new one. When this sort of thing happens, it is generally
   too late to announce new sources, an action which would raise
   suspicions of its own. About the only course of action is to make a
   reasonable choice within the ambiguity and depend on confidence in
   the good faith of the selection administrator. With care, such cases
   should be very rare.

   Based on these experiences, it is again recommended that government
   run Lottery numbers or the like be used as the random inputs and
   stock prices and volumes avoided.



6. 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. Lee
         8. Sneazy       18. Longsuffering
         9. Handsome     19. Chastity
        10. Cassandra    20. Smith




D. Eastlake 3rd                                                 [Page 9]


INTERNET-DRAFT        Verifiable Random Selection          November 2001


   Assume the following (fake example) ordered list of randomness
   sources:
   1. The Kingdom of Alphaland State Lottery daily number for 1 November
      2001 treated as a single four digit integer.
   2. Numbers of the winning horses at Hialeia for all races for the
      first day on or after 13 October 2001 on which at least two races
      are run.
   3. The People's Democratic Republic of Betastani State Lottery six
      winning numbers (ignoring the seventh "extra" number) for 1
      November 2001.

   Randomness publicly produced:
       Source 1:  9319
       Source 2:  2, 5, 12, 8, 10
       Source 3:  9, 18, 26, 34, 41, 45

   Resulting key string:

       9319./2.5.8.10.12./9.18.26.34.41.45./

   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 0x18 (24 decimal).  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.



























D. Eastlake 3rd                                                [Page 10]


INTERNET-DRAFT        Verifiable Random Selection          November 2001


   index        hex value of MD5        div  selected
    1  4C4C5D58AD807B5F7F2AF204388DD535  25  ->  1 <-
    2  8D48578ABB4CEBD0D2373D7BFA114B03  24  ->  5 <-
    3  40A00B09ADC221A1BC94A630586EAACB  23  ->  3 <-
    4  7A4E4438A12D0910DD476C4D49320AE8  22  -> 22 <-
    5  1043E7D40B3AC046DA0B0632A5D77F94  21  -> 23 <-
    6  E1D86C731699BB622DF9D1CE6151CED9  20  -> 13 <-
    7  AF58AE51C1C71F5A3F7188DDB6C06C4B  19  ->  6 <-
    8  B8C194EDAF398382F12AF1C9FC422EFD  18  -> 17 <-
    9  1171E43E16401EDDB49E8949054A6074  17  -> 24 <-
   10  88EDB93DE271B27E128D15A52E187064  16  ->  9 <-
   11  5DB41AEA8D9764A060C028C9E4092E3A  15  -> 11 <-
   12  EA5CCD27C45DF460DBCC6503ECF02D91  14  ->  8 <-
   13  F01CCAD753E7ECE2F1FC0BB8E31B32B8  13  -> 12 <-
   14  96ED6645A39FDB677074393DB3F3B65B  12  -> 25 <-
   15  F52D14524C05F3C9D5E37287EA57BF89  11  -> 15 <-
   16  5D91C0594E5A14CE4DD0B0E161330F8E  10  -> 14 <-
   17  E2F54F8469968D9F7587030846F667A4   9  ->  4 <-
   18  3BCFF32BCFB28F7084FA1D6662C8FDF2   8  -> 10 <-
   19  4ECAB2922E136FA17792308C6928AF4F   7  -> 19 <-
   20  3A69AEBA4536019CE648DEC72A18202E   6  -> 16 <-
   21  73BFBF62ADD6EDE4D49132434A4CB157   5  ->  2 <-
   22  08BF9083A8CD26BA51CB69524146648E   4  -> 20 <-
   23  7D11231987541D6378827AB916655EC0   3  ->  7 <-
   24  3598FF9C59D14E6FFFC0CC3448F99BB3   2  -> 21 <-
   25  3D31BDC8D0C4DC0A4B4A07B8F5A17EB2   1  -> 18 <-

   Resulting first ten selected, in order selected:

         1. John (1)           6. Pandora (13)
         2. Sleepy (5)         7. Grouchy (6)
         3. Bashful (3)        8. Lee (17)
         4. Sloth (22)         9. Anger (24)
         5. Envy (23)         10. Handsome (9)

   Should one of the above turn out to be ineligible or decline to
   serve, the next would be Pollyanna, number 11.



7. 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 should 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


D. Eastlake 3rd                                                [Page 11]


INTERNET-DRAFT        Verifiable Random Selection          November 2001


   assurance against implementation tampering.



8.  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
       *              November 2001
       *
       ****************************************************************/
      #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 up 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 )

          {


D. Eastlake 3rd                                                [Page 12]


INTERNET-DRAFT        Verifiable Random Selection          November 2001


          printf ( "Pool too big.\n" );
          exit ( 1 );
          }
      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" );
      else
          {
          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;



D. Eastlake 3rd                                                [Page 13]


INTERNET-DRAFT        Verifiable Random Selection          November 2001


              else
                  {   /* 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], "/" );
              }
          }   /* end for i */


D. Eastlake 3rd                                                [Page 14]


INTERNET-DRAFT        Verifiable Random Selection          November 2001


      /* 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 < pool;
              ++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 a positive non-zero integer input */
      /****************************************************************/
      int getinteger ( char *string )
      {
      int     i, j;
      char    tin[257];

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


D. Eastlake 3rd                                                [Page 15]


INTERNET-DRAFT        Verifiable Random Selection          November 2001


          ||  ( !j && ( ( tin[0] == 'e' ) || ( tin[0] == 'E' ) ) )
              )
          exit ( j );
      if ( ( j == 1 ) &&
           ( i > 0 ) )
          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 0.0;     /* degenerate case */
      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;


D. Eastlake 3rd                                                [Page 16]


INTERNET-DRAFT        Verifiable Random Selection          November 2001


      return result;
      }   /* end NPentropy */


















































D. Eastlake 3rd                                                [Page 17]


INTERNET-DRAFT        Verifiable Random Selection          November 2001


Appendix A: 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 Algorithm
        2000/2001  Bernard Aboba         This Algorithm
        2001/2002  Theodore Ts'o         This Algorithm

   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 described herein (but not the fake example sources of
   randomness).



Appendix B: Changes from RFC 2777

   This document differs from [RFC 2777], the previous version, in two
   primary ways as follows:

   (1) Section 5, on problems actually encountered with recommendations
       on how to handle them, has been added.

   (2) The selection algorithm and code have been recast from selection
       N entries from the pool to producing a total ordering of the
       pool. It is then easy to pick N by just taking the first N. This
       handles cases where some pool entries turn out to be ineligible,
       etc.

   Other minor changes and updates were made.






D. Eastlake 3rd                                                [Page 18]


INTERNET-DRAFT        Verifiable Random Selection          November 2001


References

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

   [RFC 1750] - "Randomness Recommendations for Security", D. Eastlake,
   3rd, S.  Crocker & J. Schiller. December 1994.

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

   [RFC 2777] - "Publicly Verifiable Nomcom Random Selection", D.
   Eastlake, February 2000.

   [RFC 3174] - "US Secure Hash Algorithm 1 (SHA1)", D. Eastlake, 3rd,
   P. Jones, September 2001.



Author's Address

   Donald E. Eastlake, 3rd
   Motorola
   155 Beaver Street
   Milford, MA 01757 USA

   tel:    +1-508-261-5434(w)
           +1-508-634-2066(h)
   fax:    +1-508-261-4447(w)
   email:  Donald.Eastlake@motorola.com



File name and Expiration

   This file is draft-eastlake-rfc2777bis-selection-01.txt.

   It expires May 2002.













D. Eastlake 3rd                                                [Page 19]