idnits 2.17.00 (12 Aug 2021) /tmp/idnits19065/draft-eastlake-rfc2777bis-selection-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 7 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC2777, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 412 has weird spacing: '... div selec...' == Line 494 has weird spacing: '...d short rema...' == Line 495 has weird spacing: '...ong int poo...' == Line 498 has weird spacing: '...ed char uc1...' == Line 610 has weird spacing: '... div selec...' == (1 more instance...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2004) is 6450 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '16' on line 676 -- Looks like a reference, but probably isn't: '257' on line 653 -- Looks like a reference, but probably isn't: '800' on line 497 -- Looks like a reference, but probably isn't: '256' on line 497 -- Looks like a reference, but probably isn't: '0' on line 663 -- Looks like a reference, but probably isn't: '1' on line 634 -- Looks like a reference, but probably isn't: '2' on line 634 -- Looks like a reference, but probably isn't: '3' on line 634 -- Looks like a reference, but probably isn't: '4' on line 634 -- Looks like a reference, but probably isn't: '5' on line 634 -- Looks like a reference, but probably isn't: '6' on line 634 -- Looks like a reference, but probably isn't: '7' on line 635 -- Looks like a reference, but probably isn't: '8' on line 635 -- Looks like a reference, but probably isn't: '9' on line 635 -- Looks like a reference, but probably isn't: '10' on line 635 -- Looks like a reference, but probably isn't: '11' on line 635 -- Looks like a reference, but probably isn't: '12' on line 635 -- Looks like a reference, but probably isn't: '13' on line 635 -- Looks like a reference, but probably isn't: '14' on line 635 -- Looks like a reference, but probably isn't: '15' on line 636 -- No information found for draft-ietf-nomcom-rfc2727bis- - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 2777 (Obsoleted by RFC 3797) -- Obsolete informational reference (is this intentional?): RFC 3490 (Obsoleted by RFC 5890, RFC 5891) -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Obsolete normative reference: RFC 1750 (Obsoleted by RFC 4086) ** Downref: Normative reference to an Informational RFC: RFC 3174 Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 28 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Donald E. Eastlake 3rd 2 Motorola Laboratories 3 OBSOLETES: RFC 2777 March 2004 4 Expires September 2004 6 Publicly Verifiable Nomcom Random Selection 7 -------- ---------- ------ ------ --------- 8 10 Status of this Memo 12 This draft is intended to become an Informational RFC. Distribution 13 of this document is unlimited. Comments should be sent to the author. 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC 2026. Internet-Drafts are 17 working documents of the Internet Engineering Task Force (IETF), its 18 areas, and its working groups. Note that other groups may also 19 distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." The list 25 of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft 27 Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document describes a method for making random selections in such 33 a way that the unbiased nature of the choice is publicly verifiable. 34 As an example, the selection of the voting members of the IETF 35 Nominations Committee from the pool of eligible volunteers is used. 36 Similar techniques would be applicable to other cases. 38 Acknowledgements 40 Matt Crawford and Erik Nordmark made major contributions to this 41 document. Comments by Bernard Aboba, Theodore Ts'o, Jim Galvin, 42 Steve Bellovin, and others have been incorporated. 44 Table of Contents 46 Status of this Memo........................................1 47 Abstract...................................................1 49 Acknowledgements...........................................2 50 Table of Contents..........................................2 52 1. Introduction............................................3 53 2. General Flow of a Publicly Verifiable Process...........3 54 2.1 Determination of the Pool..............................3 55 2.2 Publication of the Algorithm...........................4 56 2.3 Publication of Selection...............................4 57 3. Randomness..............................................4 58 3.1 Sources of Randomness..................................4 59 3.2 Skew...................................................5 60 3.3 Entropy Needed.........................................5 61 4. A Suggested Precise Algorithm...........................6 62 5. Handling Real World Problems............................8 63 5.1 Uncertainty as to the Pool.............................8 64 5.2 Randomness Ambiguities.................................8 65 6. Fully Worked Example....................................9 66 7. Security Considerations................................10 67 8. Reference Code.........................................11 69 Appendix A: History of NomCom Member Selection............17 71 Appendix B: Changes from RFC 2777.........................18 73 Informative References....................................19 74 Normative References......................................19 75 Author's Address..........................................19 76 File name and Expiration..................................19 78 1. Introduction 80 Under the IETF rules, each year ten people are randomly selected from 81 among eligible volunteers to be the voting members of the IETF 82 nominations committee (Nomcom). The Nomcom nominates members of the 83 Internet Engineering Steering Group (IESG) and the Internet 84 Architecture Board (IAB) as described in [2727bis]. The number of 85 eligible volunteers in recent years has been around 100. 87 It is highly desirable that the random selection of the voting Nomcom 88 be done in an unimpeachable fashion so that no reasonable charges of 89 bias or favoritism can be brought. This is as much for the protection 90 of the selection administrator (currently, the appointed non-voting 91 Nomcom chair) from suspicion of bias as it is for the protection of 92 the IETF. 94 A method such that public information will enable any person to 95 verify the randomness of the selection meets this criterion. This 96 document gives an example of such a method. 98 The method, in the form it appears in RFC 2777, was also used by IANA 99 in February 2003 to determine the ACE prefix for Internationalized 100 Domain Names [RFC 3490] so as to avoid claim jumping. 102 2. General Flow of a Publicly Verifiable Process 104 A selection of Nomcom members publicly verifiable as unbiased or 105 similar selection could follow the three steps given below. 107 2.1 Determination of the Pool 109 First, determine the pool from which the selection is to be made as 110 provided in [2727bis] or its successor. 112 Volunteers are solicited by the selection administrator. Their names 113 are then passed through the IETF Secretariat to check eligibility. 114 (Current eligibility criteria relate to IETF meeting attendance, 115 records of which are maintained by the Secretariat.) The full list of 116 eligible volunteers is made public early enough that a reasonable 117 time can be given to resolve any disputes as to who should be in the 118 pool. 120 2.2 Publication of the Algorithm 122 The exact algorithm to be used, including the public future sources 123 of randomness, is made public. For example, the members of the final 124 list of eligible volunteers are ordered by publicly numbering them, 125 some public future sources of randomness such as government run 126 lotteries are specified, and an exact algorithm is specified whereby 127 eligible volunteers are selected based on a strong hash function [RFC 128 1750] of these future sources of randomness. 130 2.3 Publication of Selection 132 When the pre-specified sources of randomness produce their output, 133 those values plus a summary of the execution of the algorithm for 134 selection should be announced so that anyone can verify that the 135 correct randomness source values were used and the algorithm properly 136 executed. The algorithm can be run to select, in an ordered fashion, 137 a larger number than are actually necessary so that if any of those 138 selected need to be passed over or replaced for any reason, an 139 ordered set of additional alternate selections will be available. A 140 cut off time for any complaint that the algorithm was run with the 141 wrong inputs or not faithfully executed must be specified to finalize 142 the output and provide a stable selection. 144 3. Randomness 146 The crux of the unbiased nature of the selection is that it is based 147 in an exact, predetermined fashion on random information which will 148 be revealed in the future and thus can not be known to the person 149 specifying the algorithm. That random information will be used to 150 control the selection. The random information must be such that it 151 will be publicly and unambiguously revealed in a timely fashion. 153 The random sources must not include anything that any reasonable 154 person would believe to be under the control or influence of the IETF 155 or its components, such as IETF meeting attendance statistics, 156 numbers of documents issued, or the like. 158 3.1 Sources of Randomness 160 Examples of good information to use are winning lottery numbers for 161 specified runnings of specified public lotteries. Particularly for 162 government run lotteries, great care is taken to see that they occur 163 on time and produce random quantities. Even in the unlikely case one 164 were to have been rigged, it would almost certainly be in connection 165 with winning money in the lottery, not in connection with IETF use. 167 Other possibilities are such things as the daily balance in the US 168 Treasury on a specified day, the volume of trading on the New York 169 Stock exchange on a specified day, etc. (However, the reference code 170 given below will not handle integers that are too large.) Sporting 171 events can also be used. (Experience has indicated that stock prices 172 and/or volumes are a poor source of unambiguous data due trading 173 suspensions, company mergers, delistings, splits, multiple markets, 174 etc.) In all cases, great care must be taken to specify exactly what 175 quantities are being presumed random and what will be done if their 176 issuance is cancelled, delayed, or advanced. 178 It is important that the last source of randomness, chronologically, 179 produce a substantial amount of the entropy needed. If most of the 180 randomness has come from the earlier of the specified sources, and 181 someone has even limited influence on the final source, they might do 182 an exhaustive analysis and exert such influence so as to bias the 183 selection in the direction they wanted. Thus it is best for the last 184 source to be an especially strong and unbiased source of a large 185 amount of randomness such as a government run lottery. 187 It is best not to use too many different sources. Every additional 188 source increases the probability that one or more sources might be 189 delayed, cancelled, or just plain screwed up somehow, calling into 190 play contingency provisions or, worst of all, creating a situation 191 that was not anticipated. This would either require arbitrary 192 judgment by the selection administrator, defeating the randomness of 193 the selection, or a re-run with a new set of sources, causing much 194 delay. Three or four would be a good number of sources. Ten is too 195 many. 197 3.2 Skew 199 Some of the sources of randomness produce data that is not uniformly 200 distributed. This is certainly true of volumes, prices, and horse 201 race results, for example. However, use of a strong mixing function 202 [RFC 1750] will extract the available entropy and produce a hash 203 value whose bits, remainder modulo a small divisor, etc., deviate 204 from a uniform distribution only by an insignificant amount. 206 3.3 Entropy Needed 208 What we are doing is selecting N items without replacement from a 209 population of P items. The number of different ways to do this is as 210 follows, where "!" represents the factorial function: 212 P! 213 ------------- 214 N! * (P - N)! 216 To do this in a completely random fashion requires as many random 217 bits as the logarithm base 2 of that quantity. Some sample calculated 218 approximate number of random bits for the completely random selection 219 of 10 Nomcom members from various pool sizes is given below: 221 Random Selection of Ten Items From Pool 223 Pool size 20 25 30 35 40 50 60 75 100 120 224 Bits needed 18 22 25 28 30 34 37 40 44 47 226 Using an inadequate number of bits means that not all of the possible 227 sets of ten selected items would be available. For a substantially 228 inadequate amount of entropy, there could be a significant 229 correlation between the selection of two different members of the 230 pool, for example. However, as a practical matter, for pool sizes 231 likely to be encountered in IETF Nomcom membership selection, 40 bits 232 of entropy should always be adequate. Even if there is a large pool 233 and more bits are needed for perfect randomness, 40 bits of entropy 234 will assure only an insignificant deviation from completely random 235 selection for the difference in probability of selection of different 236 pool members, the correlation between the selection of any pair of 237 pool members, etc. 239 An MD5 [RFC 1321] hash has 128 bits and therefore can produce no more 240 than that number of bits of entropy. However, this is more than three 241 times what is likely to ever be needed for IETF Nomcom membership 242 selection. A even stronger hash, such as SHA-1 [RFC 3174], can be 243 used if desired. 245 4. A Suggested Precise Algorithm 247 It is important that a precise algorithm be given for mixing the 248 random sources specified and making the selection based thereon. 249 Sources suggested above produce either a single positive number 250 (i.e., NY Stock Exchange volume in thousands of shares) or a small 251 set of positive numbers (many lotteries provide 6 numbers in the 252 range of 1 through 40 or the like, a sporting event could produce the 253 scores of two teams, etc.). A suggested precise algorithm is as 254 follows: 256 1. For each source producing multiple numeric values, represent each 257 as a decimal number terminated by a period (or with a period 258 separating the whole from the fractional part), without leading 259 zeroes (except for a single leading zero if the integer part is 260 zero), and without trailing zeroes after the period. 262 2. Order the values from each source from smallest to the largest and 263 concatenate them and suffix the result with a "/". For each source 264 producing a single number, simply represent it as above with a 265 suffix "/". (This sorting is necessary because the same lottery 266 results, for example, are sometimes reported in the order numbers 267 were drawn and sometimes in numeric order and such things as the 268 scores of two sports teams that play a game has no inherent 269 order.) 271 3. At this point you have a string for each source, say s1/, s2/, ... 272 Concatenate these strings in a pre-specified order, the order in 273 which the sources were listed if not otherwise specified, and 274 represent each character as its ASCII code [ASCII] producing 275 "s1/s2/.../". 277 You then produce a sequence of random values derived from a strong 278 mixing of these sources by calculating the MD5 hash [RFC 1321] of 279 this string prefixed and suffixed with an all zeros two byte sequence 280 for the first value, the string prefixed and suffixed by 0x0001 for 281 the second value, etc., treating the two bytes as a big endian 282 counter. Treat each of these derived "random" MD5 output values as a 283 positive 128-bit multiprecision big endian integer. 285 Then totally order the pool of listed volunteers as follows: If there 286 are P volunteers, select the first by dividing the first derived 287 random value by P and using the remainder plus one as the position of 288 the selectee in the published list. Select the second by dividing the 289 second derived random value by P-1 and using the remainder plus one 290 as the position in the list with the first selected person 291 eliminated. Etc. 293 It is STRONGLY recommended that alphanumeric random sources be 294 avoided due to the much greater difficulty in canonicalizing them in 295 an independently repeatable fashion; however, if you choose to ignore 296 this advice and use an ASCII or similar Roman alphabet source or 297 sources, all white space, punctuation, accents, and special 298 characters should be removed and all letters set to upper case. This 299 will leave only an unbroken sequence of letters A-Z and digits 0-9 300 which can be treated as a canonicalized number above and suffixed 301 with a "./". If you choose to not just ignore but flagrantly flout 302 this advice and try to use even more complex and harder to 303 canonicalize internationalized text, such as UNICODE, you are on your 304 own. 306 5. Handling Real World Problems 308 In the real world, problems can arise in following the steps and flow 309 outlined in Sections 2 through 4 above. Some problems that have 310 actually arisen are described below with recommendations for handling 311 them. 313 5.1 Uncertainty as to the Pool 315 Every reasonable effort should be made to see that the published pool 316 from which selection is made is of certain and eligible persons. 317 However, especially with compressed schedules or perhaps someone 318 whose claim that they volunteered and are eligible has not been 319 resolved by the deadline, or a determination that someone is not 320 eligible which occurs after the publication of the pool, it may be 321 that there are still uncertainties. 323 The best way to handle this is to maintain the announced schedule, 324 INCLUDE in the published pool all those whose eligibility is 325 uncertain and to keep the published pool list numbering IMMUTABLE 326 after its publication. If someone in the pool is later selected by 327 the algorithm and random input but it has been determined they are 328 ineligible, they can be skipped and the algorithm run further to make 329 an additional selection. Thus the uncertainty only effects one 330 selection and in general no more than a maximum of U selections where 331 there are U uncertain pool members. 333 Other courses of action are far worse. Actual insertion or deletion 334 of entries in the pool after its publication changes the length of 335 the list and totally scrambles who is selected, possibly changing 336 every selection. Insertion into the pool raises questions of where to 337 insert: at the beginning, end, alphabetic order, ... Any such choices 338 by the selection administrator after the random numbers are known 339 destroys the public verifiability of fair choice. Even if done before 340 the random numbers are known, such dinking with the list after its 341 publication just smells bad. There should be clear fixed public 342 deadlines and someone who challenges their absence from the pool 343 after the published deadline should have their challenge 344 automatically denied for tardiness. 346 5.2 Randomness Ambiguities 348 The best good faith efforts have been made to specify precise and 349 unambiguous sources of randomness. These sources have been made 350 public in advance and there has not been objection to them. However, 351 it has happened that when the time comes to actually get and use this 352 randomness, the real world has thrown a curve ball and it isn't quite 353 clear what data to use. Problems have particularly arisen in 354 connection with stock prices, volumes, and financial exchange rates 355 or indices. If volumes that were published in thousands are published 356 in hundreds, you have a rounding problem. Prices that were quoted in 357 fractions or decimals can change to the other. If you take care of 358 every contingency that has come up in the past, you can be hit with a 359 new one. When this sort of thing happens, it is generally too late to 360 announce new sources, an action which could raise suspicions of its 361 own. About the only course of action is to make a reasonable choice 362 within the ambiguity and depend on confidence in the good faith of 363 the selection administrator. With care, such cases should be 364 extremely rare. 366 Based on these experiences, it is again recommended that public 367 lottery numbers or the like be used as the random inputs and stock 368 prices and volumes avoided. 370 6. Fully Worked Example 372 Assume the following ordered list of 25 eligible volunteers is 373 published in advance of selection: 375 1. John 11. Pollyanna 21. Pride 376 2. Mary 12. Pendragon 22. Sloth 377 3. Bashful 13. Pandora 23. Envy 378 4. Dopey 14. Faith 24. Anger 379 5. Sleepy 15. Hope 25. Kasczynski 380 6. Grouchy 16. Charity 381 7. Doc 17. Lee 382 8. Sneazy 18. Longsuffering 383 9. Handsome 19. Chastity 384 10. Cassandra 20. Smith 386 Assume the following (fake example) ordered list of randomness 387 sources: 388 1. The Kingdom of Alphaland State Lottery daily number for 1 November 389 2004 treated as a single four digit integer. 390 2. Numbers of the winning horses at Hialeia for all races for the 391 first day on or after 13 October 2004 on which at least two races 392 are run. 393 3. The People's Democratic Republic of Betastani State Lottery six 394 winning numbers (ignoring the seventh "extra" number) for 1 395 November 2004. 397 Hypothetical randomness publicly produced: 398 Source 1: 9319 399 Source 2: 2, 5, 12, 8, 10 400 Source 3: 9, 18, 26, 34, 41, 45 402 Resulting key string: 404 9319./2.5.8.10.12./9.18.26.34.41.45./ 406 The table below gives the hex of the MD5 of the above key string 407 bracketed with a two byte string that is successively 0x0000, 0x0001, 408 0x0002, through 0x0010 (16 decimal). The divisor for the number size 409 of the remaining pool at each stage is given and the index of the 410 selectee as per the original number of those in the pool. 412 index hex value of MD5 div selected 413 1 990DD0A5692A029A98B5E01AA28F3459 25 -> 17 <- 414 2 3691E55CB63FCC37914430B2F70B5EC6 24 -> 7 <- 415 3 FE814EDF564C190AC1D25753979990FA 23 -> 2 <- 416 4 1863CCACEB568C31D7DDBDF1D4E91387 22 -> 16 <- 417 5 F4AB33DF4889F0AF29C513905BE1D758 21 -> 25 <- 418 6 13EAEB529F61ACFB9A29D0BA3A60DE4A 20 -> 23 <- 419 7 992DB77C382CA2BDB9727001F3CDCCD9 19 -> 8 <- 420 8 63AB4258ECA922976811C7F55C383CE7 18 -> 24 <- 421 9 DFBC5AC97CED01B3A6E348E3CC63F40D 17 -> 19 <- 422 10 31CB111C4A4EBE9287CEAE16FE51B909 16 -> 13 <- 423 11 07FA46C122F164C215BBC72793B189A3 15 -> 22 <- 424 12 AC52F8D75CCBE2E61AFEB3387637D501 14 -> 5 <- 425 13 53306F73E14FC0B2FBF434218D25948E 13 -> 18 <- 426 14 B5D1403501A81F9A47318BE7893B347C 12 -> 9 <- 427 15 85B10B356AA06663EF1B1B407765100A 11 -> 1 <- 428 16 3269E6CE559ABD57E2BA6AAB495EB9BD 10 -> 4 <- 430 Resulting first ten selected, in order selected: 432 1. Lee (17) 6. Envy (23) 433 2. Doc (7) 7. Sneazy (8) 434 3. Mary (2) 8. Anger (24) 435 4. Charity (16) 9. Chastity (19) 436 5. Kasczynski (25) 10. Pandora (13) 438 Should one of the above turn out to be ineligible or decline to 439 serve, the next would be Sloth, number 22. 441 7. Security Considerations 443 Careful choice of should be made of randomness inputs so that there 444 is no reasonable suspicion that they are under the control of the 445 administrator. Guidelines given above to use a small number of inputs 446 with a substantial amount of entropy from the last should be 447 followed. And equal care needs to be given that the algorithm 448 selected is faithfully executed with the designated inputs values. 449 Publication of the results and a week or so window for the community 450 of interest to duplicate the calculations should give a reasonable 451 assurance against implementation tampering. 453 8. Reference Code 455 This code makes use of the MD5 reference code from [RFC 1321] ("RSA 456 Data Security, Inc. MD5 Message-Digest Algorithm"). The portion of 457 the code dealing with multiple floating point numbers was written by 458 Matt Crawford. The original code in RFC 2777 could only handle pools 459 of up to 255 members and was extended to 2**16-1 by Erik Nordmark. 460 This code has been extracted from this document, compiled, and 461 tested. While no flaws have been found, it is possible that when used 462 with some compiler on some system some flaw will manifest itself. 464 /**************************************************************** 465 * 466 * Reference code for 467 * "Publicly Verifiable Random Selection" 468 * Donald E. Eastlake 3rd 469 * February 2004 470 * 471 ****************************************************************/ 472 #include 473 #include 474 #include 475 #include 476 #include 478 /* From RFC 1321 */ 479 #include "global.h" 480 #include "MD5.h" 482 /* local prototypes */ 483 int longremainder ( unsigned short divisor, 484 unsigned char dividend[16] ); 485 long int getinteger ( char *string ); 486 double NPentropy ( int N, int P ); 488 /* limited to up to 16 inputs of up to sixteen integers each */ 489 /* pool limit of 2**8-1 extended to 2**16-1 by Erik Nordmark */ 490 /****************************************************************/ 491 main () 492 { 493 int i, j, k, k2, err, keysize, selection, usel; 494 unsigned short remaining, *selected; 495 long int pool, temp, array[16]; 496 MD5_CTX ctx; 497 char buffer[257], key [800], sarray[16][256]; 498 unsigned char uc16[16], unch1, unch2; 500 pool = getinteger ( "Type size of pool:\n" ); 501 if ( pool > 65535 ) 503 { 504 printf ( "Pool too big.\n" ); 505 exit ( 1 ); 506 } 507 selected = (unsigned short *) malloc ( (size_t)pool ); 508 if ( !selected ) 509 { 510 printf ( "Out of memory.\n" ); 511 exit ( 1 ); 512 } 513 selection = getinteger ( "Type number of items to be selected:\n" ); 514 if ( selection > pool ) 515 { 516 printf ( "Pool too small.\n" ); 517 exit ( 1 ); 518 } 519 if ( selection == pool ) 520 printf ( "All of the pool is selected.\n" ); 521 else 522 { 523 err = printf ( "Approximately %.1f bits of entropy needed.\n", 524 NPentropy ( selection, pool ) + 0.1 ); 525 if ( err <= 0 ) exit ( 1 ); 526 } 527 for ( i = 0, keysize = 0; i < 16; ++i ) 528 { 529 if ( keysize > 500 ) 530 { 531 printf ( "Too much input.\n" ); 532 exit ( 1 ); 533 } 534 /* get the "random" inputs. echo back to user so the user may 535 be able to tell if truncation or other glitches occur. */ 536 err = printf ( 537 "\nType #%d randomness or 'end' followed by new line.\n" 538 "Up to 16 integers or the word 'float' followed by up\n" 539 "to 16 x.y format reals.\n", i+1 ); 540 if ( err <= 0 ) exit ( 1 ); 541 gets ( buffer ); 542 j = sscanf ( buffer, 543 "%ld%ld%ld%ld%ld%ld%ld%ld%ld%ld%ld%ld%ld%ld%ld%ld", 544 &array[0], &array[1], &array[2], &array[3], 545 &array[4], &array[5], &array[6], &array[7], 546 &array[8], &array[9], &array[10], &array[11], 547 &array[12], &array[13], &array[14], &array[15] ); 548 if ( j == EOF ) 549 exit ( j ); 550 if ( !j ) 551 if ( buffer[0] == 'e' ) 552 break; 554 else 555 { /* floating point code by Matt Crawford */ 556 j = sscanf ( buffer, 557 "float %ld.%[0-9]%ld.%[0-9]%ld.%[0-9]%ld.%[0-9]" 558 "%ld.%[0-9]%ld.%[0-9]%ld.%[0-9]%ld.%[0-9]" 559 "%ld.%[0-9]%ld.%[0-9]%ld.%[0-9]%ld.%[0-9]" 560 "%ld.%[0-9]%ld.%[0-9]%ld.%[0-9]%ld.%[0-9]", 561 &array[0], sarray[0], &array[1], sarray[1], 562 &array[2], sarray[2], &array[3], sarray[3], 563 &array[4], sarray[4], &array[5], sarray[5], 564 &array[6], sarray[6], &array[7], sarray[7], 565 &array[8], sarray[8], &array[9], sarray[9], 566 &array[10], sarray[10], &array[11], sarray[11], 567 &array[12], sarray[12], &array[13], sarray[13], 568 &array[14], sarray[14], &array[15], sarray[15] ); 569 if ( j == 0 || j & 1 ) 570 printf ( "Bad format." ); 571 else { 572 for ( k = 0, j /= 2; k < j; k++ ) 573 { 574 /* strip trailing zeros */ 575 for ( k2=strlen(sarray[k]); sarray[k][--k2]=='0';) 576 sarray[k][k2] = '\0'; 577 err = printf ( "%ld.%s\n", array[k], sarray[k] ); 578 if ( err <= 0 ) exit ( 1 ); 579 keysize += sprintf ( &key[keysize], "%ld.%s", 580 array[k], sarray[k] ); 581 } 582 keysize += sprintf ( &key[keysize], "/" ); 583 } 584 } 585 else 586 { /* sort values, not a very efficient algorithm */ 587 for ( k2 = 0; k2 < j - 1; ++k2 ) 588 for ( k = 0; k < j - 1; ++k ) 589 if ( array[k] > array[k+1] ) 590 { 591 temp = array[k]; 592 array[k] = array[k+1]; 593 array[k+1] = temp; 594 } 595 for ( k = 0; k < j; ++k ) 596 { /* print for user check */ 597 err = printf ( "%ld ", array[k] ); 598 if ( err <= 0 ) exit ( 1 ); 599 keysize += sprintf ( &key[keysize], "%ld.", array[k] ); 600 } 601 keysize += sprintf ( &key[keysize], "/" ); 602 } 603 } /* end for i */ 605 /* have obtained all the input, now produce the output */ 606 err = printf ( "Key is:\n %s\n", key ); 607 if ( err <= 0 ) exit ( 1 ); 608 for ( i = 0; i < pool; ++i ) 609 selected [i] = (unsigned short)(i + 1); 610 printf ( "index hex value of MD5 div selected\n" ); 611 for ( usel = 0, remaining = (unsigned short)pool; 612 usel < selection; 613 ++usel, --remaining ) 614 { 615 unch1 = (unsigned char)usel; 616 unch2 = (unsigned char)(usel>>8); 617 /* prefix/suffix extended to 2 bytes by Donald Eastlake */ 618 MD5Init ( &ctx ); 619 MD5Update ( &ctx, &unch2, 1 ); 620 MD5Update ( &ctx, &unch1, 1 ); 621 MD5Update ( &ctx, (unsigned char *)key, keysize ); 622 MD5Update ( &ctx, &unch2, 1 ); 623 MD5Update ( &ctx, &unch1, 1 ); 624 MD5Final ( uc16, &ctx ); 625 k = longremainder ( remaining, uc16 ); 626 /* printf ( "Remaining = %d, remainder = %d.\n", remaining, k ); */ 627 for ( j = 0; j < pool; ++j ) 628 if ( selected[j] ) 629 if ( --k < 0 ) 630 { 631 printf ( "%2d " 632 "%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X " 633 "%2d -> %2d <-\n", 634 usel+1, uc16[0],uc16[1],uc16[2],uc16[3],uc16[4],uc16[5],uc16[6], 635 uc16[7],uc16[8],uc16[9],uc16[10],uc16[11],uc16[12],uc16[13],uc16[14], 636 uc16[15], remaining, selected[j] ); 637 selected[j] = 0; 638 break; 639 } 640 } 642 printf ( "\nDone, type any character to exit.\n" ); 643 getchar (); 644 return 0; 645 } 647 /* prompt for a positive non-zero integer input */ 648 /****************************************************************/ 649 long int getinteger ( char *string ) 650 { 651 long int i; 652 int j; 653 char tin[257]; 655 while ( 1 ) 656 { 657 printf ( string ); 658 printf ( "(or 'exit' to exit) " ); 659 gets ( tin ); 660 j = sscanf ( tin, "%ld", &i ); 661 if ( ( j == EOF ) 663 || ( !j && ( ( tin[0] == 'e' ) || ( tin[0] == 'E' ) ) ) 664 ) 665 exit ( j ); 666 if ( ( j == 1 ) && 667 ( i > 0 ) ) 668 return i; 669 } /* end while */ 670 } 672 /* get remainder of dividing a 16 byte unsigned int 673 by a small positive number */ 674 /****************************************************************/ 675 int longremainder ( unsigned short divisor, 676 unsigned char dividend[16] ) 677 { 678 int i; 679 long int kruft; 681 if ( !divisor ) 682 return -1; 683 for ( i = 0, kruft = 0; i < 16; ++i ) 684 { 685 kruft = ( kruft << 8 ) + dividend[i]; 686 kruft %= divisor; 687 } 688 return kruft; 689 } /* end longremainder */ 691 /* calculate how many bits of entropy it takes to select N from P */ 692 /****************************************************************/ 693 /* P! 694 log ( ----------------- ) 695 2 N! * ( P - N )! 696 */ 698 double NPentropy ( int N, int P ) 699 { 700 int i; 701 double result = 0.0; 703 if ( ( N < 1 ) /* not selecting anything? */ 704 || ( N >= P ) /* selecting all of pool or more? */ 705 ) 706 return 0.0; /* degenerate case */ 707 for ( i = P; i > ( P - N ); --i ) 708 result += log ( i ); 709 for ( i = N; i > 1; --i ) 710 result -= log ( i ); 711 /* divide by [ log (base e) of 2 ] to convert to bits */ 712 result /= 0.69315; 714 return result; 715 } /* end NPentropy */ 717 Appendix A: History of NomCom Member Selection 719 For reference purposes, here is a list of the IETF Nominations 720 Committee member selection techniques and chairs so far: 722 YEAR CHAIR SELECTION METHOD 724 1993/1994 Jeff Case Clergy 725 1994/1995 Fred Baker Clergy 726 1995/1996 Guy Almes Clergy 727 1996/1997 Geoff Huston Spouse 728 1997/1998 Mike St.Johns Algorithm 729 1998/1999 Donald Eastlake 3rd RFC 2777 730 1999/2000 Avri Doria RFC 2777 731 2000/2001 Bernard Aboba RFC 2777 732 2001/2002 Theodore Ts'o RFC 2777 733 2002/2003 Phil Roberts RFC 2777 734 2003/2004 Rich Draves RFC 2777 736 Clergy = Names were written on pieces of paper, placed in a 737 receptacle, and a member of the clergy picked the NomCom members. 739 Spouse = Same as Clergy except chair's spouse made the selection. 741 Algorithm = Algorithmic selection based on similar concepts to those 742 documented in RFC 2777 and herein. 744 RFC 2777 = Algorithmic selection using the algorithm and reference 745 code provided in RFC 2777 (but not the fake example sources of 746 randomness). 748 Appendix B: Changes from RFC 2777 750 This document differs from [RFC 2777], the previous version, in three 751 primary ways as follows: 753 (1) Section 5, on problems actually encountered with using these 754 recommendations for selecting an IETF nomcom and on how to handle 755 them, has been added. 757 (2) The selection algorithm code has been modified to handle pools of 758 up to 2**16-1 elements and the counter based prefix and suffix 759 concatenated with the key string before hashing has been extended 760 to two bytes. 762 (3) Mention has been added that the algorithm documented herein was 763 used by IANA to select the Internationalized Domain Name ACE 764 prefix and some minor wording changes made. 766 (4) References have been divided into Informative and Normative. 768 (5) The list in Appendix A has been brought up to date. 770 Informative References 772 [2727bis] - draft-ietf-nomcom-rfc2727bis-*.txt, "IAB and IESG 773 Selection, Confirmation, and Recall Process: Operation of the 774 Nominating and Recall Committees", work in progress, J. Galvin, 775 October 2003. 777 [RFC 2777] - "Publicly Verifiable Nomcom Random Selection", D. 778 Eastlake, February 2000. 780 [RFC 3490] - "Internationalizing Domain Names in Applications 781 (IDNA)", P. Faltstrom, P. Hoffman, A. Costello, March 2003. 783 Normative References 785 [ASCII] - "USA Standard Code for Information Interchange", X3.4, 786 American National Standards Institute: New York, 1968. 788 [RFC 1321] - "The MD5 Message-Digest Algorithm", R. Rivest. April 789 1992. 791 [RFC 1750] - "Randomness Recommendations for Security", D. Eastlake, 792 3rd, S. Crocker & J. Schiller. December 1994. 794 [RFC 3174] - "US Secure Hash Algorithm 1 (SHA1)", D. Eastlake, 3rd, 795 P. Jones, September 2001. 797 Author's Address 799 Donald E. Eastlake, 3rd 800 Motorola Laboratories 801 155 Beaver Street 802 Milford, MA 01757 USA 804 tel: +1-508-786-7554(w) 805 +1-508-634-2066(h) 806 email: Donald.Eastlake@motorola.com 808 File name and Expiration 810 This file is draft-eastlake-rfc2777bis-selection-04.txt. 812 It expires September 2004.