RFC3797 日本語訳
3797 Publicly Verifiable Nominations Committee (NomCom) RandomSelection. D. Eastlake 3rd. June 2004. (Format: TXT=39883 bytes) (Obsoletes RFC2777) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Eastlake 3rd Request for Comments: 3797 Motorola Laboratories Obsoletes: 2777 June 2004 Category: Informational
コメントを求めるワーキンググループのD.イーストレーク第3要求をネットワークでつないでください: 3797のモトローラ研究所が以下を時代遅れにします。 2777 2004年6月のカテゴリ: 情報
Publicly Verifiable Nominations Committee (NomCom) Random Selection
公的に証明可能な指名委員会(NomCom)ランダム・セレクション
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(2004)。
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 (NomCom) from the pool of eligible volunteers is used. Similar techniques would be applicable to other cases.
このドキュメントは選択の不遍の本質が公的に証明可能であるような方法でランダム・セレクションをするための方法を説明します。 例として、適任のボランティアのプールからのIETF Nominations Committee(NomCom)の投票会員の品揃えは使用されています。 同様のテクニックは他のケースに適切でしょう。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. General Flow of a Publicly Verifiable Process . . . . . . . . . 2
2.1. Determination of the Pool . . . . . . . . . . . . . . . . 2
2.2. Publication of the Algorithm. . . . . . . . . . . . . . . 3
2.3. Publication of Selection. . . . . . . . . . . . . . . . . 3
3. Randomness. . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Sources of Randomness . . . . . . . . . . . . . . . . . . 3
3.2. Skew. . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Entropy Needed. . . . . . . . . . . . . . . . . . . . . . 4
4. A Suggested Precise Algorithm . . . . . . . . . . . . . . . . . 5
5. Handling Real World Problems. . . . . . . . . . . . . . . . . . 7
5.1. Uncertainty as to the Pool. . . . . . . . . . . . . . . . 7
5.2. Randomness Ambiguities. . . . . . . . . . . . . . . . . . 7
6. Fully Worked Example. . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 9
8. Reference Code. . . . . . . . . . . . . . . . . . . . . . . . . 10
Appendix A: History of NomCom Member Selection . . . . . . . . . . 16
Appendix B: Changes from RFC 2777. . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 17
1. 序論。 . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. 公的に証明可能な過程. . . . . . . . . 2 2.1の一般流れ。 プール. . . . . . . . . . . . . . . . 2 2.2の決断。 アルゴリズムの公表。 . . . . . . . . . . . . . . 3 2.3. 選択の公表。 . . . . . . . . . . . . . . . . 3 3. 偶発性。 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. 偶発性. . . . . . . . . . . . . . . . . . 3 3.2の源。 歪曲します。 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. 必要であるエントロピー。 . . . . . . . . . . . . . . . . . . . . . 4 4. 提案された正確なアルゴリズム. . . . . . . . . . . . . . . . . 5 5。 本当の世界問題7………………5.1を扱います。 プールに関する不確実性。 . . . . . . . . . . . . . . . 7 5.2. 偶発性のあいまいさ。 . . . . . . . . . . . . . . . . . 7 6. 完全に扱われた例。 . . . . . . . . . . . . . . . . . . . . . 8 7. セキュリティ問題. . . . . . . . . . . . . . . . . . . . 9 8。 参照コード。 . . . . . . . . . . . . . . . . . . . . . . . . 10 付録A: NomComメンバー選択. . . . . . . . . . 16付録Bの歴史: RFC2777からの変化。 . . . . . . . . . . . . . . . . 16の承認. . . . . . . . . . . . . . . . . . . . . . . . . 17
Eastlake 3rd Informational [Page 1] RFC 3797 Verifiable Random Selection June 2004
証明可能な[1ページ]RFC3797ランダム・セレクション2004年6月の3番目に情報のイーストレーク
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Normative References. . . . . . . . . . . . . . . . . . . . . . 17
Informative References. . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 19
参照. . . . . . . . . . . . . . . . . . . . . . . . . . . . 17引用規格。 . . . . . . . . . . . . . . . . . . . . . 17 有益な参照。 . . . . . . . . . . . . . . . . . . . . 17作者のアドレスの.18の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
1. 序論
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 3777]. The number of eligible volunteers in recent years has been around 100.
IETF規則の下では、毎年、10人の人、IETF指名委員会(NomCom)の投票会員になるように適任のボランティアの中で手当たりしだいに選び抜かれます。 NomComは[RFC3777]で説明されるようにEngineering Steering Group(IESG)とインターネット・アーキテクチャ委員会(IAB)にインターネットのメンバーを指名します。 近年適任のボランティアの数はおよそ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.
バイアスかえこひいきのどんな手頃な告発も起こされることができないように疑いようのないファッションで票のNomComのランダム・セレクションをするのは非常に望ましいです。 これはそれがIETFの保護のためのものであるように多くとしてバイアスの容疑からの選択管理者(現在の指定している非票のNomComいす)の保護のためのものです。
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.
方法、公開情報が、どんな人も選択の偶発性について確かめるのを可能にするようなものはこの評価基準を満たします。 このドキュメントはそのような方法に関する例を出します。
The method, in the form it appears in RFC 2777, was also used by IANA in February 2003 to determine the ACE prefix for Internationalized Domain Names [RFC 3490] so as to avoid claim jumping.
また、方法は、2003年2月にクレームジャンプを避けて、Internationalized Domain Names[RFC3490]のためにACE接頭語を決定するのにそれがRFC2777で見えるフォームでIANAによって使用されました。
2. General Flow of a Publicly Verifiable Process
2. 公的に証明可能な過程の一般流れ
A selection of NomCom members publicly verifiable as unbiased or similar selection could follow the three steps given below.
不遍として公的に証明可能な数人のNomComメンバーか同様の選択が以下に与えられた3つの方法に従うかもしれません。
2.1. Determination of the Pool
2.1. プールの決断
First, determine the pool from which the selection is to be made as provided in [RFC 3777] or its successor.
まず最初に、[RFC3777]かその後継者に提供するように作られる選択がことであるプールを決定してください。
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.
ボランティアは選択管理者によって請求されます。 そして、それらの名前は、適任をチェックするためにIETF事務局に通り抜けます。 (現在の適任評価基準は出席を達成するIETFに関連します。)その記録は事務局によって保守されます。 適任のボランティアの完全リストが十分早く公表されるので、だれがプールの中にいるべきであるかに関して妥当な時間をどんな論争も解決させることができます。
Eastlake 3rd Informational [Page 2] RFC 3797 Verifiable Random Selection June 2004
証明可能な[2ページ]RFC3797ランダム・セレクション2004年6月の3番目に情報のイーストレーク
2.2. Publication of the Algorithm
2.2. アルゴリズムの公表
The exact algorithm to be used, including the public future sources of randomness, is made public. For example, the members of the final list of eligible volunteers are ordered by publicly numbering them, 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.
偶発性の公共の将来の源を含んでいて、使用されるべき正確なアルゴリズムは公表されます。 例えば、適任のボランティアが選ばれる適任のボランティアが公的に彼らに付番することによって命令されて、政府走行宝くじなどの偶発性の何人かの公共の将来の源が指定されて、正確なアルゴリズムが指定されるのを最終的なリストのメンバーの偶発性のこれらの将来の源の[RFC1750]は強いハッシュ関数に基づいていました。
2.3. Publication of Selection
2.3. 選択の公表
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. The algorithm can be run to select, in an ordered fashion, a larger number than are actually necessary so that if any of those selected need to be passed over or replaced for any reason, an ordered set of additional alternate selections will be available. A cut off time for any complaint that the algorithm was run with the wrong inputs or not faithfully executed must be specified to finalize the output and provide a stable selection.
偶発性のあらかじめ指定された源が彼らの出力を起こすと、選択のためのアルゴリズムの実行のそれらの値と概要は、だれでも正しい偶発性ソース値が使用されていて、アルゴリズムが適切に実行されていたことを確かめることができるように、発表されるべきです。 それらのどれかが通り過ぎられるべきであるか、またはどんな理由でも取り替えられるべき必要性を選択したなら、1つの順序集合の追加交互の選択が利用可能になって、アルゴリズムは、規則正しいファッションで実際に必要とするより大きい数を選択するために走ることができます。 出力を成立させて、安定した選択を提供するためにどんな苦情のための忠実に実行されて、アルゴリズムが間違った入力か否かに関係なく、走った時間のカットも指定しなければなりません。
3. Randomness
3. 偶発性
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.
無作為のソースはどんな道理をわきまえた人もIETFのコントロールか影響でいると信じているものは何も、ドキュメントの数がIETFミーティング出席統計などのように発行したコンポーネント、または同様のものも入れてはいけません。
3.1. Sources of Randomness
3.1. 偶発性の源
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 occur on time and 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.
使用する良い情報に関する例は指定された公共の宝くじの指定された走力の抽選番号を得ています。 特に政府走行宝くじにおいて、それらが定刻に起こるのがわかって、無作為の量を生産するために高度の注意を取ります。 ありそうもない場合ではさえ、1つは装備されることになっていて、IETF使用で得るのではなく、宝くじでお金を得ることに関してそれはほぼ確実にあるでしょう。
Eastlake 3rd Informational [Page 3] RFC 3797 Verifiable Random Selection June 2004
証明可能な[3ページ]RFC3797ランダム・セレクション2004年6月の3番目に情報のイーストレーク
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 and/or volumes are a poor source of unambiguous data due trading suspensions, company 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, delayed, or advanced.
他の可能性は指定された日の米国債における日計表、指定された日のニューヨークStock交換の取引高などのようにものです。 (しかしながら、以下に与えられた参照コードは大き過ぎる整数を扱わないでしょう。) また、スポーツ競技を使用できます。 (経験は、株価、そして/または、ボリュームがデータの明白な支払われるべきもの取り引きサスペンション、会社の合併、「反-リスト」、股割り、複数の市場などの貧しい源であることを示しました) すべての場合では、どんな量が無作為であると推定されているか、そして、それらの発行が取り消されるか、遅らせられるか、または進められると何が終わるかをまさに指定するために高度の注意を取らなければなりません。
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 with a new set of sources, causing much delay. Three or four would be a good number of sources. Ten is too many.
あまりに多くのさまざまな原因を使用しないのは最も良いです。 すべての追加ソースが1つ以上のソースが遅らせて、取り消されたかもしれないか、プレー偶然性条項にちょっと立ち寄って、まさしく平野がどうにかへまをしたか、または状況を作成して、すべてでは、最もひどく、それが予期されなかったという確率を増加させます。 これは選択管理者による任意の判断を必要とするでしょう、選択の偶発性、または新しいセットの源による再放送を破って、多くの遅れを引き起こして。 3か4が多くのソースでしょう。 10は多く過ぎます。
3.2. Skew
3.2. 斜行
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., deviate from a uniform distribution only by an insignificant amount.
偶発性の源のいくつかが一様に分配されないデータを作り出します。 確かに、これは例えば、ボリューム、価格、および競馬結果に関して本当です。 しかしながら、単にわずかな量に従って、強い混合機能[RFC1750]の使用は、有効なエントロピーを抽出に望んでいて、ビット、残りの法のaわずかな除数などが逸れる生産物aハッシュ値に一様分布を望んでいます。
3.3. Entropy Needed
3.3. 必要であるエントロピー
What we are doing is selecting 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! * (P - N)!
P! ------------- N! * (P--N!)
Eastlake 3rd Informational [Page 4] RFC 3797 Verifiable Random Selection June 2004
証明可能な[4ページ]RFC3797ランダム・セレクション2004年6月の3番目に情報のイーストレーク
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 completely random selection of 10 NomCom members from various pool sizes is given below:
完全に無作為のファッションでこれをするのはその2つの量の対数ベースと同じくらい多くの無作為のビットを必要とします。 様々なプール・サイズからの10人のNomComメンバーの完全に無作為の品揃えのための何らかのサンプルの計算された概数の無作為のビットを以下に与えます:
Random Selection of Ten Items From Pool
プールからの10の項目のランダム・セレクション
Pool size 20 25 30 35 40 50 60 75 100 120
Bits needed 18 22 25 28 30 34 37 40 44 47
プール・サイズ20 25 30 35 40 50 60 75 100 120Bitsが18 22 25 28 30 34 37 40 44 47を必要としました。
Using an inadequate number of bits means that not all of the possible sets of ten selected items would be available. For a substantially inadequate amount of entropy, there could be a significant 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 more bits are needed for perfect 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.
不十分な数のビットを使用するのは、10の選択した項目の可能なセットのすべてが利用可能であるというわけではないことを意味します。 実質的に不十分な量のエントロピーのために、例えば、プールの2個の異なった部材の品揃えの間には、重要な相関関係があるかもしれません。 しかしながら、実際問題としてIETF NomCom会員資格選択で遭遇しそうなプール・サイズにおいて、エントロピーの40ビットはいつも適切であるべきです。 大きいプールがあり、より多くのビットが完全な偶発性に必要であっても、エントロピーの40ビットは異なったプールメンバーの品揃えの確率の違い、プールメンバーのどんな組の選択などの間の相関関係のための完全に無作為の選択からのわずかな逸脱だけを保証するでしょう。
An MD5 [RFC 1321] hash has 128 bits and therefore can produce no more than that number of bits of entropy. However, this is more than 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.
MD5[RFC1321]細切れ肉料理は、128ビットを持って、したがって、エントロピーのその数のビットだけを作り出すことができます。 しかしながら、これは今までにIETF NomCom会員資格選択に必要でありそうなものの3倍以上です。 望まれているなら、SHA-1などのさらに強い細切れ肉料理[RFC3174]を使用できます。
4. A Suggested Precise Algorithm
4. 提案された正確なアルゴリズム
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 suggested precise algorithm is as follows:
指定されて、選択をその上に基づかせている無作為のソースを混合するために正確なアルゴリズムを与えるのは重要です。 情報筋は、ただ一つの正の数(すなわち、何千ものシェアにおけるニューヨーク証券取引所ボリューム)か小さい正の数のどちらかが上で生産されることを(多くの宝くじが1〜40か同様のものの範囲に6つの番号を提供して、スポーツ競技は2つのチームなどのスコアを生産するかもしれません)提案しました。 提案された正確なアルゴリズムは以下の通りです:
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), without
leading zeroes (except for a single leading zero if the integer
part is zero), and without trailing zeroes after the period.
1. 複数の数値を生産する各ソースに、主なゼロ(シングル以外の、整数部であるなら、先行ゼロはゼロである)なしで期間の後の末尾のゼロなしで期間(または期間が断片的な部分と全体を切り離していて)までに終えられた10進数をそれぞれ表してください。
Eastlake 3rd Informational [Page 5] RFC 3797 Verifiable Random Selection June 2004
証明可能な[5ページ]RFC3797ランダム・セレクション2004年6月の3番目に情報のイーストレーク
2. Order the values from each source 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
and such things as the scores of two sports teams that play a
game has no inherent order.)
2. 「それらを連結して、各ソースから値を最も小さいのから最も大きくなるまで取り寄せてください。そうすれば、接尾語はa」/がある結果を連結します。」 「1つの数を生産する各ソースに上として接尾語で単にそれを表してください」/、」 (このソーティングは、注文番号が例えば、同じ宝くじ結果で時々報告されるので描かれたのが必要であり、時々ゲームをする2つのスポーツチームのスコアとしての数値注文とそのようなものにどんな固有のオーダーも持っていません。)
3. At this point you have a string for each source, say s1/, s2/,
... Concatenate these strings in a pre-specified order, the
order in which the sources were listed if not otherwise
specified, and represent each character as its ASCII code
[ASCII] producing "s1/s2/.../".
3. s1/、s2/は、ここに、あなたには各ソースへのストリングがあると言います… あらかじめ指定されたオーダーでこれらのストリングを連結してください、情報筋が記載されたか、または別の方法で指定されて、"s1/s2/"を生産しながらASCIIコード[ASCII]として各キャラクタの代理をするオーダー…/".
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 an all zeros two byte sequence for the first value, the string prefixed and suffixed by 0x0001 for the second value, etc., treating the two bytes as a big endian counter. Treat each of these derived "random" MD5 output values as a positive 128-bit multiprecision big endian integer.
次に、あなたはこのストリングのMD5細切れ肉料理[RFC1321]が最初の値、2番目の値のための0×0001などによって前に置かれていて、suffixedされたストリングのためにすべてのゼロで2バイト列を前に置いて、suffixedしたと見込むことによってこれらのソースの強い混合から得られた無作為の値の系列を作成します、ビッグエンディアンカウンタとして2バイトを扱って。 それぞれこれらのトリートは陽の128ビットの多倍精度ビッグエンディアン整数として「無作為」のMD5出力値を引き出しました。
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.
次に、以下の記載されたボランティアのプールを完全に注文してください: Pボランティアがいれば、最初の派生している無作為の値をPに割って、応召兵の地位として発行されたリストで残りと1つを使用することによって、1番目を選択してください。 最初の選択された人がいるリストの見解が排泄されながら、2番目の派生している無作為の値をP-1に割って、残りと1つを使用することによって、2番目を選択してください。 など
It is STRONGLY recommended that alphanumeric random sources be avoided due to the much greater difficulty in canonicalizing them in an independently repeatable fashion; however, if you choose to ignore this advice and use an ASCII or similar Roman alphabet source or sources, all white space, punctuation, accents, 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 "./". If you choose to not just ignore but flagrantly flout this advice and try to use even more complex and harder to canonicalize internationalized text, such as UNICODE, you are on your own.
英数字の無作為のソースが独自に反復可能なファッションで彼らをcanonicalizingすることにおけるはるかに大きい苦労のため避けられるのは、STRONGLYお勧めです。 しかしながら、あなたがこのアドバイスを無視して、ASCII、同様のローマ字ソースまたはソースを使用するのを選ぶなら、すべての余白、句読、アクセント、および特殊文字は移されるべきでした、そして、すべての手紙が大文字にセットしました。 「これは、a」 /で上にA-Zとaが数をcanonicalizedしたとき扱うことができるケタ0-9に手紙の壊れていない系列だけを残して、suffixedするつもりでした。」 無視しますが、ただ非道にこのアドバイスを侮辱して、さらに使用しようとしないのを選ぶなら、複雑であって、ユニコードなどの国際化しているテキストをよりcanonicalizeしにくくて、あなたは一人でいます。
Eastlake 3rd Informational [Page 6] RFC 3797 Verifiable Random Selection June 2004
証明可能な[6ページ]RFC3797ランダム・セレクション2004年6月の3番目に情報のイーストレーク
5. Handling Real World Problems
5. 本当の世界問題を扱います。
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.
本当の世界では、問題が上の4を通してセクション2に概説された方法と流れに従う際に起こることができます。 実際に起こったいくつかの問題が以下でそれらを扱うための推薦で説明されます。
5.1. Uncertainty as to the Pool
5.1. プールに関する不確実性
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 the algorithm and random input but it has been determined they are ineligible, they can 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 U selections where there are U uncertain pool members.
発行のINCLUDEは適任が不確実であるすべてのそれらをプールします、そして、これを扱う最も良い方法が発表されたスケジュールを維持することであり、発行されたプールを保つのは、公表の後にIMMUTABLEに付番しながら、記載します。 プールの中のだれかが後でアルゴリズムと無作為の入力で選ばれますが、それがそれらが不適格である、それらをスキップできると決心しているか、そして、アルゴリズムは造に加えて追加選択を走らせます。 したがって、一般に、不確実性は最大U選択よりU不確実なプールメンバーがいるところで1つの選択に作用するだけではありません。
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 smells bad. 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.
動作の他の方針ははるかに悪いです。 公表がリストの長さを変えて、だれを完全に急いで移動させたかの後にプールにおけるエントリーの実際の挿入か削除が選択されます、ことによるとあらゆる選択を変えて。 プールの中への挿入は以下をどこに挿入するかに関する疑問を挙げます。 始め、終わり、アルファバット順で… 乱数が知られていた後に選択管理者によるどんなそのような選択も公正な選択の公共の検証可能性を破壊します。 乱数を知っている前にしても、公表の後のリストでそのようなdinkingであるのはただ悪臭を放ちます。 緩慢のために発行された締め切りで自動的に彼らの挑戦を否定したべきであった後に晴れている固定公共の締め切りとプールの彼らの不在に挑戦するだれかがいるべきです。
5.2. Randomness Ambiguities
5.2. 偶発性のあいまいさ
The best good faith efforts have been made to specify precise and unambiguous sources of randomness. These sources have been 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
偶発性の正確で明白な源を指定するのを最も良い誠実の努力をしました。 これらのソースはあらかじめ公表されました、そして、彼らへの異論がありませんでした。 しかしながら、時間が実際にこの偶発性を得て、使用するようになるとき、本当の世界がカーブボールを投げて、どんなデータを使用したらよいかが全く明確であるというわけではないことは起こりました。 生じられて、問題は特にそうしました。
Eastlake 3rd Informational [Page 7] RFC 3797 Verifiable Random Selection June 2004
証明可能な[7ページ]RFC3797ランダム・セレクション2004年6月の3番目に情報のイーストレーク
connection with stock prices, volumes, and 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 could 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 extremely 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
6. 完全に扱われた例
Assume the following ordered list of 25 eligible volunteers is published in advance of selection:
25人の適任のボランティアの以下の規則正しいリストが選択の前に発表されると仮定してください:
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
1. ジョン11。 楽天家21。 2を自慢してください。 メアリ12。 首領22。 怠惰3。 内気な13。 パンドラ23。 4をねたんでください。 麻酔にかかっている14。 信頼24。 5を怒らせてください。 眠い15。 望み25。 Kasczynski6。 不機嫌な16。 チャリティー7。 Doc17。 リー8。 Sneazy18。 辛抱強い9。 素敵な19。 貞操10。 カッサンドラ20。 スミス
Assume the following (fake example) ordered list of randomness
sources:
1. The Kingdom of Alphaland State Lottery daily number for 1 November
2004 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 2004 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 2004.
↓これが偶発性ソースのリストが注文された(にせの例)であると仮定してください: 1. 2004年11月1日のAlphalandの州のLotteryの毎日の番号のKingdomはただ一つの4ケタ整数として扱いました。 2. すべてをどの少なくとも2つのレースのときに2004年10月13日か2004年10月13日以降初日のために競走をするかので、Hialeiaの勝馬の数は走ります。 3. Peopleの2004年11月1日のBetastani州Lottery six当選番号(7番目の「余分な」数を無視する)の民主共和国。
Hypothetical randomness publicly produced:
Source 1: 9319
Source 2: 2, 5, 12, 8, 10
Source 3: 9, 18, 26, 34, 41, 45
仮定している偶発性は公的に生産されました: ソース1: 9319ソース2: 2、5、12、8、10ソース3: 9, 18, 26, 34, 41, 45
Eastlake 3rd Informational [Page 8] RFC 3797 Verifiable Random Selection June 2004
証明可能な[8ページ]RFC3797ランダム・セレクション2004年6月の3番目に情報のイーストレーク
Resulting key string:
結果として起こる主要なストリング:
9319./2.5.8.10.12./9.18.26.34.41.45./
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 two byte string that is successively 0x0000, 0x0001, 0x0002, through 0x0010 (16 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.
以下のテーブルは相次ぐ2バイトのひもで腕木を付けられた上の主要なストリングのMD5の十六進法を与えます。0×0000 0×0001、0×0010を通した0×0002(16小数)。 各段階の残っているプールのサイズが与えられている数のための除数とプールの中のそれらの元の数に従って応召兵のインデックス。
index hex value of MD5 div selected
1 990DD0A5692A029A98B5E01AA28F3459 25 -> 17 <-
2 3691E55CB63FCC37914430B2F70B5EC6 24 -> 7 <-
3 FE814EDF564C190AC1D25753979990FA 23 -> 2 <-
4 1863CCACEB568C31D7DDBDF1D4E91387 22 -> 16 <-
5 F4AB33DF4889F0AF29C513905BE1D758 21 -> 25 <-
6 13EAEB529F61ACFB9A29D0BA3A60DE4A 20 -> 23 <-
7 992DB77C382CA2BDB9727001F3CDCCD9 19 -> 8 <-
8 63AB4258ECA922976811C7F55C383CE7 18 -> 24 <-
9 DFBC5AC97CED01B3A6E348E3CC63F40D 17 -> 19 <-
10 31CB111C4A4EBE9287CEAE16FE51B909 16 -> 13 <-
11 07FA46C122F164C215BBC72793B189A3 15 -> 22 <-
12 AC52F8D75CCBE2E61AFEB3387637D501 14 -> 5 <-
13 53306F73E14FC0B2FBF434218D25948E 13 -> 18 <-
14 B5D1403501A81F9A47318BE7893B347C 12 -> 9 <-
15 85B10B356AA06663EF1B1B407765100A 11 -> 1 <-
16 3269E6CE559ABD57E2BA6AAB495EB9BD 10 -> 4 <-
MD5 divのインデックス十六進法価値は1 990DD0A5692A029A98B5E01AA28F3459 25->17<2 3691 55CB63FCC37914430B2F70B5EC6 24->7Eの<3FE814EDF564C190AC1D25753979990FA23->2<4 1863CCACEB568C31D7DDBDF1D4E91387 22->16<5F4AB33DF4889F0AF29C513905BE1D758 21->25<6 13EAEB529F61ACFB9A29D0BA3A60DE4A20->23<7 992DB77C382CA2BDB9727001F3CDCCD9 19->8<8 63AB4258ECA922976811C7F55C383CE7 18->を選択しました; 24 <9DFBC5AC97CED01B3A6E348E3CC63F40D17->19<10 31CB111C4A4EBE9287CEAE16FE51B909 16->13<11 07FA46C122F164C215BBC72793B189A3 15->22<12AC52F8D75CCBE2E61AFEB3387637D501 14->5<13 53306F73E14FC0B2FBF434218D25948E13->18<14B5D1403501A81F9A47318BE7893B347C12->9<15 85B10B356AA06663EF1B1B407765100A11->1<16 3269Eの6CE559ABD57E2BA6AAB495EB9BD10->4<。
Resulting first ten selected, in order selected:
結果として起こる最初の10は選択されたオーダーで選択しました:
1. Lee (17) 6. Envy (23)
2. Doc (7) 7. Sneazy (8)
3. Mary (2) 8. Anger (24)
4. Charity (16) 9. Chastity (19)
5. Kasczynski (25) 10. Pandora (13)
1. リー(17)6。 (23)2をねたんでください。 Doc(7)7。 Sneazy(8)3。 メアリ(2)8。 (24)4を怒らせてください。 チャリティー(16)9。 貞操(19)5。 Kasczynski(25)10。 パンドラ(13)
Should one of the above turn out to be ineligible or decline to serve, the next would be Sloth, number 22.
不適格であるか、または不適格であることを断ろうとしている上の回転の1つが役立つなら、次のことはSlothでしょう、No.22。
7. Security Considerations
7. セキュリティ問題
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.
慎重な選択、それらが管理者のコントロールの下にあるというどんな妥当な容疑もないように、偶発性入力で作られているべきです。 最終からかなりの量のエントロピーがある少ない数の入力を使用するために上に与えられたガイドラインは従われるべきです。 そして、選択されたアルゴリズムが指定された入力値で忠実に実行されるなら、等しい注意は、必要があります。
Eastlake 3rd Informational [Page 9] RFC 3797 Verifiable Random Selection June 2004
証明可能な[9ページ]RFC3797ランダム・セレクション2004年6月の3番目に情報のイーストレーク
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.
結果と計算をコピーするために興味がある共同体への窓が実現のいじることに対して手頃な保証を与えるはずであるおよそ1週間の公表。
8. Reference Code
8. 参照コード
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.
This code has been extracted from this document, compiled, and
tested. While no flaws have been found, it is possible that when
used with some compiler on some system some flaw will manifest
itself.
このコードは[RFC1321]からのMD5参照コード(「RSA Data Security Inc.MD5メッセージダイジェストアルゴリズム」)を利用します。 複数の浮動小数点に対処するコードの部分はマット・クロフォードによって書かれました。 RFC2777の元のコードは、最大255人のメンバーのプールを扱うことができただけであって、エリックNordmarkによって16-1に2**に広げられました。 このコードは、このドキュメントから抜粋されて、コンパイルされて、テストされました。 欠点は全く見つけられていませんが、或るものが失敗させる何らかのシステムの上の何らかのコンパイラと共に使用されるとそれが現れるのは、可能です。
/****************************************************************
*
* Reference code for
* "Publicly Verifiable Random Selection"
* Donald E. Eastlake 3rd
* February 2004
*
****************************************************************/
#include <limits.h>
#include <math.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
/**************************************************************** * * Reference code for * "Publicly Verifiable Random Selection" * Donald E. Eastlake 3rd * February 2004 * ****************************************************************/ #include <limits.h> #include <math.h> #include <stdio.h> #include <stdlib.h> #include <string.h>
/* From RFC 1321 */
#include "global.h"
#include "MD5.h"
RFC1321*/#、からの/*は#、が含む"global.h""MD5.h"を含んでいます。
/* local prototypes */
int longremainder ( unsigned short divisor,
unsigned char dividend[16] );
long int getinteger ( char *string );
double NPentropy ( int N, int P );
/*ローカル原型*/int longremainder、(無記名の短い除数、無記名の炭の配当[16] )。 長いint getinteger(炭*ストリング)。 NPentropy(int N、int P)を倍にしてください。
/* 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, selection, usel;
main () { int i, j, k, k2, err, keysize, selection, usel;
Eastlake 3rd Informational [Page 10] RFC 3797 Verifiable Random Selection June 2004
Eastlake 3rd Informational [Page 10] RFC 3797 Verifiable Random Selection June 2004
unsigned short remaining, *selected;
long int pool, temp, array[16];
MD5_CTX ctx;
char buffer[257], key [800], sarray[16][256];
unsigned char uc16[16], unch1, unch2;
unsigned short remaining, *selected; long int pool, temp, array[16]; MD5_CTX ctx; char buffer[257], key [800], sarray[16][256]; unsigned char uc16[16], unch1, unch2;
pool = getinteger ( "Type size of pool:\n" );
if ( pool > 65535 )
pool = getinteger ( "Type size of pool:\n" ); if ( pool > 65535 )
{
printf ( "Pool too big.\n" );
exit ( 1 );
}
selected = (unsigned short *) malloc ( (size_t)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 );
{ printf ( "Pool too big.\n" ); exit ( 1 ); } selected = (unsigned short *) malloc ( (size_t)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 );
Eastlake 3rd Informational [Page 11] RFC 3797 Verifiable Random Selection June 2004
Eastlake 3rd Informational [Page 11] RFC 3797 Verifiable Random Selection June 2004
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;
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] = '%%BODY%%';
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] )
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] = '%%BODY%%'; 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] )
Eastlake 3rd Informational [Page 12] RFC 3797 Verifiable Random Selection June 2004
Eastlake 3rd Informational [Page 12] RFC 3797 Verifiable Random Selection June 2004
{
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 */
{ 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] = (unsigned short)(i + 1);
printf ( "index hex value of MD5 div selected\n" );
for ( usel = 0, remaining = (unsigned short)pool;
usel < selection;
++usel, --remaining )
{
unch1 = (unsigned char)usel;
unch2 = (unsigned char)(usel>>8);
/* prefix/suffix extended to 2 bytes by Donald Eastlake */
MD5Init ( &ctx );
MD5Update ( &ctx, &unch2, 1 );
MD5Update ( &ctx, &unch1, 1 );
MD5Update ( &ctx, (unsigned char *)key, keysize );
MD5Update ( &ctx, &unch2, 1 );
MD5Update ( &ctx, &unch1, 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",
usel+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;
/* 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] = (unsigned short)(i + 1); printf ( "index hex value of MD5 div selected\n" ); for ( usel = 0, remaining = (unsigned short)pool; usel < selection; ++usel, --remaining ) { unch1 = (unsigned char)usel; unch2 = (unsigned char)(usel>>8); /* prefix/suffix extended to 2 bytes by Donald Eastlake */ MD5Init ( &ctx ); MD5Update ( &ctx, &unch2, 1 ); MD5Update ( &ctx, &unch1, 1 ); MD5Update ( &ctx, (unsigned char *)key, keysize ); MD5Update ( &ctx, &unch2, 1 ); MD5Update ( &ctx, &unch1, 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", usel+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;
Eastlake 3rd Informational [Page 13] RFC 3797 Verifiable Random Selection June 2004
Eastlake 3rd Informational [Page 13] RFC 3797 Verifiable Random Selection June 2004
break;
}
}
printf ( "\nDone, type any character to exit.\n" );
getchar ();
return 0;
}
break; } } printf ( "\nDone, type any character to exit.\n" ); getchar (); return 0; }
/* prompt for a positive non-zero integer input */
/****************************************************************/
long int getinteger ( char *string )
{
long int i;
int j;
char tin[257];
/* prompt for a positive non-zero integer input */ /****************************************************************/ long int getinteger ( char *string ) { long int i; int j; char tin[257];
while ( 1 )
{
printf ( string );
printf ( "(or 'exit' to exit) " );
gets ( tin );
j = sscanf ( tin, "%ld", &i );
if ( ( j == EOF )
while ( 1 ) { printf ( string ); printf ( "(or 'exit' to exit) " ); gets ( tin ); j = sscanf ( tin, "%ld", &i ); if ( ( j == EOF )
|| ( !j && ( ( tin[0] == 'e' ) || ( tin[0] == 'E' ) ) )
)
exit ( j );
if ( ( j == 1 ) &&
( i > 0 ) )
return i;
} /* end while */
}
|| ( !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;
/* 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;
if ( !divisor ) return -1; for ( i = 0, kruft = 0; i < 16; ++i ) { kruft = ( kruft << 8 ) + dividend[i]; kruft %= divisor;
Eastlake 3rd Informational [Page 14] RFC 3797 Verifiable Random Selection June 2004
Eastlake 3rd Informational [Page 14] RFC 3797 Verifiable Random Selection June 2004
}
return kruft;
} /* end longremainder */
} return kruft; } /* end longremainder */
/* calculate how many bits of entropy it takes to select N from P */
/****************************************************************/
/* P!
log ( ----------------- )
2 N! * ( P - N )!
*/
/* 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;
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;
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 */
return result; } /* end NPentropy */
Eastlake 3rd Informational [Page 15] RFC 3797 Verifiable Random Selection June 2004
Eastlake 3rd Informational [Page 15] RFC 3797 Verifiable Random Selection June 2004
Appendix A: History of NomCom Member Selection
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:
For reference purposes, here is a list of the IETF Nominations Committee member selection techniques and chairs so far:
YEAR CHAIR SELECTION METHOD
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
2003/2004 Rich Draves RFC 2777
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 2003/2004 Rich Draves RFC 2777
Clergy = Names were written on pieces of paper, placed in a receptacle, and a member of the clergy picked the NomCom members.
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.
Spouse = Same as Clergy except chair's spouse made the selection.
Algorithm = Algorithmic selection based on similar concepts to those documented in RFC 2777 and herein.
Algorithm = Algorithmic selection based on similar concepts to those documented in RFC 2777 and herein.
RFC 2777 = Algorithmic selection using the algorithm and reference code provided in RFC 2777 (but not the fake example sources of randomness).
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
Appendix B: Changes from RFC 2777
This document differs from [RFC 2777], the previous version, in three primary ways as follows:
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.
(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 code has been modified to handle pools of
up to 2**16-1 elements and the counter based prefix and suffix
concatenated with the key string before hashing has been extended
to two bytes.
(2) The selection algorithm code has been modified to handle pools of up to 2**16-1 elements and the counter based prefix and suffix concatenated with the key string before hashing has been extended to two bytes.
(3) Mention has been added that the algorithm documented herein was
used by IANA to select the Internationalized Domain Name ACE
prefix and some minor wording changes made.
(3) Mention has been added that the algorithm documented herein was used by IANA to select the Internationalized Domain Name ACE prefix and some minor wording changes made.
Eastlake 3rd Informational [Page 16] RFC 3797 Verifiable Random Selection June 2004
Eastlake 3rd Informational [Page 16] RFC 3797 Verifiable Random Selection June 2004
(4) References have been divided into Informative and Normative.
(4) References have been divided into Informative and Normative.
(5) The list in Appendix A has been brought up to date.
(5) The list in Appendix A has been brought up to date.
Acknowledgements
Acknowledgements
Matt Crawford and Erik Nordmark made major contributions to this document. Comments by Bernard Aboba, Theodore Ts'o, Jim Galvin, Steve Bellovin, and others have been incorporated.
Matt Crawford and Erik Nordmark made major contributions to this document. Comments by Bernard Aboba, Theodore Ts'o, Jim Galvin, Steve Bellovin, and others have been incorporated.
References
References
Normative References
Normative References
[ASCII] "USA Standard Code for Information Interchange", X3.4,
American National Standards Institute: New York, 1968.
[ASCII] "USA Standard Code for Information Interchange", X3.4, American National Standards Institute: New York, 1968.
[RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC 1750] Eastlake, 3rd, D., Crocker, S. and J. Schiller,
"Randomness Recommendations for Security", RFC 1750,
December 1994.
[RFC 1750] Eastlake, 3rd, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC 3174] Eastlake, 3rd, D. and P. Jones, "US Secure Hash Algorithm
1 (SHA1)", RFC 3174, September 2001.
[RFC 3174] Eastlake, 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
Informative References
Informative References
[RFC 3777] Galvin, J., "IAB and IESG Selection, Confirmation, and
Recall Process: Operation of the Nominating and Recall
Committees", BCP 10, RFC 3777, April 2004.
[RFC 3777] Galvin, J., "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees", BCP 10, RFC 3777, April 2004.
[RFC 2777] Eastlake, 3rd, D., "Publicly Verifiable Nomcom Random
Selection", RFC 2777, February 2000.
[RFC 2777] Eastlake, 3rd, D., "Publicly Verifiable Nomcom Random Selection", RFC 2777, February 2000.
[RFC 3490] Falstrom, P., Hoffman, P. and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003.
[RFC 3490] Falstrom, P., Hoffman, P. and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
Eastlake 3rd Informational [Page 17] RFC 3797 Verifiable Random Selection June 2004
Eastlake 3rd Informational [Page 17] RFC 3797 Verifiable Random Selection June 2004
Author's Address
Author's Address
Donald E. Eastlake, 3rd Motorola Laboratories 155 Beaver Street Milford, MA 01757 USA
Donald E. Eastlake, 3rd Motorola Laboratories 155 Beaver Street Milford, MA 01757 USA
Phone: +1-508-786-7554(w)
+1-508-634-2066(h)
EMail: Donald.Eastlake@motorola.com
Phone: +1-508-786-7554(w) +1-508-634-2066(h) EMail: Donald.Eastlake@motorola.com
Eastlake 3rd Informational [Page 18] RFC 3797 Verifiable Random Selection June 2004
Eastlake 3rd Informational [Page 18] RFC 3797 Verifiable Random Selection June 2004
Full Copyright Statement
Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
Intellectual Property
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
Acknowledgement
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.
Funding for the RFC Editor function is currently provided by the Internet Society.
Eastlake 3rd Informational [Page 19]
Eastlake 3rd Informational [Page 19]
一覧
スポンサーリンク
