INTERNET-DRAFT Donald E. Eastlake 3rd Motorola OBSOLETES: RFC 2777 June 2003 Expires December 2003 Publicly Verifiable Nomcom Random Selection -------- ---------- ------ ------ --------- 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 and Erik Nordmark made major contributions to this document. Comments by Bernard Aboba, Theodore Ts'o, Jim Galvin, 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.................................8 6. Fully Worked Example....................................9 7. Security Considerations................................11 8. Reference Code........................................11 Appendix A: History of NomCom Member Selection............17 Appendix B: Changes from RFC 2777.........................17 References................................................18 Author's Address..........................................18 File name and Expiration..................................18 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 [2727bis]. 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 as provided in [2727bis] or its successor. 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 is made public early enough that a reasonable time can be given to resolve any disputes as to who should be in the pool. 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 is 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 public 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 judgment by the selection administrator, defeating the randomness of the selection, or a re-run of with a new set of sources, causing much delay. Three is a good number of sources. Ten is way too many. 3.2 Skew Some of the sources of randomness produce data that 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 only an insignificant deviation from completely random selection for the difference in probability of selection of different pool members, the correlation between the selection of any pair of pool members, etc. 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 even 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 and sometimes in numeric order.) D. Eastlake 3rd [Page 6] INTERNET-DRAFT Verifiable Random Selection November 2001 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 uncertain and to keep the published pool list numbering IMMUTABLE after its publication. If someone in the pool is later selected by D. Eastlake 3rd [Page 7] INTERNET-DRAFT Verifiable Random Selection November 2001 the algorithm and random input but it has been determined they are ineligible, they must be skipped and the algorithm run 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 As specified in [2727bis] 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, those that can't be contacted, and anyone who might leave the Nomcom during its term. Yes, it has actually occurred that an eligible volunteer has been selected and found to be un-contactable, 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 select another person. 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.) 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 D. Eastlake 3rd [Page 8] INTERNET-DRAFT Verifiable Random Selection November 2001 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 public 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 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. D. Eastlake 3rd [Page 9] INTERNET-DRAFT Verifiable Random Selection 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. 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) D. Eastlake 3rd [Page 10] INTERNET-DRAFT Verifiable Random Selection November 2001 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 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. The original code in RFC 2777 could only handle pools of up to 255 members and was extended to 2**16-1 by Erik Nordmark. /**************************************************************** * * Reference code for * "Publicly Verifiable Nomcom Random Selection" * Donald E. Eastlake 3rd * June 2003 * ****************************************************************/ #include #include #include #include #include #include "global.h" #include "MD5.h" /* local prototypes */ int longremainder ( unsigned short divisor, unsigned char dividend[16] ); int getinteger ( char *string ); double NPentropy ( int N, int P ); D. Eastlake 3rd [Page 11] INTERNET-DRAFT Verifiable Random Selection November 2001 /* limited to up to 16 inputs of up to sixteen integers each */ /* pool limit of 2**8-1 extended to 2**16-1 by Erik Nordmark */ /****************************************************************/ main () { int i, j, k, k2, err, keysize, pool, selection; unsigned short 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 > 65535 ) { printf ( "Pool too big.\n" ); exit ( 1 ); } selected = (unsigned short *) 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" D. Eastlake 3rd [Page 12] INTERNET-DRAFT Verifiable Random Selection November 2001 "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 { /* 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 ) D. Eastlake 3rd [Page 13] INTERNET-DRAFT Verifiable Random Selection November 2001 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 */ /* 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 (); D. Eastlake 3rd [Page 14] INTERNET-DRAFT Verifiable Random Selection November 2001 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 ) || ( !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 short 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 ( ----------------- ) D. Eastlake 3rd [Page 15] INTERNET-DRAFT Verifiable Random Selection November 2001 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; return result; } /* end NPentropy */ D. Eastlake 3rd [Page 16] 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 RFC 2777 1999/2000 Avri Doria RFC 2777 2000/2001 Bernard Aboba RFC 2777 2001/2002 Theodore Ts'o RFC 2777 2002/2003 Phil Roberts RFC 2777 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. RFC 2777 = Algorithmic selection using the algorithm and reference code provided in RFC 2777 (but not the fake example sources of randomness). Appendix B: Changes from RFC 2777 This document differs from [RFC 2777], the previous version, in three primary ways as follows: (1) Section 5, on problems actually encountered with using these Recommendations for selecting an IETF nomcom and 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. (3) The selection algorithm code has been modified to handle pools of up to 2**16-1 elements. D. Eastlake 3rd [Page 17] INTERNET-DRAFT Verifiable Random Selection November 2001 References [2727bis] - draft-ietf-nomcom-rfc2727bis-05.txt, "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees", work in progress, J. Galvin, June 2003. [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 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) email: Donald.Eastlake@motorola.com File name and Expiration This file is draft-eastlake-rfc2777bis-selection-02.txt. It expires December 2003. D. Eastlake 3rd [Page 18]