| < draft-eastlake-randomness2-08.txt | draft-eastlake-randomness2-09.txt > | |||
|---|---|---|---|---|
| Network Working Group Donald E. Eastlake, 3rd | Network Working Group Donald E. Eastlake, 3rd | |||
| OBSOLETES RFC 1750 Jeffrey I. Schiller | OBSOLETES RFC 1750 Jeffrey I. Schiller | |||
| Steve Crocker | Steve Crocker | |||
| Expires February 2005 August 2004 | Expires April 2005 October 2004 | |||
| Randomness Requirements for Security | Randomness Requirements for Security | |||
| ---------- ------------ --- -------- | ---------- ------------ --- -------- | |||
| <draft-eastlake-randomness2-08.txt> | <draft-eastlake-randomness2-09.txt> | |||
| Status of This Document | Status of This Document | |||
| By submitting this Internet-Draft, I certify that any applicable | By submitting this Internet-Draft, I certify that any applicable | |||
| patent or other IPR claims of which I am aware have been disclosed, | patent or other IPR claims of which I am aware have been disclosed, | |||
| or will be disclosed, and any of which I become aware will be | or will be disclosed, and any of which I become aware will be | |||
| disclosed, in accordance with RFC 3668. | disclosed, in accordance with RFC 3668. | |||
| This document is intended to become a Best Current Practice. | This document is intended to become a Best Current Practice. | |||
| Comments should be sent to the authors. Distribution is unlimited. | Comments should be sent to the authors. Distribution is unlimited. | |||
| This document is an Internet-Draft and is in full conformance with | Internet-Drafts are working documents of the Internet Engineering | |||
| all provisions of Section 10 of RFC 2026. Internet-Drafts are | Task Force (IETF), its areas, and its working groups. Note that | |||
| working documents of the Internet Engineering Task Force (IETF), its | other groups may also distribute working documents as Internet- | |||
| areas, and its working groups. Note that other groups may also | Drafts. | |||
| distribute working documents as Internet-Drafts. | ||||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." The list | material or to cite them other than a "work in progress." | |||
| of current Internet-Drafts can be accessed at | ||||
| http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft | The list of current Internet-Drafts can be accessed at | |||
| Shadow Directories can be accessed at | http://www.ietf.org/1id-abstracts.html | |||
| http://www.ietf.org/shadow.html. | ||||
| The list of Internet-Draft Shadow Directories can be accessed at | ||||
| http://www.ietf.org/shadow.html | ||||
| Copyright (C) The Internet Society 2004. All Rights Reserved. | ||||
| Abstract | Abstract | |||
| Security systems are built on strong cryptographic algorithms that | Security systems are built on strong cryptographic algorithms that | |||
| foil pattern analysis attempts. However, the security of these | foil pattern analysis attempts. However, the security of these | |||
| systems is dependent on generating secret quantities for passwords, | systems is dependent on generating secret quantities for passwords, | |||
| cryptographic keys, and similar quantities. The use of pseudo-random | cryptographic keys, and similar quantities. The use of pseudo-random | |||
| processes to generate secret quantities can result in pseudo- | processes to generate secret quantities can result in pseudo- | |||
| security. The sophisticated attacker of these security systems may | security. The sophisticated attacker of these security systems may | |||
| find it easier to reproduce the environment that produced the secret | find it easier to reproduce the environment that produced the secret | |||
| skipping to change at page 3, line 7 ¶ | skipping to change at page 2, line 15 ¶ | |||
| pitfalls in using traditional pseudo-random number generation | pitfalls in using traditional pseudo-random number generation | |||
| techniques for choosing such quantities. It recommends the use of | techniques for choosing such quantities. It recommends the use of | |||
| truly random hardware techniques and shows that the existing hardware | truly random hardware techniques and shows that the existing hardware | |||
| on many systems can be used for this purpose. It provides suggestions | on many systems can be used for this purpose. It provides suggestions | |||
| to ameliorate the problem when a hardware solution is not available. | to ameliorate the problem when a hardware solution is not available. | |||
| And it gives examples of how large such quantities need to be for | And it gives examples of how large such quantities need to be for | |||
| some applications. | some applications. | |||
| Acknowledgements | Acknowledgements | |||
| Special thanks to Peter Gutmann, who has permitted the incorporation | Special thanks to Paul Hoffman and John Kelsey for their extensive | |||
| of material from his paper "Software Generation of Practically Strong | comments and to Peter Gutmann, who has permitted the incorporation of | |||
| Random Numbers", and to Paul Hoffman for his extensive comments. | material from his paper "Software Generation of Practically Strong | |||
| Random Numbers". | ||||
| The following other persons (in alphabetic order) have also | The following other persons (in alphabetic order) have also | |||
| contributed substantially to this document: | contributed substantially to this document: | |||
| Tony Hansen, Sandy Harris, Russ Housley | Daniel Brown, Don Davis, Peter Gutmann, Tony Hansen, Sandy | |||
| Harris, Paul Hoffman, Scott Hollenback, Russ Housley, Christian | ||||
| Huitema, John Kelsey, and Damir Rajnovic. | ||||
| The following persons (in alphabetic order) contributed to RFC 1750, | The following persons (in alphabetic order) contributed to RFC 1750, | |||
| the predecessor of this document: | the predecessor of this document: | |||
| David M. Balenson, Don T. Davis, Carl Ellison, Marc Horowitz, | David M. Balenson, Don T. Davis, Carl Ellison, Marc Horowitz, | |||
| Christian Huitema, Charlie Kaufman, Steve Kent, Hal Murray, Neil | Christian Huitema, Charlie Kaufman, Steve Kent, Hal Murray, Neil | |||
| Haller, Richard Pitkin, Tim Redmond, and Doug Tygar. | Haller, Richard Pitkin, Tim Redmond, and Doug Tygar. | |||
| Table of Contents | Table of Contents | |||
| Status of This Document....................................1 | Status of This Document....................................1 | |||
| Abstract...................................................1 | Abstract...................................................1 | |||
| Acknowledgements...........................................2 | ||||
| Acknowledgements...........................................3 | Table of Contents..........................................3 | |||
| Table of Contents..........................................4 | ||||
| 1. Introduction............................................6 | 1. Introduction............................................5 | |||
| 2. General Requirements....................................7 | 2. General Requirements....................................6 | |||
| 3. Traditional Pseudo-Random Sequences.....................9 | 3. Traditional Pseudo-Random Sequences.....................9 | |||
| 4. Unpredictability.......................................11 | 4. Unpredictability.......................................11 | |||
| 4.1 Problems with Clocks and Serial Numbers...............11 | 4.1 Problems with Clocks and Serial Numbers...............11 | |||
| 4.2 Timing and Content of External Events.................12 | 4.2 Timing and Value of External Events...................12 | |||
| 4.3 The Fallacy of Complex Manipulation...................12 | 4.3 The Fallacy of Complex Manipulation...................12 | |||
| 4.4 The Fallacy of Selection from a Large Database........13 | 4.4 The Fallacy of Selection from a Large Database........13 | |||
| 5. Hardware for Randomness................................14 | 5. Hardware for Randomness................................15 | |||
| 5.1 Volume Required.......................................14 | 5.1 Volume Required.......................................15 | |||
| 5.2 Sensitivity to Skew...................................14 | 5.2 Sensitivity to Skew...................................15 | |||
| 5.2.1 Using Stream Parity to De-Skew......................15 | 5.2.1 Using Stream Parity to De-Skew......................16 | |||
| 5.2.2 Using Transition Mappings to De-Skew................16 | 5.2.2 Using Transition Mappings to De-Skew................17 | |||
| 5.2.3 Using FFT to De-Skew................................17 | 5.2.3 Using FFT to De-Skew................................18 | |||
| 5.2.4 Using Compression to De-Skew........................17 | 5.2.4 Using Compression to De-Skew........................18 | |||
| 5.3 Existing Hardware Can Be Used For Randomness..........18 | 5.3 Existing Hardware Can Be Used For Randomness..........19 | |||
| 5.3.1 Using Existing Sound/Video Input....................18 | 5.3.1 Using Existing Sound/Video Input....................19 | |||
| 5.3.2 Using Existing Disk Drives..........................18 | 5.3.2 Using Existing Disk Drives..........................19 | |||
| 5.4 Ring Oscillator Sources...............................19 | 5.4 Ring Oscillator Sources...............................20 | |||
| 6. Recommended Software Strategy..........................21 | 6. Recommended Software Strategy..........................22 | |||
| 6.1 Mixing Functions......................................21 | 6.1 Mixing Functions......................................22 | |||
| 6.1.1 A Trivial Mixing Function...........................21 | 6.1.1 A Trivial Mixing Function...........................22 | |||
| 6.1.2 Stronger Mixing Functions...........................22 | 6.1.2 Stronger Mixing Functions...........................23 | |||
| 6.1.3 Using S-Boxes for Mixing............................24 | 6.1.3 Using S-Boxes for Mixing............................25 | |||
| 6.1.4 Diffie-Hellman as a Mixing Function.................24 | 6.1.4 Diffie-Hellman as a Mixing Function.................25 | |||
| 6.1.5 Using a Mixing Function to Stretch Random Bits......24 | 6.1.5 Using a Mixing Function to Stretch Random Bits......25 | |||
| 6.1.6 Other Factors in Choosing a Mixing Function.........25 | 6.1.6 Other Factors in Choosing a Mixing Function.........26 | |||
| 6.2 Non-Hardware Sources of Randomness....................26 | 6.2 Non-Hardware Sources of Randomness....................27 | |||
| 6.3 Cryptographically Strong Sequences....................27 | 6.3 Cryptographically Strong Sequences....................28 | |||
| 6.3.1 Traditional Strong Sequences........................27 | 6.3.1 OFB and CTR Sequences...............................28 | |||
| 6.3.2 The Blum Blum Shub Sequence Generator...............28 | 6.3.2 The Blum Blum Shub Sequence Generator...............29 | |||
| 6.3.3 Entropy Pool Techniques.............................29 | 6.3.3 Entropy Pool Techniques.............................30 | |||
| 7. Key Generation Standards and Examples..................31 | 7. Key Generation Examples and Standards..................32 | |||
| 7.1 US DoD Recommendations for Password Generation........31 | 7.1 US DoD Recommendations for Password Generation........32 | |||
| 7.2 X9.17 Key Generation..................................31 | 7.2 X9.17 Key Generation..................................32 | |||
| 7.3 DSS Pseudo-Random Number Generation...................32 | 7.3 DSS Pseudo-Random Number Generation...................33 | |||
| 7.4 X9.82 Pseudo-Random Number Generation.................33 | 7.4 X9.82 Pseudo-Random Number Generation.................34 | |||
| 7.5 The /dev/random Device................................33 | 7.5 The /dev/random Device................................34 | |||
| 7.6 Windows CryptGenRandom................................36 | ||||
| 8. Examples of Randomness Required........................35 | 8. Examples of Randomness Required........................37 | |||
| 8.1 Password Generation..................................35 | 8.1 Password Generation..................................37 | |||
| 8.2 A Very High Security Cryptographic Key................36 | 8.2 A Very High Security Cryptographic Key................38 | |||
| 8.2.1 Effort per Key Trial................................36 | 8.2.1 Effort per Key Trial................................38 | |||
| 8.2.2 Meet in the Middle Attacks..........................37 | 8.2.2 Meet in the Middle Attacks..........................39 | |||
| 8.2.3 Other Considerations................................38 | 8.2.3 Other Considerations................................40 | |||
| 9. Conclusion.............................................39 | 9. Conclusion.............................................41 | |||
| 10. Security Considerations...............................40 | 10. Security Considerations...............................42 | |||
| 11. Copyright and Disclaimer..............................40 | 11. Copyright and Disclaimer..............................42 | |||
| 12. Appendix A: Changes from RFC 1750.....................41 | 12. Appendix A: Changes from RFC 1750.....................43 | |||
| 14. Informative References................................42 | 14. Informative References................................44 | |||
| Authors Addresses.........................................46 | Author's Addresses........................................48 | |||
| File Name and Expiration..................................46 | File Name and Expiration..................................48 | |||
| 1. Introduction | 1. Introduction | |||
| Software cryptography is coming into wider use and is continuing to | Software cryptography is coming into wider use and is continuing to | |||
| spread, although there is a long way to go until it becomes | spread, although there is a long way to go until it becomes | |||
| pervasive. | pervasive. | |||
| Systems like SSH, IPSEC, TLS, S/MIME, PGP, DNSSEC, Kerberos, etc. are | Systems like SSH, IPSEC, TLS, S/MIME, PGP, DNSSEC, Kerberos, etc. are | |||
| maturing and becoming a part of the network landscape [SSH, IPSEC, | maturing and becoming a part of the network landscape [SSH, IPSEC, | |||
| MAIL*, TLS, DNSSEC]. By comparison, when the previous version of this | MAIL*, TLS, DNSSEC]. By comparison, when the previous version of this | |||
| document [RFC 1750] was issued in 1994, about the only Internet | document [RFC 1750] was issued in 1994, about the only Internet | |||
| cryptographic security specification in the IETF was the Privacy | cryptographic security specification in the IETF was the Privacy | |||
| Enhanced Mail protocol [MAIL PEM]. | Enhanced Mail protocol [MAIL PEM *]. | |||
| These systems provide substantial protection against snooping and | These systems provide substantial protection against snooping and | |||
| spoofing. However, there is a potential flaw. At the heart of all | spoofing. However, there is a potential flaw. At the heart of all | |||
| cryptographic systems is the generation of secret, unguessable (i.e., | cryptographic systems is the generation of secret, unguessable (i.e., | |||
| random) numbers. | random) numbers. | |||
| The lack of generally available facilities for generating such | The lack of generally available facilities for generating such random | |||
| unpredictable numbers is an open wound in the design of cryptographic | numbers, that is the lack of general availability of truly | |||
| software. For the software developer who wants to build a key or | unpredictable sources, forms an open wound in the design of | |||
| password generation procedure that runs on a wide range of hardware, | cryptographic software. For the software developer who wants to build | |||
| the only safe strategy so far has been to force the local | a key or password generation procedure that runs on a wide range of | |||
| installation to supply a suitable routine to generate random numbers. | hardware, this is a very real problem. | |||
| This is an awkward, error-prone and unpalatable solution. | ||||
| It is important to keep in mind that the requirement is for data that | It is important to keep in mind that the requirement is for data that | |||
| an adversary has a very low probability of guessing or determining. | an adversary has a very low probability of guessing or determining. | |||
| This can easily fail if pseudo-random data is used which only meets | This can easily fail if pseudo-random data is used which only meets | |||
| traditional statistical tests for randomness or which is based on | traditional statistical tests for randomness or which is based on | |||
| limited range sources, such as clocks. Frequently such random | limited range sources, such as clocks. Sometimes such pseudo-random | |||
| quantities are determinable by an adversary searching through an | quantities are determinable by an adversary searching through an | |||
| embarrassingly small space of possibilities. | embarrassingly small space of possibilities. | |||
| This Best Current Practice describes techniques for producing random | This Best Current Practice describes techniques for producing random | |||
| quantities that will be resistant to such attack. It recommends that | quantities that will be resistant to such attack. It recommends that | |||
| future systems include hardware random number generation or provide | future systems include hardware random number generation or provide | |||
| access to existing hardware that can be used for this purpose. It | access to existing hardware that can be used for this purpose. It | |||
| suggests methods for use if such hardware is not available. And it | suggests methods for use if such hardware is not available. And it | |||
| gives some estimates of the number of random bits required for sample | gives some estimates of the number of random bits required for sample | |||
| applications. | applications. | |||
| skipping to change at page 7, line 22 ¶ | skipping to change at page 6, line 22 ¶ | |||
| strings or phrases composed on ordinary words. But this only affects | strings or phrases composed on ordinary words. But this only affects | |||
| the format of the password information, not the requirement that the | the format of the password information, not the requirement that the | |||
| password be very hard to guess.) | password be very hard to guess.) | |||
| Many other requirements come from the cryptographic arena. | Many other requirements come from the cryptographic arena. | |||
| Cryptographic techniques can be used to provide a variety of services | Cryptographic techniques can be used to provide a variety of services | |||
| including confidentiality and authentication. Such services are based | including confidentiality and authentication. Such services are based | |||
| on quantities, traditionally called "keys", that are unknown to and | on quantities, traditionally called "keys", that are unknown to and | |||
| unguessable by an adversary. | unguessable by an adversary. | |||
| Generally speaking, the above two examples also illustrate two | ||||
| different types of random quantities that may be wanted. In the case | ||||
| of human usable passwords, the only important characteristic is that | ||||
| it be unguessable; it is not important that they may be composed of | ||||
| ASCII characters, for example, so the top bit of every byte is zero. | ||||
| On the other hand, for fixed length keys and the like, you normally | ||||
| quantities that are indistinguishable from truly random, that is, all | ||||
| bits will pass statistical randomness tests. | ||||
| In some cases, such as the use of symmetric encryption with the one | In some cases, such as the use of symmetric encryption with the one | |||
| time pads or an algorithm like the US Advanced Encryption Standard | time pads or an algorithm like the US Advanced Encryption Standard | |||
| [AES], the parties who wish to communicate confidentially and/or with | [AES], the parties who wish to communicate confidentially and/or with | |||
| authentication must all know the same secret key. In other cases, | authentication must all know the same secret key. In other cases, | |||
| using what are called asymmetric or "public key" cryptographic | using what are called asymmetric or "public key" cryptographic | |||
| techniques, keys come in pairs. One key of the pair is private and | techniques, keys come in pairs. One key of the pair is private and | |||
| must be kept secret by one party, the other is public and can be | must be kept secret by one party, the other is public and can be | |||
| published to the world. It is computationally infeasible to determine | published to the world. It is computationally infeasible to determine | |||
| the private key from the public key and knowledge of the public is of | the private key from the public key and knowledge of the public is of | |||
| no help to an adversary [ASYMMETRIC]. [SCHNEIER, FERGUSON, KAUFMAN] | no help to an adversary [ASYMMETRIC]. [SCHNEIER, FERGUSON, KAUFMAN] | |||
| skipping to change at page 9, line 5 ¶ | skipping to change at page 7, line 42 ¶ | |||
| more probable values first. | more probable values first. | |||
| For example, consider a cryptographic system that uses 128 bit keys. | For example, consider a cryptographic system that uses 128 bit keys. | |||
| If these 128 bit keys are derived by using a fixed pseudo-random | If these 128 bit keys are derived by using a fixed pseudo-random | |||
| number generator that is seeded with an 8 bit seed, then an adversary | number generator that is seeded with an 8 bit seed, then an adversary | |||
| needs to search through only 256 keys (by running the pseudo-random | needs to search through only 256 keys (by running the pseudo-random | |||
| number generator with every possible seed), not the 2^128 keys that | number generator with every possible seed), not the 2^128 keys that | |||
| may at first appear to be the case. Only 8 bits of "information" are | may at first appear to be the case. Only 8 bits of "information" are | |||
| in these 128 bit keys. | in these 128 bit keys. | |||
| While the above analysis is correct on average, it can be misleading | ||||
| in some cases for cryptographic analysis where what is really | ||||
| important is the work factor for an adversary. For example, assume | ||||
| that there was a pseudo-random number generator generating 128 bit | ||||
| keys, as in the previous paragraph, but that it generated 0 half of | ||||
| the time and a random selection from the remaining 2**128 - 1 values | ||||
| the rest of the time. The Shannon equation above says that there are | ||||
| 64 bits of information in one of these key values but an adversary, | ||||
| by simply trying the values 0, can break the security of half of the | ||||
| uses, albeit a random half. Thus for cryptographic purposes, it is | ||||
| also useful to look at other measures, such as min-entropy, defined | ||||
| as | ||||
| Min-entropy = - log ( maximum ( p ) ) | ||||
| i | ||||
| where i is as above. Using this equation, we get 1 bit of min- | ||||
| entropy for our new hypothetical distribution as opposed to 64 bits | ||||
| of classical Shannon entropy. | ||||
| A continuous spectrum of entropies, sometimes called Renyi entropy, | ||||
| have been defined, specified by a parameter r. When r = 1, it is | ||||
| Shannon entropy, and with r = infinity, it is min-entropy. When r = | ||||
| 0, it is just log (n) where n is the number of non-zero | ||||
| probabilities. Renyi entropy is a non-increasing function of r, so | ||||
| min-entropy is always the most conservative measure of entropy and | ||||
| usually the best to use for cryptographic evaluation. [LUBY] | ||||
| 3. Traditional Pseudo-Random Sequences | 3. Traditional Pseudo-Random Sequences | |||
| Most traditional sources of random numbers use deterministic sources | This section talks about traditional sources of deterministic of | |||
| of "pseudo-random" numbers. These typically start with a "seed" | "pseudo-random" numbers. These typically start with a "seed" quantity | |||
| quantity and use numeric or logical operations to produce a sequence | and use numeric or logical operations to produce a sequence of | |||
| of values. | values. Note that none of the techniques discussed in this section is | |||
| suitable for cryptographic use. They are presented for general | ||||
| information. | ||||
| [KNUTH] has a classic exposition on pseudo-random numbers. | [KNUTH] has a classic exposition on pseudo-random numbers. | |||
| Applications he mentions are simulation of natural phenomena, | Applications he mentions are simulation of natural phenomena, | |||
| sampling, numerical analysis, testing computer programs, decision | sampling, numerical analysis, testing computer programs, decision | |||
| making, and games. None of these have the same characteristics as the | making, and games. None of these have the same characteristics as the | |||
| sort of security uses we are talking about. Only in the last two | sort of security uses we are talking about. Only in the last two | |||
| could there be an adversary trying to find the random quantity. | could there be an adversary trying to find the random quantity. | |||
| However, in these cases, the adversary normally has only a single | However, in these cases, the adversary normally has only a single | |||
| chance to use a guessed value. In guessing passwords or attempting to | chance to use a guessed value. In guessing passwords or attempting to | |||
| break an encryption scheme, the adversary normally has many, perhaps | break an encryption scheme, the adversary normally has many, perhaps | |||
| skipping to change at page 11, line 15 ¶ | skipping to change at page 11, line 15 ¶ | |||
| 4. Unpredictability | 4. Unpredictability | |||
| Statistically tested randomness in the traditional sense described in | Statistically tested randomness in the traditional sense described in | |||
| section 3 is NOT the same as the unpredictability required for | section 3 is NOT the same as the unpredictability required for | |||
| security use. | security use. | |||
| For example, use of a widely available constant sequence, such as | For example, use of a widely available constant sequence, such as | |||
| that from the CRC tables, is very weak against an adversary. Once | that from the CRC tables, is very weak against an adversary. Once | |||
| they learn of or guess it, they can easily break all security, future | they learn of or guess it, they can easily break all security, future | |||
| and past, based on the sequence. [CRC] Yet the statistical properties | and past, based on the sequence. [CRC] Yet the statistical properties | |||
| of these tables are good. | of these tables are good. So you should keep in mind that passing | |||
| statistical tests doesn't tell you that something is unpredictable. | ||||
| The following sections describe the limitations of some randomness | The following sections describe the limitations of some randomness | |||
| generation techniques and sources. | generation techniques and sources. Much better sources are described | |||
| in Section 5. | ||||
| 4.1 Problems with Clocks and Serial Numbers | 4.1 Problems with Clocks and Serial Numbers | |||
| Computer clocks, or similar operating system or hardware values, | Computer clocks, or similar operating system or hardware values, | |||
| provide significantly fewer real bits of unpredictability than might | provide significantly fewer real bits of unpredictability than might | |||
| appear from their specifications. | appear from their specifications. | |||
| Tests have been done on clocks on numerous systems and it was found | Tests have been done on clocks on numerous systems and it was found | |||
| that their behavior can vary widely and in unexpected ways. One | that their behavior can vary widely and in unexpected ways. One | |||
| version of an operating system running on one set of hardware may | version of an operating system running on one set of hardware may | |||
| skipping to change at page 12, line 8 ¶ | skipping to change at page 12, line 10 ¶ | |||
| on approximate date of manufacture or other data. For example, it is | on approximate date of manufacture or other data. For example, it is | |||
| likely that a company that manufactures both computers and Ethernet | likely that a company that manufactures both computers and Ethernet | |||
| adapters will, at least internally, use its own adapters, which | adapters will, at least internally, use its own adapters, which | |||
| significantly limits the range of built-in addresses. | significantly limits the range of built-in addresses. | |||
| Problems such as those described above related to clocks and serial | Problems such as those described above related to clocks and serial | |||
| numbers make code to produce unpredictable quantities difficult if | numbers make code to produce unpredictable quantities difficult if | |||
| the code is to be ported across a variety of computer platforms and | the code is to be ported across a variety of computer platforms and | |||
| systems. | systems. | |||
| 4.2 Timing and Content of External Events | 4.2 Timing and Value of External Events | |||
| It is possible to measure the timing and content of mouse movement, | It is possible to measure the timing and content of mouse movement, | |||
| key strokes, and similar user events. This is a reasonable source of | key strokes, and similar user events. This is a reasonable source of | |||
| unguessable data with some qualifications. On some machines, inputs | unguessable data with some qualifications. On some machines, inputs | |||
| such as key strokes are buffered. Even though the userどヨs inter- | such as key strokes are buffered. Even though the user's inter- | |||
| keystroke timing may have sufficient variation and unpredictability, | keystroke timing may have sufficient variation and unpredictability, | |||
| there might not be an easy way to access that variation. Another | there might not be an easy way to access that variation. Another | |||
| problem is that no standard method exists to sample timing details. | problem is that no standard method exists to sample timing details. | |||
| This makes it hard to build standard software intended for | This makes it hard to build standard software intended for | |||
| distribution to a large range of machines based on this technique. | distribution to a large range of machines based on this technique. | |||
| The amount of mouse movement or the keys actually hit are usually | The amount of mouse movement or the keys actually hit are usually | |||
| easier to access than timings but may yield less unpredictability as | easier to access than timings but may yield less unpredictability as | |||
| the user may provide highly repetitive input. | the user may provide highly repetitive input. | |||
| Other external events, such as network packet arrival times, can also | Other external events, such as network packet arrival times and | |||
| be used, with care. In particular, the possibility of manipulation of | lengths, can also be used, but only with great care. In particular, | |||
| such times by an adversary and the lack of history at system start up | the possibility of manipulation of such network traffic measurements | |||
| must be considered. | by an adversary and the lack of history at system start up must be | |||
| carefully considered. If this input is subject to manipulation, it | ||||
| must not be trusted as a source of entropy. | ||||
| Indeed, almost any external sensor, such as raw radio reception or | ||||
| temperature sensing in appropriately equipped computers, can be used | ||||
| in principle. But in each case careful consideration must be given to | ||||
| how much such data is subject to adversarial manipulation and to how | ||||
| much entropy it can actually provide. | ||||
| The above techniques are quite powerful against any attackers having | ||||
| no access to the quantities being measured. For example, they would | ||||
| be powerful against offline attackers who had no access to your | ||||
| environment and were trying to crack your random seed after the fact. | ||||
| In all cases, the more accurately you can measure the timing or value | ||||
| of an external sensor, the more rapidly you can generate bits. | ||||
| 4.3 The Fallacy of Complex Manipulation | 4.3 The Fallacy of Complex Manipulation | |||
| One strategy which may give a misleading appearance of | One strategy which may give a misleading appearance of | |||
| unpredictability is to take a very complex algorithm (or an excellent | unpredictability is to take a very complex algorithm (or an excellent | |||
| traditional pseudo-random number generator with good statistical | traditional pseudo-random number generator with good statistical | |||
| properties) and calculate a cryptographic key by starting with | properties) and calculate a cryptographic key by starting with | |||
| limited data such as the computer system clock value as the seed. An | limited data such as the computer system clock value as the seed. An | |||
| adversary who knew roughly when the generator was started would have | adversary who knew roughly when the generator was started would have | |||
| a relatively small number of seed values to test as they would know | a relatively small number of seed values to test as they would know | |||
| skipping to change at page 13, line 9 ¶ | skipping to change at page 13, line 25 ¶ | |||
| use the limited number of results stemming from a limited number of | use the limited number of results stemming from a limited number of | |||
| seed values to defeat security. | seed values to defeat security. | |||
| Another serious strategy error is to assume that a very complex | Another serious strategy error is to assume that a very complex | |||
| pseudo-random number generation algorithm will produce strong random | pseudo-random number generation algorithm will produce strong random | |||
| numbers when there has been no theory behind or analysis of the | numbers when there has been no theory behind or analysis of the | |||
| algorithm. There is a excellent example of this fallacy right near | algorithm. There is a excellent example of this fallacy right near | |||
| the beginning of Chapter 3 in [KNUTH] where the author describes a | the beginning of Chapter 3 in [KNUTH] where the author describes a | |||
| complex algorithm. It was intended that the machine language program | complex algorithm. It was intended that the machine language program | |||
| corresponding to the algorithm would be so complicated that a person | corresponding to the algorithm would be so complicated that a person | |||
| trying to read the code without comments wouldnどヨt know what the | trying to read the code without comments wouldn't know what the | |||
| program was doing. Unfortunately, actual use of this algorithm showed | program was doing. Unfortunately, actual use of this algorithm showed | |||
| that it almost immediately converged to a single repeated value in | that it almost immediately converged to a single repeated value in | |||
| one case and a small cycle of values in another case. | one case and a small cycle of values in another case. | |||
| Not only does complex manipulation not help you if you have a limited | Not only does complex manipulation not help you if you have a limited | |||
| range of seeds but blindly chosen complex manipulation can destroy | range of seeds but blindly chosen complex manipulation can destroy | |||
| the randomness in a good seed! | the randomness in a good seed! | |||
| 4.4 The Fallacy of Selection from a Large Database | 4.4 The Fallacy of Selection from a Large Database | |||
| Another strategy that can give a misleading appearance of | Another strategy that can give a misleading appearance of | |||
| unpredictability is selection of a quantity randomly from a database | unpredictability is selection of a quantity randomly from a database | |||
| and assume that its strength is related to the total number of bits | and assume that its strength is related to the total number of bits | |||
| in the database. For example, typical USENET servers process many | in the database. For example, typical USENET servers process many | |||
| megabytes of information per day [USENET]. Assume a random quantity | megabytes of information per day [USENET]. Assume a random quantity | |||
| was selected by fetching 32 bytes of data from a random starting | was selected by fetching 32 bytes of data from a random starting | |||
| point in this data. This does not yield 32*8 = 256 bits worth of | point in this data. This does not yield 32*8 = 256 bits worth of | |||
| unguessability. Even after allowing that much of the data is human | unguessability. Even after allowing that much of the data is human | |||
| language and probably has no more than 2 or 3 bits of information per | language and probably has no more than 2 or 3 bits of information per | |||
| byte, it doesnどヨt yield 32*2 = 64 bits of unguessability. For an | byte, it doesn't yield 32*2 = 64 bits of unguessability. For an | |||
| adversary with access to the same usenet database the unguessability | adversary with access to the same usenet database the unguessability | |||
| rests only on the starting point of the selection. That is perhaps a | rests only on the starting point of the selection. That is perhaps a | |||
| little over a couple of dozen bits of unguessability. | little over a couple of dozen bits of unguessability. | |||
| The same argument applies to selecting sequences from the data on a | The same argument applies to selecting sequences from the data on a | |||
| publicly available CD/DVD recording or any other large public | publicly available CD/DVD recording or any other large public | |||
| database. If the adversary has access to the same database, this | database. If the adversary has access to the same database, this | |||
| "selection from a large volume of data" step buys little. However, | "selection from a large volume of data" step buys little. However, | |||
| if a selection can be made from data to which the adversary has no | if a selection can be made from data to which the adversary has no | |||
| access, such as system buffers on an active multi-user system, it may | access, such as system buffers on an active multi-user system, it may | |||
| be of help. | be of help. | |||
| 5. Hardware for Randomness | 5. Hardware for Randomness | |||
| Is there any hope for true strong portable randomness in the future? | Is there any hope for true strong portable randomness in the future? | |||
| There might be. All thatどヨs needed is a physical source of | There might be. All that's needed is a physical source of | |||
| unpredictable numbers. | unpredictable numbers. | |||
| A thermal noise (sometimes called Johnson noise in integrated | A thermal noise (sometimes called Johnson noise in integrated | |||
| circuits) or radioactive decay source and a fast, free-running | circuits) or radioactive decay source and a fast, free-running | |||
| oscillator would do the trick directly [GIFFORD]. This is a trivial | oscillator would do the trick directly [GIFFORD]. This is a trivial | |||
| amount of hardware, and could easily be included as a standard part | amount of hardware, and could easily be included as a standard part | |||
| of a computer systemどヨs architecture. Most audio (or video) input | of a computer system's architecture. Most audio (or video) input | |||
| devices are useable [TURBID]. Furthermore, any system with a | devices are useable [TURBID]. Furthermore, any system with a | |||
| spinning disk or ring oscillator and a stable (crystal) time source | spinning disk or ring oscillator and a stable (crystal) time source | |||
| or the like has an adequate source of randomness ([DAVIS] and Section | or the like has an adequate source of randomness ([DAVIS] and Section | |||
| 5.4). All thatどヨs needed is the common perception among computer | 5.4). All that's needed is the common perception among computer | |||
| vendors that this small additional hardware and the software to | vendors that this small additional hardware and the software to | |||
| access it is necessary and useful. | access it is necessary and useful. | |||
| 5.1 Volume Required | 5.1 Volume Required | |||
| How much unpredictability is needed? Is it possible to quantify the | How much unpredictability is needed? Is it possible to quantify the | |||
| requirement in, say, number of random bits per second? | requirement in, say, number of random bits per second? | |||
| The answer is not very much is needed. For AES, the key can be 128 | The answer is not very much is needed. For AES, the key can be 128 | |||
| bits and, as we show in an example in Section 8, even the highest | bits and, as we show in an example in Section 8, even the highest | |||
| skipping to change at page 15, line 8 ¶ | skipping to change at page 16, line 8 ¶ | |||
| Is there any specific requirement on the shape of the distribution of | Is there any specific requirement on the shape of the distribution of | |||
| the random numbers? The good news is the distribution need not be | the random numbers? The good news is the distribution need not be | |||
| uniform. All that is needed is a conservative estimate of how non- | uniform. All that is needed is a conservative estimate of how non- | |||
| uniform it is to bound performance. Simple techniques to de-skew the | uniform it is to bound performance. Simple techniques to de-skew the | |||
| bit stream are given below and stronger cryptographic techniques are | bit stream are given below and stronger cryptographic techniques are | |||
| described in Section 6.1.2 below. | described in Section 6.1.2 below. | |||
| 5.2.1 Using Stream Parity to De-Skew | 5.2.1 Using Stream Parity to De-Skew | |||
| Consider taking a sufficiently long string of bits and map the string | As a simple but not particularly practical example, consider taking a | |||
| to "zero" or "one". The mapping will not yield a perfectly uniform | sufficiently long string of bits and map the string to "zero" or | |||
| distribution, but it can be as close as desired. One mapping that | "one". The mapping will not yield a perfectly uniform distribution, | |||
| serves the purpose is to take the parity of the string. This has the | but it can be as close as desired. One mapping that serves the | |||
| advantages that it is robust across all degrees of skew up to the | purpose is to take the parity of the string. This has the advantages | |||
| estimated maximum skew and is absolutely trivial to implement in | that it is robust across all degrees of skew up to the estimated | |||
| hardware. | maximum skew and is absolutely trivial to implement in hardware. | |||
| The following analysis gives the number of bits that must be sampled: | The following analysis gives the number of bits that must be sampled: | |||
| Suppose the ratio of ones to zeros is ( 0.5 + e ) to ( 0.5 - e ), | Suppose the ratio of ones to zeros is ( 0.5 + e ) to ( 0.5 - e ), | |||
| where e is between 0 and 0.5 and is a measure of the "eccentricity" | where e is between 0 and 0.5 and is a measure of the "eccentricity" | |||
| of the distribution. Consider the distribution of the parity function | of the distribution. Consider the distribution of the parity function | |||
| of N bit samples. The probabilities that the parity will be one or | of N bit samples. The probabilities that the parity will be one or | |||
| zero will be the sum of the odd or even terms in the binomial | zero will be the sum of the odd or even terms in the binomial | |||
| expansion of (p + q)^N, where p = 0.5 + e, the probability of a one, | expansion of (p + q)^N, where p = 0.5 + e, the probability of a one, | |||
| and q = 0.5 - e, the probability of a zero. | and q = 0.5 - e, the probability of a zero. | |||
| skipping to change at page 16, line 27 ¶ | skipping to change at page 17, line 27 ¶ | |||
| | 0.6 | 0.10 | 4 | | | 0.6 | 0.10 | 4 | | |||
| | 0.7 | 0.20 | 7 | | | 0.7 | 0.20 | 7 | | |||
| | 0.8 | 0.30 | 13 | | | 0.8 | 0.30 | 13 | | |||
| | 0.9 | 0.40 | 28 | | | 0.9 | 0.40 | 28 | | |||
| | 0.95 | 0.45 | 59 | | | 0.95 | 0.45 | 59 | | |||
| | 0.99 | 0.49 | 308 | | | 0.99 | 0.49 | 308 | | |||
| +---------+--------+-------+ | +---------+--------+-------+ | |||
| The last entry shows that even if the distribution is skewed 99% in | The last entry shows that even if the distribution is skewed 99% in | |||
| favor of ones, the parity of a string of 308 samples will be within | favor of ones, the parity of a string of 308 samples will be within | |||
| 0.001 of a 50/50 distribution. | 0.001 of a 50/50 distribution. But, as we shall see in section 6.1.2, | |||
| there are much stronger techniques that extract more of the available | ||||
| entropy. | ||||
| 5.2.2 Using Transition Mappings to De-Skew | 5.2.2 Using Transition Mappings to De-Skew | |||
| Another technique, originally due to von Neumann [VON NEUMANN], is to | Another technique, originally due to von Neumann [VON NEUMANN], is to | |||
| examine a bit stream as a sequence of non-overlapping pairs. You | examine a bit stream as a sequence of non-overlapping pairs. You | |||
| could then discard any 00 or 11 pairs found, interpret 01 as a 0 and | could then discard any 00 or 11 pairs found, interpret 01 as a 0 and | |||
| 10 as a 1. Assume the probability of a 1 is 0.5+e and the probability | 10 as a 1. Assume the probability of a 1 is 0.5+e and the probability | |||
| of a 0 is 0.5-e where e is the eccentricity of the source and | of a 0 is 0.5-e where e is the eccentricity of the source and | |||
| described in the previous section. Then the probability of each pair | described in the previous section. Then the probability of each pair | |||
| is as follows: | is as follows: | |||
| skipping to change at page 17, line 17 ¶ | skipping to change at page 18, line 20 ¶ | |||
| stream and that bits are not correlated, i.e., that the bits are | stream and that bits are not correlated, i.e., that the bits are | |||
| identical independent distributions. If alternate bits were from two | identical independent distributions. If alternate bits were from two | |||
| correlated sources, for example, the above analysis breaks down. | correlated sources, for example, the above analysis breaks down. | |||
| The above technique also provides another illustration of how a | The above technique also provides another illustration of how a | |||
| simple statistical analysis can mislead if one is not always on the | simple statistical analysis can mislead if one is not always on the | |||
| lookout for patterns that could be exploited by an adversary. If the | lookout for patterns that could be exploited by an adversary. If the | |||
| algorithm were mis-read slightly so that overlapping successive bits | algorithm were mis-read slightly so that overlapping successive bits | |||
| pairs were used instead of non-overlapping pairs, the statistical | pairs were used instead of non-overlapping pairs, the statistical | |||
| analysis given is the same; however, instead of providing an unbiased | analysis given is the same; however, instead of providing an unbiased | |||
| uncorrelated series of random 1どヨs and 0どヨs, it instead produces a | uncorrelated series of random 1s and 0s, it instead produces a | |||
| totally predictable sequence of exactly alternating 1どヨs and 0どヨs. | totally predictable sequence of exactly alternating 1s and 0s. | |||
| 5.2.3 Using FFT to De-Skew | 5.2.3 Using FFT to De-Skew | |||
| When real world data consists of strongly biased or correlated bits, | When real world data consists of strongly biased or correlated bits, | |||
| it may still contain useful amounts of randomness. This randomness | it may still contain useful amounts of randomness. This randomness | |||
| can be extracted through use of the discrete Fourier transform or its | can be extracted through use of various transforms, the most powerful | |||
| optimized variant, the FFT. | of which are described in section 6.1.2 below. | |||
| Using the Fourier transform of the data, strong correlations can be | Using the Fourier transform of the data or its optimized variant, the | |||
| discarded. If adequate data is processed and remaining correlations | FFT, is an technique interesting primarily for theoretical reasons. | |||
| decay, spectral lines approaching statistical independence and | It can be show that this will discard strong correlations. If | |||
| normally distributed randomness can be produced [BRILLINGER]. | adequate data is processed and remaining correlations decay, spectral | |||
| lines approaching statistical independence and normally distributed | ||||
| randomness can be produced [BRILLINGER]. | ||||
| 5.2.4 Using Compression to De-Skew | 5.2.4 Using Compression to De-Skew | |||
| Reversible compression techniques also provide a crude method of de- | Reversible compression techniques also provide a crude method of de- | |||
| skewing a skewed bit stream. This follows directly from the | skewing a skewed bit stream. This follows directly from the | |||
| definition of reversible compression and the formula in Section 2 | definition of reversible compression and the formula in Section 2 | |||
| above for the amount of information in a sequence. Since the | above for the amount of information in a sequence. Since the | |||
| compression is reversible, the same amount of information must be | compression is reversible, the same amount of information must be | |||
| present in the shorter output than was present in the longer input. | present in the shorter output than was present in the longer input. | |||
| By the Shannon information equation, this is only possible if, on | By the Shannon information equation, this is only possible if, on | |||
| average, the probabilities of the different shorter sequences are | average, the probabilities of the different shorter sequences are | |||
| more uniformly distributed than were the probabilities of the longer | more uniformly distributed than were the probabilities of the longer | |||
| sequences. Therefore the shorter sequences must be de-skewed relative | sequences. Therefore the shorter sequences must be de-skewed relative | |||
| to the input. | to the input. | |||
| However, many compression techniques add a somewhat predictable | However, many compression techniques add a somewhat predictable | |||
| preface to their output stream and may insert such a sequence again | preface to their output stream and may insert such a sequence again | |||
| periodically in their output or otherwise introduce subtle patterns | periodically in their output or otherwise introduce subtle patterns | |||
| of their own. They should be considered only a rough technique | of their own. They should be considered only a rough technique | |||
| compared with those described above or in Section 6.1.2. At a | compared with those described in Section 6.1.2. At a minimum, the | |||
| minimum, the beginning of the compressed sequence should be skipped | beginning of the compressed sequence should be skipped and only later | |||
| and only later bits used for applications requiring random bits. | bits used for applications requiring roughly random bits. | |||
| 5.3 Existing Hardware Can Be Used For Randomness | 5.3 Existing Hardware Can Be Used For Randomness | |||
| As described below, many computers come with hardware that can, with | As described below, many computers come with hardware that can, with | |||
| care, be used to generate truly random quantities. | care, be used to generate truly random quantities. | |||
| 5.3.1 Using Existing Sound/Video Input | 5.3.1 Using Existing Sound/Video Input | |||
| Many computers are built with inputs that digitize some real world | Many computers are built with inputs that digitize some real world | |||
| analog source, such as sound from a microphone or video input from a | analog source, such as sound from a microphone or video input from a | |||
| camera. Under appropriate circumstances, such input can provide | camera. Under appropriate circumstances, such input can provide | |||
| reasonably high quality random bits. The "input" from a sound | reasonably high quality random bits. The "input" from a sound | |||
| digitizer with no source plugged in or a camera with the lens cap on, | digitizer with no source plugged in or a camera with the lens cap on, | |||
| if the system has enough gain to detect anything, is essentially | if the system has enough gain to detect anything, is essentially | |||
| thermal noise. | thermal noise. This method is extremely hardware and implementation | |||
| dependent. | ||||
| For example, on some UNIX based systems, one can read from the | For example, on some UNIX based systems, one can read from the | |||
| /dev/audio device with nothing plugged into the microphone jack or | /dev/audio device with nothing plugged into the microphone jack or | |||
| the microphone receiving only low level background noise. Such data | the microphone receiving only low level background noise. Such data | |||
| is essentially random noise although it should not be trusted without | is essentially random noise although it should not be trusted without | |||
| some checking in case of hardware failure. It will, in any case, need | some checking in case of hardware failure. It will, in any case, need | |||
| to be de-skewed as described elsewhere. | to be de-skewed as described elsewhere. | |||
| Combining this with compression to de-skew one can, in UNIXese, | Combining this with compression to de-skew one can, in UNIXese, | |||
| generate a huge amount of medium quality random data by doing | generate a huge amount of medium quality random data by doing | |||
| cat /dev/audio | compress - >random-bits-file | cat /dev/audio | compress - >random-bits-file | |||
| A detailed examination of this type of randomness source appears in | A detailed examination of this type of randomness source appears in | |||
| [TURBID]. | [TURBID]. | |||
| 5.3.2 Using Existing Disk Drives | 5.3.2 Using Existing Disk Drives | |||
| Disk drives have small random fluctuations in their rotational speed | Disk drives have small random fluctuations in their rotational speed | |||
| due to chaotic air turbulence [DAVIS]. By adding low level disk seek | due to chaotic air turbulence [DAVIS, Jakobsson]. By adding low | |||
| time instrumentation to a system, a series of measurements can be | level disk seek time instrumentation to a system, a series of | |||
| obtained that include this randomness. Such data is usually highly | measurements can be obtained that include this randomness. Such data | |||
| correlated so that significant processing is needed, such as FFT (see | is usually highly correlated so that significant processing is | |||
| section 5.2.3). Nevertheless experimentation has shown that, with | needed, such as described in 6.1.2 below. Nevertheless | |||
| such processing, most disk drives easily produce 100 bits a minute or | experimentation a decade ago showed that, with such processing, even | |||
| more of excellent random data. | slow disk drives on the slower computers of that day could easily | |||
| produce 100 bits a minute or more of excellent random data. | ||||
| Partly offsetting this need for processing is the fact that disk | Every increase in processor speed, which increases the resolution | |||
| drive failure will normally be rapidly noticed. Thus, problems with | with which disk motion can be timed, or increase in the rate of disk | |||
| this method of random number generation due to hardware failure are | seeks, increases the rate of random bit generation possible with this | |||
| unlikely. | technique. At the time of this paper and using modern hardware, a | |||
| more typical rate of random bit production would be in excess of | ||||
| 10,000 bits a second. This technique is used in many operating system | ||||
| library random number generators. | ||||
| Note: the inclusion of cache memories in disk controllers has little | ||||
| effect on this technique if very short seek times, which represent | ||||
| cache hits, are simply ignored. | ||||
| 5.4 Ring Oscillator Sources | 5.4 Ring Oscillator Sources | |||
| If an integrated circuit is being designed or field programmed, an | If an integrated circuit is being designed or field programmed, an | |||
| odd number of gates can be connected in series to produce a free- | odd number of gates can be connected in series to produce a free- | |||
| running ring oscillator. By sampling a point in the ring at a fixed | running ring oscillator. By sampling a point in the ring at a fixed | |||
| frequency, say one determined by a stable crystal oscillator, some | frequency, say one determined by a stable crystal oscillator, some | |||
| amount of entropy can be extracted due to variations in the free- | amount of entropy can be extracted due to variations in the free- | |||
| running oscillator timing. It is possible to increase the rate of | running oscillator timing. It is possible to increase the rate of | |||
| entropy by xorどヨing sampled values from a few ring oscillators with | entropy by xor'ing sampled values from a few ring oscillators with | |||
| relatively prime lengths. It is sometimes recommended that an odd | relatively prime lengths. It is sometimes recommended that an odd | |||
| number of rings be used so that, even if the rings somehow become | number of rings be used so that, even if the rings somehow become | |||
| synchronously locked to each other, there will still be sampled bit | synchronously locked to each other, there will still be sampled bit | |||
| transitions. Another possibility source to sample is the output of a | transitions. Another possibility source to sample is the output of a | |||
| noisy diode. | noisy diode. | |||
| Sampled bits from such sources will have to be heavily de-skewed, as | Sampled bits from such sources will have to be heavily de-skewed, as | |||
| disk rotation timings must be (Section 5.3.2). An engineering study | disk rotation timings must be (Section 5.3.2). An engineering study | |||
| would be needed to determine the amount of entropy being produced | would be needed to determine the amount of entropy being produced | |||
| depending on the particular design. In any case, these can be good | depending on the particular design. In any case, these can be good | |||
| skipping to change at page 21, line 20 ¶ | skipping to change at page 22, line 20 ¶ | |||
| sources and to mix them with a strong mixing function. Such a | sources and to mix them with a strong mixing function. Such a | |||
| function will preserve the randomness present in any of the sources | function will preserve the randomness present in any of the sources | |||
| even if other quantities being combined happen to be fixed or easily | even if other quantities being combined happen to be fixed or easily | |||
| guessable. This may be advisable even with a good hardware source, as | guessable. This may be advisable even with a good hardware source, as | |||
| hardware can also fail, though this should be weighed against any | hardware can also fail, though this should be weighed against any | |||
| increase in the chance of overall failure due to added software | increase in the chance of overall failure due to added software | |||
| complexity. | complexity. | |||
| 6.1 Mixing Functions | 6.1 Mixing Functions | |||
| A strong mixing function is one which combines two or more inputs and | A strong mixing function is one which combines inputs and produces an | |||
| produces an output where each output bit is a different complex non- | output where each output bit is a different complex non-linear | |||
| linear function of all the input bits. On average, changing any input | function of all the input bits. On average, changing any input bit | |||
| bit will change about half the output bits. But because the | will change about half the output bits. But because the relationship | |||
| relationship is complex and non-linear, no particular output bit is | is complex and non-linear, no particular output bit is guaranteed to | |||
| guaranteed to change when any particular input bit is changed. | change when any particular input bit is changed. | |||
| Consider the problem of converting a stream of bits that is skewed | Consider the problem of converting a stream of bits that is skewed | |||
| towards 0 or 1 or which has a somewhat predictable pattern to a | towards 0 or 1 or which has a somewhat predictable pattern to a | |||
| shorter stream which is more random, as discussed in Section 5.2 | shorter stream which is more random, as discussed in Section 5.2 | |||
| above. This is simply another case where a strong mixing function is | above. This is simply another case where a strong mixing function is | |||
| desired, mixing the input bits to produce a smaller number of output | desired, mixing the input bits to produce a smaller number of output | |||
| bits. The technique given in Section 5.2.1 of using the parity of a | bits. The technique given in Section 5.2.1 of using the parity of a | |||
| number of bits is simply the result of successively Exclusive Orどヨing | number of bits is simply the result of successively Exclusive Or'ing | |||
| them which is examined as a trivial mixing function immediately | them which is examined as a trivial mixing function immediately | |||
| below. Use of stronger mixing functions to extract more of the | below. Use of stronger mixing functions to extract more of the | |||
| randomness in a stream of skewed bits is examined in Section 6.1.2. | randomness in a stream of skewed bits is examined in Section 6.1.2. | |||
| 6.1.1 A Trivial Mixing Function | 6.1.1 A Trivial Mixing Function | |||
| A trivial example for single bit inputs is the Exclusive Or function, | A trivial example for single bit inputs described only for expository | |||
| which is equivalent to addition without carry, as show in the table | purposes is the Exclusive Or function, which is equivalent to | |||
| below. This is a degenerate case in which the one output bit always | addition without carry, as show in the table below. This is a | |||
| changes for a change in either input bit. But, despite its | degenerate case in which the one output bit always changes for a | |||
| simplicity, it provides a useful illustration. | change in either input bit. But, despite its simplicity, it provides | |||
| a useful illustration. | ||||
| +-----------+-----------+----------+ | +-----------+-----------+----------+ | |||
| | input 1 | input 2 | output | | | input 1 | input 2 | output | | |||
| +-----------+-----------+----------+ | +-----------+-----------+----------+ | |||
| | 0 | 0 | 0 | | | 0 | 0 | 0 | | |||
| | 0 | 1 | 1 | | | 0 | 1 | 1 | | |||
| | 1 | 0 | 1 | | | 1 | 0 | 1 | | |||
| | 1 | 1 | 0 | | | 1 | 1 | 0 | | |||
| +-----------+-----------+----------+ | +-----------+-----------+----------+ | |||
| skipping to change at page 23, line 25 ¶ | skipping to change at page 24, line 25 ¶ | |||
| Although the message digest functions are designed for variable | Although the message digest functions are designed for variable | |||
| amounts of input, AES and other encryption functions can also be used | amounts of input, AES and other encryption functions can also be used | |||
| to combine any number of inputs. If 128 bits of output is adequate, | to combine any number of inputs. If 128 bits of output is adequate, | |||
| the inputs can be packed into a 128-bit data quantity and successive | the inputs can be packed into a 128-bit data quantity and successive | |||
| AES keys, padding with zeros if needed, which are then used to | AES keys, padding with zeros if needed, which are then used to | |||
| successively encrypt using AES in Electronic Codebook Mode. Or the | successively encrypt using AES in Electronic Codebook Mode. Or the | |||
| input could be packed into one 128-bit key and multiple data blocks | input could be packed into one 128-bit key and multiple data blocks | |||
| and a CBC-MAC calculated [MODES]. | and a CBC-MAC calculated [MODES]. | |||
| If more than 128 bits of output are needed, use more complex mixing. | If more than 128 bits of output are needed and you want to employ | |||
| But keep in mind that it is absolutely impossible to get more bits of | AES, use more complex mixing. But keep in mind that it is absolutely | |||
| "randomness" out than are put in. For example, if inputs are packed | impossible to get more bits of "randomness" out than are put in. For | |||
| into three quantities, A, B, and C, use AES to encrypt A with B as a | example, if inputs are packed into three quantities, A, B, and C, use | |||
| key and then with C as a key to produce the 1st part of the output, | AES to encrypt A with B as a key and then with C as a key to produce | |||
| then encrypt B with C and then A for more output and, if necessary, | the 1st part of the output, then encrypt B with C and then A for more | |||
| encrypt C with A and then B for yet more output. Still more output | output and, if necessary, encrypt C with A and then B for yet more | |||
| can be produced by reversing the order of the keys given above to | output. Still more output can be produced by reversing the order of | |||
| stretch things. The same can be done with the hash functions by | the keys given above to stretch things. The same can be done with the | |||
| hashing various subsets of the input data or different copies of the | hash functions by hashing various subsets of the input data or | |||
| input data with different prefixes and/or suffixes to produce | different copies of the input data with different prefixes and/or | |||
| multiple outputs. | suffixes to produce multiple outputs. | |||
| An example of using a strong mixing function would be to reconsider | An example of using a strong mixing function would be to reconsider | |||
| the case of a string of 308 bits each of which is biased 99% towards | the case of a string of 308 bits each of which is biased 99% towards | |||
| zero. The parity technique given in Section 5.2.1 above reduced this | zero. The parity technique given in Section 5.2.1 above reduced this | |||
| to one bit with only a 1/1000 deviance from being equally likely a | to one bit with only a 1/1000 deviance from being equally likely a | |||
| zero or one. But, applying the equation for information given in | zero or one. But, applying the equation for information given in | |||
| Section 2, this 308 bit skewed sequence has over 5 bits of | Section 2, this 308 bit skewed sequence has over 5 bits of | |||
| information in it. Thus hashing it with SHA-1 and taking the bottom 5 | information in it. Thus hashing it with SHA-1 and taking the bottom 5 | |||
| bits of the result would yield 5 unbiased random bits as opposed to | bits of the result would yield 5 unbiased random bits as opposed to | |||
| the single bit given by calculating the parity of the string. | the single bit given by calculating the parity of the string. | |||
| skipping to change at page 24, line 14 ¶ | skipping to change at page 25, line 14 ¶ | |||
| 6.1.3 Using S-Boxes for Mixing | 6.1.3 Using S-Boxes for Mixing | |||
| Many modern block encryption functions, including DES and AES, | Many modern block encryption functions, including DES and AES, | |||
| incorporate modules known as S-Boxes (substitution boxes). These | incorporate modules known as S-Boxes (substitution boxes). These | |||
| produce a smaller number of outputs from a larger number of inputs | produce a smaller number of outputs from a larger number of inputs | |||
| through a complex non-linear mixing function which would have the | through a complex non-linear mixing function which would have the | |||
| effect of concentrating limited entropy in the inputs into the | effect of concentrating limited entropy in the inputs into the | |||
| output. | output. | |||
| S-Boxes sometimes incorporate bent boolean functions (functions of an | S-Boxes sometimes incorporate bent Boolean functions (functions of an | |||
| even number of bits producing one output bit with maximum non- | even number of bits producing one output bit with maximum non- | |||
| linearity). Looking at the output for all input pairs differing in | linearity). Looking at the output for all input pairs differing in | |||
| any particular bit position, exactly half the outputs are different. | any particular bit position, exactly half the outputs are different. | |||
| An S-Box in which each output bit is produced by a bent function such | An S-Box in which each output bit is produced by a bent function such | |||
| that any linear combination of these functions is also a bent | that any linear combination of these functions is also a bent | |||
| function is called a "perfect S-Box". | function is called a "perfect S-Box". | |||
| S-boxes and various repeated application or cascades of such boxes | S-boxes and various repeated application or cascades of such boxes | |||
| can be used for mixing. [SBOX*] | can be used for mixing. [SBOX*] | |||
| skipping to change at page 25, line 8 ¶ | skipping to change at page 26, line 8 ¶ | |||
| 6.1.5 Using a Mixing Function to Stretch Random Bits | 6.1.5 Using a Mixing Function to Stretch Random Bits | |||
| While it is not necessary for a mixing function to produce the same | While it is not necessary for a mixing function to produce the same | |||
| or fewer bits than its inputs, mixing bits cannot "stretch" the | or fewer bits than its inputs, mixing bits cannot "stretch" the | |||
| amount of random unpredictability present in the inputs. Thus four | amount of random unpredictability present in the inputs. Thus four | |||
| inputs of 32 bits each where there is 12 bits worth of | inputs of 32 bits each where there is 12 bits worth of | |||
| unpredictability (such as 4,096 equally probable values) in each | unpredictability (such as 4,096 equally probable values) in each | |||
| input cannot produce more than 48 bits worth of unpredictable output. | input cannot produce more than 48 bits worth of unpredictable output. | |||
| The output can be expanded to hundreds or thousands of bits by, for | The output can be expanded to hundreds or thousands of bits by, for | |||
| example, mixing with successive integers, but the clever adversaryどヨs | example, mixing with successive integers, but the clever adversary's | |||
| search space is still 2^48 possibilities. Furthermore, mixing to | search space is still 2^48 possibilities. Furthermore, mixing to | |||
| fewer bits than are input will tend to strengthen the randomness of | fewer bits than are input will tend to strengthen the randomness of | |||
| the output the way using Exclusive Or to produce one bit from two did | the output. | |||
| above. | ||||
| The last table in Section 6.1.1 shows that mixing a random bit with a | The last table in Section 6.1.1 shows that mixing a random bit with a | |||
| constant bit with Exclusive Or will produce a random bit. While this | constant bit with Exclusive Or will produce a random bit. While this | |||
| is true, it does not provide a way to "stretch" one random bit into | is true, it does not provide a way to "stretch" one random bit into | |||
| more than one. If, for example, a random bit is mixed with a 0 and | more than one. If, for example, a random bit is mixed with a 0 and | |||
| then with a 1, this produces a two bit sequence but it will always be | then with a 1, this produces a two bit sequence but it will always be | |||
| either 01 or 10. Since there are only two possible values, there is | either 01 or 10. Since there are only two possible values, there is | |||
| still only the one bit of original randomness. | still only the one bit of original randomness. | |||
| 6.1.6 Other Factors in Choosing a Mixing Function | 6.1.6 Other Factors in Choosing a Mixing Function | |||
| skipping to change at page 27, line 26 ¶ | skipping to change at page 28, line 26 ¶ | |||
| way from the previous value, then when any value is compromised, all | way from the previous value, then when any value is compromised, all | |||
| future values can be determined. This would be the case, for example, | future values can be determined. This would be the case, for example, | |||
| if each value were a constant function of the previously used values, | if each value were a constant function of the previously used values, | |||
| even if the function were a very strong, non-invertible message | even if the function were a very strong, non-invertible message | |||
| digest function. | digest function. | |||
| (It should be noted that if your technique for generating a sequence | (It should be noted that if your technique for generating a sequence | |||
| of key values is fast enough, it can trivially be used as the basis | of key values is fast enough, it can trivially be used as the basis | |||
| for a confidentiality system. If two parties use the same sequence | for a confidentiality system. If two parties use the same sequence | |||
| generating technique and start with the same seed material, they will | generating technique and start with the same seed material, they will | |||
| generate identical sequences. These could, for example, be xorどヨed at | generate identical sequences. These could, for example, be xor'ed at | |||
| one end with data being send, encrypting it, and xorどヨed with this | one end with data being send, encrypting it, and xor'ed with this | |||
| data as received, decrypting it due to the reversible properties of | data as received, decrypting it due to the reversible properties of | |||
| the xor operation. This is commonly referred to as a simple stream | the xor operation. This is commonly referred to as a simple stream | |||
| cipher.) | cipher.) | |||
| 6.3.1 Traditional Strong Sequences | 6.3.1 OFB and CTR Sequences | |||
| A traditional way to achieve a strong sequence has been to have the | One way to achieve a strong sequence is to have the values be | |||
| values be produced by hashing the quantities produced by | produced by taking a seed value and hashing the quantities produced | |||
| concatenating the seed with successive integers or the like and then | by concatenating the seed with successive integers or the like and | |||
| mask the values obtained so as to limit the amount of generator state | then mask the values obtained so as to limit the amount of generator | |||
| available to the adversary. | state available to the adversary. | |||
| It may also be possible to use an "encryption" algorithm with a | It may also be possible to use an "encryption" algorithm with a | |||
| random key and seed value to encrypt and feedback some or all of the | random key and seed value to encrypt successive integers as in | |||
| output encrypted value into the value to be encrypted for the next | counter (CTR) mode encryption. Alternatively, you can feedback all of | |||
| iteration. Appropriate feedback techniques will usually be | the output encrypted value into the value to be encrypted for the | |||
| recommended with the encryption algorithm. An example is shown below | next iteration. This is a particular example of output feedback mode | |||
| where shifting and masking are used to combine the cypher output | (OFB). [MODES] | |||
| feedback. This type of feedback is defined by the US Government in | ||||
| connection with AES and DES [MODES] as Output Feedback Mode (OFM) but | An example is shown below where shifting and masking are used to | |||
| should be avoided for reasons described below. | combine part of the output feedback with part of the old input. This | |||
| type of partial feedback should be avoided for reasons described | ||||
| below. | ||||
| +---------------+ | +---------------+ | |||
| | V | | | V | | |||
| | | n |--+ | | | n |--+ | |||
| +--+------------+ | | +--+------------+ | | |||
| | | +---------+ | | | +---------+ | |||
| shift| +---> | | +-----+ | shift| +---> | | +-----+ | |||
| +--+ | Encrypt | <--- | Key | | +--+ | Encrypt | <--- | Key | | |||
| | +-------- | | +-----+ | | +-------- | | +-----+ | |||
| | | +---------+ | | | +---------+ | |||
| skipping to change at page 28, line 49 ¶ | skipping to change at page 29, line 49 ¶ | |||
| sequence. Thus it is best to use only one bit from each value. It has | sequence. Thus it is best to use only one bit from each value. It has | |||
| been shown that in some cases this makes it impossible to break a | been shown that in some cases this makes it impossible to break a | |||
| system even when the cryptographic system is invertible and can be | system even when the cryptographic system is invertible and can be | |||
| broken if all of each generated value was revealed. | broken if all of each generated value was revealed. | |||
| 6.3.2 The Blum Blum Shub Sequence Generator | 6.3.2 The Blum Blum Shub Sequence Generator | |||
| Currently the generator which has the strongest public proof of | Currently the generator which has the strongest public proof of | |||
| strength is called the Blum Blum Shub generator after its inventors | strength is called the Blum Blum Shub generator after its inventors | |||
| [BBS]. It is also very simple and is based on quadratic residues. | [BBS]. It is also very simple and is based on quadratic residues. | |||
| Itどヨs only disadvantage is that it is computationally intensive | Its only disadvantage is that it is computationally intensive | |||
| compared with the traditional techniques give in 6.3.1 above. This is | compared with the traditional techniques give in 6.3.1 above. This is | |||
| not a major draw back if it is used for moderately infrequent | not a major draw back if it is used for moderately infrequent | |||
| purposes, such as generating session keys. | purposes, such as generating session keys. | |||
| Simply choose two large prime numbers, say p and q, which both have | Simply choose two large prime numbers, say p and q, which both have | |||
| the property that you get a remainder of 3 if you divide them by 4. | the property that you get a remainder of 3 if you divide them by 4. | |||
| Let n = p * q. Then you choose a random number x relatively prime to | Let n = p * q. Then you choose a random number x relatively prime to | |||
| n. The initial seed for the generator and the method for calculating | n. The initial seed for the generator and the method for calculating | |||
| subsequent values are then | subsequent values are then | |||
| skipping to change at page 29, line 45 ¶ | skipping to change at page 30, line 45 ¶ | |||
| This means that in applications where many keys are generated in this | This means that in applications where many keys are generated in this | |||
| fashion, it is not necessary to save them all. Each key can be | fashion, it is not necessary to save them all. Each key can be | |||
| effectively indexed and recovered from that small index and the | effectively indexed and recovered from that small index and the | |||
| initial s and n. | initial s and n. | |||
| 6.3.3 Entropy Pool Techniques | 6.3.3 Entropy Pool Techniques | |||
| Many modern pseudo-random number sources utilize the technique of | Many modern pseudo-random number sources utilize the technique of | |||
| maintaining a "pool" of bits and providing operations for strongly | maintaining a "pool" of bits and providing operations for strongly | |||
| mixing input with some randomness into the pool and extracting psuedo | mixing input with some randomness into the pool and extracting pseudo | |||
| random bits from the pool. This is illustrated in the figure below. | random bits from the pool. This is illustrated in the figure below. | |||
| +--------+ +------+ +---------+ | +--------+ +------+ +---------+ | |||
| --->| Mix In |--->| POOL |--->| Extract |---> | --->| Mix In |--->| POOL |--->| Extract |---> | |||
| | Bits | | | | Bits | | | Bits | | | | Bits | | |||
| +--------+ +------+ +---------+ | +--------+ +------+ +---------+ | |||
| ^ V | ^ V | |||
| | | | | | | |||
| +-----------+ | +-----------+ | |||
| Bits to be feed into the pool can be any of the various hardware, | Bits to be feed into the pool can be any of the various hardware, | |||
| environmental, or user input sources discussed above. It is also | environmental, or user input sources discussed above. It is also | |||
| common to save the state of the pool on system shut down and restore | common to save the state of the pool on system shut down and restore | |||
| it on re-starting, if stable storage is available. | it on re-starting, if stable storage is available. | |||
| Care must be taken that enough entropy has been added to the pool to | Care must be taken that enough entropy has been added to the pool to | |||
| support particular output uses desired. See Section 7.5 for more | support particular output uses desired. See Section 7.5 for more | |||
| details on an example implementation and [RSA BULL1] for similar | details on an example implementation and [RSA BULL1] for similar | |||
| suggestions. | suggestions. | |||
| 7. Key Generation Standards and Examples | 7. Key Generation Examples and Standards | |||
| Several public standards and widely deployed examples are now in | Several public standards and widely deployed examples are now in | |||
| place for the generation of keys without special hardware. Three | place for the generation of keys without special hardware. Three | |||
| standards are described below. The two older standards use DES, with | standards are described below. The two older standards use DES, with | |||
| its 64-bit block and key size limit, but any equally strong or | its 64-bit block and key size limit, but any equally strong or | |||
| stronger mixing function could be substituted. The third is a more | stronger mixing function could be substituted [DES]. The third is a | |||
| modern and stronger standard based on SHA-1. Lastly the widely | more modern and stronger standard based on SHA-1 [SHA*]. Lastly the | |||
| deployed modern UNIX random number generators are described. | widely deployed modern UNIX random number generators are described. | |||
| 7.1 US DoD Recommendations for Password Generation | 7.1 US DoD Recommendations for Password Generation | |||
| The United States Department of Defense has specific recommendations | The United States Department of Defense has specific recommendations | |||
| for password generation [DoD]. They suggest using the US Data | for password generation [DoD]. They suggest using the US Data | |||
| Encryption Standard [DES] in Output Feedback Mode [MODES] as follows: | Encryption Standard [DES] in Output Feedback Mode [MODES] as follows: | |||
| use an initialization vector determined from | use an initialization vector determined from | |||
| the system clock, | the system clock, | |||
| system ID, | system ID, | |||
| skipping to change at page 32, line 24 ¶ | skipping to change at page 33, line 24 ¶ | |||
| s = DES ( k, DES ( k, t ) .xor. g ) | s = DES ( k, DES ( k, t ) .xor. g ) | |||
| n+1 n | n+1 n | |||
| If g sub n is to be used as a DES key, then every eighth bit should | If g sub n is to be used as a DES key, then every eighth bit should | |||
| be adjusted for parity for that use but the entire 64 bit unmodified | be adjusted for parity for that use but the entire 64 bit unmodified | |||
| g should be used in calculating the next s. | g should be used in calculating the next s. | |||
| 7.3 DSS Pseudo-Random Number Generation | 7.3 DSS Pseudo-Random Number Generation | |||
| Appendix 3 of the NIST Digital Signature Standard [DSS] provides an | Appendix 3 of the NIST Digital Signature Standard [DSS] provides a | |||
| approved method of producing a sequence of pseudo-random 160 bit | method of producing a sequence of pseudo-random 160 bit quantities | |||
| quantities for use as private keys or the like. A subset of that | for use as private keys or the like. This has been modified by Change | |||
| algorithm is as follows: | Notice 1 [DSS CN1] to produce the following algorithm for generating | |||
| general purpose pseudorandom numbers: | ||||
| t = 0x 67452301 EFCDAB89 98BADCFE 10325476 C3D2E1F0 | t = 0x 67452301 EFCDAB89 98BADCFE 10325476 C3D2E1F0 | |||
| q = a 160-bit prime number | ||||
| XKEY = initial seed | XKEY = initial seed | |||
| 0 | 0 | |||
| For j = 0 to ... | For j = 0 to ... | |||
| XVAL = ( XKEY + optional user input ) (Mod 2^512) | XVAL = ( XKEY + optional user input ) (Mod 2^512) | |||
| j | j | |||
| X = G( t, XVAL ) (Mod q) | X = G( t, XVAL ) | |||
| j | j | |||
| XKEY = ( 1 + XKEY + X ) (Mod 2^512) | XKEY = ( 1 + XKEY + X ) (Mod 2^512) | |||
| j+1 j j | j+1 j j | |||
| The quantities X thus produced are the pseudo-random sequence of | The quantities X thus produced are the pseudo-random sequence of 160 | |||
| values in the rang 0 to q. Two functions can be used for "G" above. | bit values. Two functions can be used for "G" above. Each produces | |||
| Each produces a 160-bit value and takes two arguments, the first a | a 160-bit value and takes two arguments, the first argument a 160-bit | |||
| 160-bit value and the second a 512 bit value. | value and the second a 512 bit value. | |||
| The first is based on SHA-1 and works by setting the 5 linking | The first is based on SHA-1 and works by setting the 5 linking | |||
| variables, denoted H with subscripts in the SHA-1 specification, to | variables, denoted H with subscripts in the SHA-1 specification, to | |||
| the first argument divided into fifths. Then steps (a) through (e) of | the first argument divided into fifths. Then steps (a) through (e) of | |||
| section 7 of the NIST SHA-1 specification are run over the second | section 7 of the NIST SHA-1 specification are run over the second | |||
| argument as if it were a 512-bit data block. The values of the | argument as if it were a 512-bit data block. The values of the | |||
| linking variable after those steps are then concatenated to produce | linking variable after those steps are then concatenated to produce | |||
| the output of G. [SHA-1] | the output of G. [SHA*] | |||
| As an alternative second method, NIST also defined an alternate G | As an alternative second method, NIST also defined an alternate G | |||
| function based on multiple applications of the DES encryption | function based on multiple applications of the DES encryption | |||
| function [DSS]. | function [DSS]. | |||
| 7.4 X9.82 Pseudo-Random Number Generation | 7.4 X9.82 Pseudo-Random Number Generation | |||
| The National Institute for Standards and Technology (NIST) and the | The National Institute for Standards and Technology (NIST) and the | |||
| American National Standards Institutes (ANSI) X9F1 committee are in | American National Standards Institutes (ANSI) X9F1 committee are in | |||
| the final stages of creating a standard for random number generation. | the final stages of creating a standard for random number generation | |||
| This standard includes a number of random number generators for use | covering both true randomness generators and pseudo-random number | |||
| with AES and other block ciphers. It also includes random number | generators. It includes a number of pseudo-random number generators | |||
| generators based on hash functions and the arithmetic of elliptic | for use with AES and other block ciphers. It also includes random | |||
| curves [X9.82]. | number generators based on hash functions and the arithmetic of | |||
| elliptic curves [X9.82]. | ||||
| 7.5 The /dev/random Device | 7.5 The /dev/random Device | |||
| Several versions of the UNIX operating system provides a kernel- | Several versions of the UNIX operating system provides a kernel- | |||
| resident random number generator. In some cases, these generators | resident random number generator. In some cases, these generators | |||
| makes use of events captured by the Kernel during normal system | makes use of events captured by the Kernel during normal system | |||
| operation. | operation. | |||
| For example, on some versions of Linux, the generator consists of a | For example, on some versions of Linux, the generator consists of a | |||
| random pool of 512 bytes represented as 128 words of 4-bytes each. | random pool of 512 bytes represented as 128 words of 4-bytes each. | |||
| When an event occurs, such as a disk drive interrupt, the time of the | When an event occurs, such as a disk drive interrupt, the time of the | |||
| event is xorどヨed into the pool and the pool is stirred via a primitive | event is xor'ed into the pool and the pool is stirred via a primitive | |||
| polynomial of degree 128. The pool itself is treated as a ring | polynomial of degree 128. The pool itself is treated as a ring | |||
| buffer, with new data being XORed (after stirring with the | buffer, with new data being XORed (after stirring with the | |||
| polynomial) across the entire pool. | polynomial) across the entire pool. | |||
| Each call that adds entropy to the pool estimates the amount of | Each call that adds entropy to the pool estimates the amount of | |||
| likely true entropy the input contains. The pool itself contains a | likely true entropy the input contains. The pool itself contains a | |||
| accumulator that estimates the total over all entropy of the pool. | accumulator that estimates the total over all entropy of the pool. | |||
| Input events come from several sources as listed below. | Input events come from several sources as listed below. | |||
| Unfortunately, for server machines without human operators, the first | Unfortunately, for server machines without human operators, the first | |||
| skipping to change at page 34, line 16 ¶ | skipping to change at page 35, line 16 ¶ | |||
| code are added to the pool. This in effect adds entropy from the | code are added to the pool. This in effect adds entropy from the | |||
| human operator by measuring inter-keystroke arrival times. | human operator by measuring inter-keystroke arrival times. | |||
| 2. Disk completion and other interrupts. A system being used by a | 2. Disk completion and other interrupts. A system being used by a | |||
| person will likely have a hard to predict pattern of disk | person will likely have a hard to predict pattern of disk | |||
| accesses. (But not all disk drivers support capturing this timing | accesses. (But not all disk drivers support capturing this timing | |||
| information with sufficient accuracy to be useful.) | information with sufficient accuracy to be useful.) | |||
| 3. Mouse motion. The timing as well as mouse position is added in. | 3. Mouse motion. The timing as well as mouse position is added in. | |||
| When random bytes are required, the pool is hashed with SHA-1 [SHA1] | When random bytes are required, the pool is hashed with SHA-1 [SHA*] | |||
| to yield the returned bytes of randomness. If more bytes are required | to yield the returned bytes of randomness. If more bytes are required | |||
| than the output of SHA-1 (20 bytes), then the hashed output is | than the output of SHA-1 (20 bytes), then the hashed output is | |||
| stirred back into the pool and a new hash performed to obtain the | stirred back into the pool and a new hash performed to obtain the | |||
| next 20 bytes. As bytes are removed from the pool, the estimate of | next 20 bytes. As bytes are removed from the pool, the estimate of | |||
| entropy is similarly decremented. | entropy is similarly decremented. | |||
| To ensure a reasonable random pool upon system startup, the standard | To ensure a reasonable random pool upon system startup, the standard | |||
| startup scripts (and shutdown scripts) save the pool to a disk file | startup scripts (and shutdown scripts) save the pool to a disk file | |||
| at shutdown and read this file at system startup. | at shutdown and read this file at system startup. | |||
| skipping to change at page 34, line 39 ¶ | skipping to change at page 35, line 39 ¶ | |||
| As entropy is added to the pool from events, more data becomes | As entropy is added to the pool from events, more data becomes | |||
| available via /dev/random. Random data obtained from such a | available via /dev/random. Random data obtained from such a | |||
| /dev/random device is suitable for key generation for long term keys, | /dev/random device is suitable for key generation for long term keys, | |||
| if enough random bits are in the pool or are added in a reasonable | if enough random bits are in the pool or are added in a reasonable | |||
| amount of time. | amount of time. | |||
| /dev/urandom works like /dev/random, however it provides data even | /dev/urandom works like /dev/random, however it provides data even | |||
| when the entropy estimate for the random pool drops to zero. This may | when the entropy estimate for the random pool drops to zero. This may | |||
| be adequate for session keys or for other key generation tasks where | be adequate for session keys or for other key generation tasks where | |||
| blocking while waiting for more random bits is not acceptable. The | blocking while waiting for more random bits is not acceptable. The | |||
| risk of continuing to take data even when the poolどヨs entropy estimate | risk of continuing to take data even when the pool's entropy estimate | |||
| is small in that past output may be computable from current output | is small in that past output may be computable from current output | |||
| provided an attacker can reverse SHA-1. Given that SHA-1 is designed | provided an attacker can reverse SHA-1. Given that SHA-1 is designed | |||
| to be non-invertible, this is a reasonable risk. | to be non-invertible, this is a reasonable risk. | |||
| To obtain random numbers under Linux, Solaris, or other UNIX systems | To obtain random numbers under Linux, Solaris, or other UNIX systems | |||
| equipped with code as described above, all an application needs to do | equipped with code as described above, all an application needs to do | |||
| is open either /dev/random or /dev/urandom and read the desired | is open either /dev/random or /dev/urandom and read the desired | |||
| number of bytes. | number of bytes. | |||
| (The Linux Random device was written by Theodore Tsどヨo. It was based | (The Linux Random device was written by Theodore Ts'o. It was based | |||
| loosely on the random number generator in PGP 2.X and PGP 3.0 (aka | loosely on the random number generator in PGP 2.X and PGP 3.0 (aka | |||
| PGP 5.0).) | PGP 5.0).) | |||
| 7.6 Windows CryptGenRandom | ||||
| Microsoft's recommendation to users of the widely deployed Windows | ||||
| operating system is generally to use the CryptGenRandom pseudo-random | ||||
| number generation call with the CryptAPI cryptographic service | ||||
| provider. This takes a handle to a cryptographic service provider | ||||
| library, a pointer to a buffer by which the caller can provide | ||||
| entropy and into which the generated pseudo-randomness is returned, | ||||
| and an indication of how many octets of randomness are desired. | ||||
| The Windows CryptAPI cryptographic service provider stores a seed | ||||
| state variable with every user. When CryptGenRandom is called, this | ||||
| is combined with any randomness provided in the call and various | ||||
| system and user data such as the process ID, thread ID, system clock, | ||||
| system time, system counter, memory status, free disk clusters, and | ||||
| hashed user environment block. This data is all feed to SHA-1 and the | ||||
| output used to seed an RC4 key stream. That key stream is used to | ||||
| produce the pseudo-random data requested and to update the user's | ||||
| seed state variable. | ||||
| Users of Windows ".NET" will probably find it easier to use the | ||||
| RNGCryptoServiceProvider.GetBytes method interface. | ||||
| For further information, see [WSC]. | ||||
| 8. Examples of Randomness Required | 8. Examples of Randomness Required | |||
| Below are two examples showing rough calculations of needed | Below are two examples showing rough calculations of needed | |||
| randomness for security. The first is for moderate security passwords | randomness for security. The first is for moderate security passwords | |||
| while the second assumes a need for a very high security | while the second assumes a need for a very high security | |||
| cryptographic key. | cryptographic key. | |||
| In addition [ORMAN] and [RSA BULL13] provide information on the | In addition [ORMAN] and [RSA BULL13] provide information on the | |||
| public key lengths that should be used for exchanging symmetric keys. | public key lengths that should be used for exchanging symmetric keys. | |||
| 8.1 Password Generation | 8.1 Password Generation | |||
| Assume that user passwords change once a year and it is desired that | Assume that user passwords change once a year and it is desired that | |||
| the probability that an adversary could guess the password for a | the probability that an adversary could guess the password for a | |||
| particular account be less than one in a thousand. Further assume | particular account be less than one in a thousand. Further assume | |||
| that sending a password to the system is the only way to try a | that sending a password to the system is the only way to try a | |||
| password. Then the crucial question is how often an adversary can try | password. Then the crucial question is how often an adversary can try | |||
| possibilities. Assume that delays have been introduced into a system | possibilities. Assume that delays have been introduced into a system | |||
| so that, at most, an adversary can make one password try every six | so that, at most, an adversary can make one password try every six | |||
| seconds. Thatどヨs 600 per hour or about 15,000 per day or about | seconds. That's 600 per hour or about 15,000 per day or about | |||
| 5,000,000 tries in a year. Assuming any sort of monitoring, it is | 5,000,000 tries in a year. Assuming any sort of monitoring, it is | |||
| unlikely someone could actually try continuously for a year. In fact, | unlikely someone could actually try continuously for a year. In fact, | |||
| even if log files are only checked monthly, 500,000 tries is more | even if log files are only checked monthly, 500,000 tries is more | |||
| plausible before the attack is noticed and steps taken to change | plausible before the attack is noticed and steps taken to change | |||
| passwords and make it harder to try more passwords. | passwords and make it harder to try more passwords. | |||
| To have a one in a thousand chance of guessing the password in | To have a one in a thousand chance of guessing the password in | |||
| 500,000 tries implies a universe of at least 500,000,000 passwords or | 500,000 tries implies a universe of at least 500,000,000 passwords or | |||
| about 2^29. Thus 29 bits of randomness are needed. This can probably | about 2^29. Thus 29 bits of randomness are needed. This can probably | |||
| be achieved using the US DoD recommended inputs for password | be achieved using the US DoD recommended inputs for password | |||
| skipping to change at page 36, line 49 ¶ | skipping to change at page 38, line 49 ¶ | |||
| could break the key in 2 weeks (on average they need try only half | could break the key in 2 weeks (on average they need try only half | |||
| the keys). | the keys). | |||
| These questions are considered in detail in "Minimal Key Lengths for | These questions are considered in detail in "Minimal Key Lengths for | |||
| Symmetric Ciphers to Provide Adequate Commercial Security: A Report | Symmetric Ciphers to Provide Adequate Commercial Security: A Report | |||
| by an Ad Hoc Group of Cryptographers and Computer Scientists" | by an Ad Hoc Group of Cryptographers and Computer Scientists" | |||
| [KeyStudy] which was sponsored by the Business Software Alliance. It | [KeyStudy] which was sponsored by the Business Software Alliance. It | |||
| concluded that a reasonable key length in 1995 for very high security | concluded that a reasonable key length in 1995 for very high security | |||
| is in the range of 75 to 90 bits and, since the cost of cryptography | is in the range of 75 to 90 bits and, since the cost of cryptography | |||
| does not vary much with they key size, recommends 90 bits. To update | does not vary much with they key size, recommends 90 bits. To update | |||
| these recommendations, just add 2/3 of a bit per year for Mooreどヨs law | these recommendations, just add 2/3 of a bit per year for Moore's law | |||
| [MOORE]. Thus, in the year 2004, this translates to a determination | [MOORE]. Thus, in the year 2004, this translates to a determination | |||
| that a reasonable key length is in the 81 to 96 bit range. In fact, | that a reasonable key length is in the 81 to 96 bit range. In fact, | |||
| today, it is increasingly common to use keys longer than 96 bits, | today, it is increasingly common to use keys longer than 96 bits, | |||
| such as 128-bit (or longer) keys with AES and keys with effective | such as 128-bit (or longer) keys with AES and keys with effective | |||
| lengths of 112-bits using triple-DES. | lengths of 112-bits using triple-DES. | |||
| 8.2.2 Meet in the Middle Attacks | 8.2.2 Meet in the Middle Attacks | |||
| If chosen or known plain text and the resulting encrypted text are | If chosen or known plain text and the resulting encrypted text are | |||
| skipping to change at page 37, line 41 ¶ | skipping to change at page 39, line 41 ¶ | |||
| amount of randomness in the very strong key to a minimum of 192 bits | amount of randomness in the very strong key to a minimum of 192 bits | |||
| (96*2) is required for the year 2004 based on the [KeyStudy] | (96*2) is required for the year 2004 based on the [KeyStudy] | |||
| analysis. | analysis. | |||
| This amount of randomness is well beyond the limit of that in the | This amount of randomness is well beyond the limit of that in the | |||
| inputs recommended by the US DoD for password generation and could | inputs recommended by the US DoD for password generation and could | |||
| require user typing timing, hardware random number generation, or | require user typing timing, hardware random number generation, or | |||
| other sources. | other sources. | |||
| The meet in the middle attack assumes that the cryptographic | The meet in the middle attack assumes that the cryptographic | |||
| algorithm can be decomposed in this way but we can not rule that out | algorithm can be decomposed in this way. Hopefully no modern | |||
| without a deep knowledge of the algorithm. Even if a basic algorithm | algorithm has this weakness but there may be cases where we are not | |||
| is not subject to a meet in the middle attack, an attempt to produce | sure of that or even of what algorithm a key will be used with. Even | |||
| a stronger algorithm by applying the basic algorithm twice (or two | if a basic algorithm is not subject to a meet in the middle attack, | |||
| different algorithms sequentially) with different keys may gain less | an attempt to produce a stronger algorithm by applying the basic | |||
| added security than would be expected. Such a composite algorithm | algorithm twice (or two different algorithms sequentially) with | |||
| would be subject to a meet in the middle attack. | different keys will gain less added security than would be expected. | |||
| Such a composite algorithm would be subject to a meet in the middle | ||||
| attack. | ||||
| Enormous resources may be required to mount a meet in the middle | Enormous resources may be required to mount a meet in the middle | |||
| attack but they are probably within the range of the national | attack but they are probably within the range of the national | |||
| security services of a major nation. Essentially all nations spy on | security services of a major nation. Essentially all nations spy on | |||
| other nations traffic. | other nations traffic. | |||
| 8.2.3 Other Considerations | 8.2.3 Other Considerations | |||
| [KeyStudy] also considers the possibilities of special purpose code | [KeyStudy] also considers the possibilities of special purpose code | |||
| breaking hardware and having an adequate safety margin. | breaking hardware and having an adequate safety margin. | |||
| skipping to change at page 41, line 20 ¶ | skipping to change at page 43, line 20 ¶ | |||
| 3. Addition of section 5.4 on Ring Oscillator randomness sources. | 3. Addition of section 5.4 on Ring Oscillator randomness sources. | |||
| 4. AES and the members of the SHA series producing more than 160 | 4. AES and the members of the SHA series producing more than 160 | |||
| bits have been added. Use of AES has been emphasized and the use | bits have been added. Use of AES has been emphasized and the use | |||
| of DES de-emphasized. | of DES de-emphasized. | |||
| 5. Addition of section 6.3.3 on entropy pool techniques. | 5. Addition of section 6.3.3 on entropy pool techniques. | |||
| 6. Addition of section 7.3 on the pseudo-random number generation | 6. Addition of section 7.3 on the pseudo-random number generation | |||
| techniques given in FIPS 186-2, 7.4 on those given in X9.82, and | techniques given in FIPS 186-2 (with Change Notice 1), 7.4 on | |||
| section 7.5 on the random number generation techniques of the | those given in X9.82, section 7.5 on the random number generation | |||
| /dev/random device in Linux and other UNIX systems. | techniques of the /dev/random device in Linux and other UNIX | |||
| systems, and section 7.6 on random number generation techniques | ||||
| in the Windows operating system. | ||||
| 7. Addition of references to the "Minimal Key Lengths for Symmetric | 7. Addition of references to the "Minimal Key Lengths for Symmetric | |||
| Ciphers to Provide Adequate Commercial Security" study published | Ciphers to Provide Adequate Commercial Security" study published | |||
| in January 1996 [KeyStudy]. | in January 1996 [KeyStudy]. | |||
| 8. Added caveats to using Diffie-Hellman as a mixing function. | 8. Added caveats to using Diffie-Hellman as a mixing function. | |||
| 9. Addition of references to the [TURBID] paper and system. | 9. Addition of references to the [TURBID] paper and system. | |||
| 10. Minor wording changes and reference updates. | 10. Addition of discussion of min-entropy and Renyi entropy and | |||
| references to the [LUBY] book. | ||||
| 11. Minor wording changes and reference updates. | ||||
| 14. Informative References | 14. Informative References | |||
| [AES] - "Specification of the Advanced Encryption Standard (AES)", | [AES] - "Specification of the Advanced Encryption Standard (AES)", | |||
| United States of America, US National Institute of Standards and | United States of America, US National Institute of Standards and | |||
| Technology, FIPS 197, November 2001. | Technology, FIPS 197, November 2001. | |||
| [ASYMMETRIC] - "Secure Communications and Asymmetric Cryptosystems", | [ASYMMETRIC] - "Secure Communications and Asymmetric Cryptosystems", | |||
| edited by Gustavus J. Simmons, AAAS Selected Symposium 69, Westview | edited by Gustavus J. Simmons, AAAS Selected Symposium 69, Westview | |||
| Press, Inc. | Press, Inc. | |||
| skipping to change at page 42, line 25 ¶ | skipping to change at page 44, line 25 ¶ | |||
| [BBS] - "A Simple Unpredictable Pseudo-Random Number Generator", SIAM | [BBS] - "A Simple Unpredictable Pseudo-Random Number Generator", SIAM | |||
| Journal on Computing, v. 15, n. 2, 1986, L. Blum, M. Blum, & M. Shub. | Journal on Computing, v. 15, n. 2, 1986, L. Blum, M. Blum, & M. Shub. | |||
| [BRILLINGER] - "Time Series: Data Analysis and Theory", Holden-Day, | [BRILLINGER] - "Time Series: Data Analysis and Theory", Holden-Day, | |||
| 1981, David Brillinger. | 1981, David Brillinger. | |||
| [CRC] - "C.R.C. Standard Mathematical Tables", Chemical Rubber | [CRC] - "C.R.C. Standard Mathematical Tables", Chemical Rubber | |||
| Publishing Company. | Publishing Company. | |||
| [DAVIS] - "Cryptographic Randomness from Air Turbulence in Disk | [DAVIS] - "Cryptographic Randomness from Air Turbulence in Disk | |||
| Drives", Advances in Cryptology - Crypto どヨ94, Springer-Verlag Lecture | Drives", Advances in Cryptology - Crypto '94, Springer-Verlag Lecture | |||
| Notes in Computer Science #839, 1984, Don Davis, Ross Ihaka, and | Notes in Computer Science #839, 1984, Don Davis, Ross Ihaka, and | |||
| Philip Fenstermacher. | Philip Fenstermacher. | |||
| [DES] - "Data Encryption Standard", US National Institute of | [DES] - "Data Encryption Standard", US National Institute of | |||
| Standards and Technology, FIPS 46-3, October 1999. | Standards and Technology, FIPS 46-3, October 1999. | |||
| - "Data Encryption Algorithm", American National Standards | - "Data Encryption Algorithm", American National Standards | |||
| Institute, ANSI X3.92-1981. | Institute, ANSI X3.92-1981. | |||
| (See also FIPS 112, Password Usage, which includes FORTRAN | (See also FIPS 112, Password Usage, which includes FORTRAN | |||
| code for performing DES.) | code for performing DES.) | |||
| skipping to change at page 42, line 50 ¶ | skipping to change at page 44, line 50 ¶ | |||
| Eastlake, March 1999. | Eastlake, March 1999. | |||
| [DoD] - "Password Management Guideline", United States of America, | [DoD] - "Password Management Guideline", United States of America, | |||
| Department of Defense, Computer Security Center, CSC-STD-002-85. | Department of Defense, Computer Security Center, CSC-STD-002-85. | |||
| (See also FIPS 112, Password Usage, which incorporates CSC-STD-002-85 | (See also FIPS 112, Password Usage, which incorporates CSC-STD-002-85 | |||
| as one of its appendices.) | as one of its appendices.) | |||
| [DSS] - "Digital Signature Standard (DSS)", US National Institute of | [DSS] - "Digital Signature Standard (DSS)", US National Institute of | |||
| Standards and Technology, FIPS 186-2, January 2000. | Standards and Technology, FIPS 186-2, January 2000. | |||
| [DSS CN1] - "Digital Signature Standard Change Notice 1", US National | ||||
| Institute of Standards and Technology, FIPS 186-2 Change Notice 1, 5 | ||||
| October 2001. | ||||
| [FERGUSON] - "Practical Cryptography", Niels Ferguson and Bruce | [FERGUSON] - "Practical Cryptography", Niels Ferguson and Bruce | |||
| Schneier, Wiley Publishing Inc., ISBN 047122894X, April 2003. | Schneier, Wiley Publishing Inc., ISBN 047122894X, April 2003. | |||
| [GIFFORD] - "Natural Random Number", MIT/LCS/TM-371, David K. | [GIFFORD] - "Natural Random Number", MIT/LCS/TM-371, David K. | |||
| Gifford, September 1988. | Gifford, September 1988. | |||
| [IEEE 802.11i] - "Amendment to Standard for Telecommunications and | [IEEE 802.11i] - "Amendment to Standard for Telecommunications and | |||
| Information Exchange Between Systems - LAN/MAN Specific Requirements | Information Exchange Between Systems - LAN/MAN Specific Requirements | |||
| - Part 11: Wireless Medium Access Control (MAC) and physical layer | - Part 11: Wireless Medium Access Control (MAC) and physical layer | |||
| (PHY) specifications: Medium Access Control (MAC) Security | (PHY) specifications: Medium Access Control (MAC) Security | |||
| Enhancements", The Institute for Electrical and Electronics | Enhancements", The Institute for Electrical and Electronics | |||
| Engineers, January 2004. | Engineers, January 2004. | |||
| [IPSEC] - RFC 2401, "Security Architecture for the Internet | [IPSEC] - RFC 2401, "Security Architecture for the Internet | |||
| Protocol", S. Kent, R. Atkinson, November 1998. | Protocol", S. Kent, R. Atkinson, November 1998. | |||
| [Jakobsson] - M. Jakobsson, E. Shriver, B. K. Hillyer, and A. Juels, | ||||
| "A practical secure random bit generator", Proceedings of the Fifth | ||||
| ACM Conference on Computer and Communications Security, 1998. See | ||||
| also http://citeseer.ist.psu.edu/article/jakobsson98practical.html. | ||||
| [KAUFMAN] - "Network Security: Private Communication in a Public | [KAUFMAN] - "Network Security: Private Communication in a Public | |||
| World", Charlie Kaufman, Radia Perlman, and Mike Speciner, Prentis | World", Charlie Kaufman, Radia Perlman, and Mike Speciner, Prentis | |||
| Hall PTR, ISBN 0-13-046019-2, 2nd Edition 2002. | Hall PTR, ISBN 0-13-046019-2, 2nd Edition 2002. | |||
| [KeyStudy] - "Minimal Key Lengths for Symmetric Ciphers to Provide | [KeyStudy] - "Minimal Key Lengths for Symmetric Ciphers to Provide | |||
| Adequate Commercial Security: A Report by an Ad Hoc Group of | Adequate Commercial Security: A Report by an Ad Hoc Group of | |||
| Cryptographers and Computer Scientists", M. Blaze, W. Diffie, R. | Cryptographers and Computer Scientists", M. Blaze, W. Diffie, R. | |||
| Rivest, B. Schneier, T. Shimomura, E. Thompson, and M. Weiner, | Rivest, B. Schneier, T. Shimomura, E. Thompson, and M. Weiner, | |||
| January 1996, <www.counterpane.com/keylength.html>. | January 1996, <www.counterpane.com/keylength.html>. | |||
| [KNUTH] - "The Art of Computer Programming", Volume 2: Seminumerical | [KNUTH] - "The Art of Computer Programming", Volume 2: Seminumerical | |||
| Algorithms, Chapter 3: Random Numbers. Addison Wesley Publishing | Algorithms, Chapter 3: Random Numbers, Donald E. Knuth, Addison | |||
| Company, 3rd Edition November 1997, Donald E. Knuth. | Wesley Publishing Company, 3rd Edition November 1997. | |||
| [KRAWCZYK] - "How to Predict Congruential Generators", Journal of | [KRAWCZYK] - "How to Predict Congruential Generators", H. Krawczyk, | |||
| Algorithms, V. 13, N. 4, December 1992, H. Krawczyk | Journal of Algorithms, V. 13, N. 4, December 1992. | |||
| [MAIL PEM] - RFCs 1421 through 1424: | [LUBY] - "Pseudorandomness and Cryptographic Applications", Michael | |||
| - RFC 1421, Privacy Enhancement for Internet Electronic Mail: | Luby, Princeton University Press, ISBN 0691025460, 8 January 1996. | |||
| Part I: Message Encryption and Authentication Procedures, 02/10/1993, | ||||
| J. Linn | [MAIL PEM 1] - RFC 1421, "Privacy Enhancement for Internet Electronic | |||
| - RFC 1422, Privacy Enhancement for Internet Electronic Mail: | Mail: Part I: Message Encryption and Authentication Procedures", J. | |||
| Part II: Certificate-Based Key Management, 02/10/1993, S. Kent | Linn, 02/10/1993. | |||
| - RFC 1423, Privacy Enhancement for Internet Electronic Mail: | [MAIL PEM 2] - RFC 1422, "Privacy Enhancement for Internet | |||
| Part III: Algorithms, Modes, and Identifiers, 02/10/1993, D. Balenson | Electronic Mail: Part II: Certificate-Based Key Management", S. Kent, | |||
| - RFC 1424, Privacy Enhancement for Internet Electronic Mail: | 02/10/1993. | |||
| Part IV: Key Certification and Related Services, 02/10/1993, B. | [MAIL PEM 3] - RFC 1423, "Privacy Enhancement for Internet | |||
| Kaliski | Electronic Mail: Part III: Algorithms, Modes, and Identifiers", D. | |||
| Balenson, 02/10/1993. | ||||
| [MAIL PEM 4] - RFC 1424, "Privacy Enhancement for Internet | ||||
| Electronic Mail: Part IV: Key Certification and Related Services", B. | ||||
| Kaliski, 02/10/1993. | ||||
| [MAIL PGP] | [MAIL PGP] | |||
| - RFC 2440, "OpenPGP Message Format", J. Callas, L. | - RFC 2440, "OpenPGP Message Format", J. Callas, L. | |||
| Donnerhacke, H. Finney, R. Thayer", November 1998. | Donnerhacke, H. Finney, R. Thayer", November 1998. | |||
| - RFC 3156, "MIME Security with OpenPGP" M. Elkins, D. Del | - RFC 3156, "MIME Security with OpenPGP" M. Elkins, D. Del | |||
| Torto, R. Levien, T. Roessler, August 2001. | Torto, R. Levien, T. Roessler, August 2001. | |||
| [MAIL S/MIME] - RFCs 2632 through 2634: | [MAIL S/MIME] - RFCs 2632 through 2634: | |||
| - RFC 2632, "S/MIME Version 3 Certificate Handling", B. | - RFC 2632, "S/MIME Version 3 Certificate Handling", B. | |||
| Ramsdell, Ed., June 1999. | Ramsdell, Ed., June 1999. | |||
| skipping to change at page 44, line 4 ¶ | skipping to change at page 46, line 19 ¶ | |||
| - RFC 2440, "OpenPGP Message Format", J. Callas, L. | - RFC 2440, "OpenPGP Message Format", J. Callas, L. | |||
| Donnerhacke, H. Finney, R. Thayer", November 1998. | Donnerhacke, H. Finney, R. Thayer", November 1998. | |||
| - RFC 3156, "MIME Security with OpenPGP" M. Elkins, D. Del | - RFC 3156, "MIME Security with OpenPGP" M. Elkins, D. Del | |||
| Torto, R. Levien, T. Roessler, August 2001. | Torto, R. Levien, T. Roessler, August 2001. | |||
| [MAIL S/MIME] - RFCs 2632 through 2634: | [MAIL S/MIME] - RFCs 2632 through 2634: | |||
| - RFC 2632, "S/MIME Version 3 Certificate Handling", B. | - RFC 2632, "S/MIME Version 3 Certificate Handling", B. | |||
| Ramsdell, Ed., June 1999. | Ramsdell, Ed., June 1999. | |||
| - RFC 2633, "S/MIME Version 3 Message Specification", B. | - RFC 2633, "S/MIME Version 3 Message Specification", B. | |||
| Ramsdell, Ed., June 1999. | Ramsdell, Ed., June 1999. | |||
| - RFC 2634, "Enhanced Security Services for S/MIME" P. | - RFC 2634, "Enhanced Security Services for S/MIME" P. | |||
| Hoffman, Ed., June 1999. | Hoffman, Ed., June 1999. | |||
| [MD4] - "The MD4 Message-Digest Algorithm", RFC1320, April 1992, R. | [MD4] - "The MD4 Message-Digest Algorithm", RFC1320, April 1992, R. | |||
| Rivest | Rivest | |||
| [MD5] - "The MD5 Message-Digest Algorithm", RFC1321, April 1992, R. | [MD5] - "The MD5 Message-Digest Algorithm", RFC1321, April 1992, R. | |||
| Rivest | Rivest | |||
| [MODES] - "DES Modes of Operation", US National Institute of | [MODES] - "DES Modes of Operation", US National Institute of | |||
| Standards and Technology, FIPS 81, December 1980. | Standards and Technology, FIPS 81, December 1980. | |||
| - "Data Encryption Algorithm - Modes of Operation", American | - "Data Encryption Algorithm - Modes of Operation", American | |||
| National Standards Institute, ANSI X3.106-1983. | National Standards Institute, ANSI X3.106-1983. | |||
| [MOORE] - Mooreどヨs Law: the exponential increase in the logic density | [MOORE] - Moore's Law: the exponential increase in the logic density | |||
| of silicon circuits. Originally formulated by Gordon Moore in 1964 as | of silicon circuits. Originally formulated by Gordon Moore in 1964 as | |||
| a doubling every year starting in 1962, in the late 1970s the rate | a doubling every year starting in 1962, in the late 1970s the rate | |||
| fell to a doubling every 18 months and has remained there through the | fell to a doubling every 18 months and has remained there through the | |||
| date of this document. See "The New Hackerどヨs Dictionary", Third | date of this document. See "The New Hacker's Dictionary", Third | |||
| Edition, MIT Press, ISBN 0-262-18178-9, Eric S. Raymond, 1996. | Edition, MIT Press, ISBN 0-262-18178-9, Eric S. Raymond, 1996. | |||
| [ORMAN] - "Determining Strengths For Public Keys Used For Exchanging | [ORMAN] - "Determining Strengths For Public Keys Used For Exchanging | |||
| Symmetric Keys", draft-orman-public-key-lengths-*.txt, Hilarie Orman, | Symmetric Keys", RFC 3766, Hilarie Orman, Paul Hoffman, April 2004. | |||
| Paul Hoffman, work in progress. | ||||
| [RFC 1750] - "Randomness Requirements for Security", D. Eastlake, S. | [RFC 1750] - "Randomness Requirements for Security", D. Eastlake, S. | |||
| Crocker, J. Schiller, December 1994. | Crocker, J. Schiller, December 1994. | |||
| [RSA BULL1] - "Suggestions for Random Number Generation in Software", | [RSA BULL1] - "Suggestions for Random Number Generation in Software", | |||
| RSA Laboratories Bulletin #1, January 1996. | RSA Laboratories Bulletin #1, January 1996. | |||
| [RSA BULL13] - "A Cost-Based Security Analysis of Symmetric and | [RSA BULL13] - "A Cost-Based Security Analysis of Symmetric and | |||
| Asymmetric Key Lengths", RSA Laboratories Bulletin #13, Robert | Asymmetric Key Lengths", RSA Laboratories Bulletin #13, Robert | |||
| Silverman, April 2000 (revised November 2001). | Silverman, April 2000 (revised November 2001). | |||
| [SBOX1] - "Practical s-box design", S. Mister, C. Adams, Selected | [SBOX1] - "Practical s-box design", S. Mister, C. Adams, Selected | |||
| Areas in Cryptography, 1996. | Areas in Cryptography, 1996. | |||
| [SBOX2] - "Perfect Non-linear S-boxes", K. Nyberg, Advances in | [SBOX2] - "Perfect Non-linear S-boxes", K. Nyberg, Advances in | |||
| Cryptography - Eurocrypt どヨ91 Proceedings, Springer-Verland, 1991. | Cryptography - Eurocrypt '91 Proceedings, Springer-Verland, 1991. | |||
| [SCHNEIER] - "Applied Cryptography: Protocols, Algorithms, and Source | [SCHNEIER] - "Applied Cryptography: Protocols, Algorithms, and Source | |||
| Code in C", 2nd Edition, John Wiley & Sons, 1996, Bruce Schneier. | Code in C", Bruce Schneier, 2nd Edition, John Wiley & Sons, 1996. | |||
| [SHANNON] - "The Mathematical Theory of Communication", University of | [SHANNON] - "The Mathematical Theory of Communication", University of | |||
| Illinois Press, 1963, Claude E. Shannon. (originally from: Bell | Illinois Press, 1963, Claude E. Shannon. (originally from: Bell | |||
| System Technical Journal, July and October 1948) | System Technical Journal, July and October 1948) | |||
| [SHIFT1] - "Shift Register Sequences", Aegean Park Press, Revised | [SHIFT1] - "Shift Register Sequences", Solomon W. Golomb, Aegean Park | |||
| Edition 1982, Solomon W. Golomb. | Press, Revised Edition 1982. | |||
| [SHIFT2] - "Cryptanalysis of Shift-Register Generated Stream Cypher | [SHIFT2] - "Cryptanalysis of Shift-Register Generated Stream Cypher | |||
| Systems", Aegean Park Press, 1984, Wayne G. Barker. | Systems", Wayne G. Barker, Aegean Park Press, 1984. | |||
| [SHA-1] - "Secure Hash Standard (SHA-1)", US National Institute of | [SHA] - "Secure Hash Standard", US National Institute of Science and | |||
| Science and Technology, FIPS 180-1, April 1993. | Technology, FIPS 180-2, 1 August 2002. | |||
| - RFC 3174, "US Secure Hash Algorithm 1 (SHA1)", D. Eastlake, | ||||
| P. Jones, September 2001. | ||||
| [SHA-2] - "Secure Hash Standard", Draft (SHA-2156/384/512), US | [SHA RFC] - RFC 3174, "US Secure Hash Algorithm 1 (SHA1)", D. | |||
| National Institute of Science and Technology, FIPS 180-2, not yet | Eastlake, P. Jones, September 2001. | |||
| issued. | ||||
| [SSH] - draft-ietf-secsh-*, work in progress. | [SSH] - draft-ietf-secsh-*, work in progress. | |||
| [STERN] - "Secret Linear Congruential Generators are not | [STERN] - "Secret Linear Congruential Generators are not | |||
| Cryptographically Secure", Proceedings of IEEE STOC, 1987, J. Stern. | Cryptographically Secure", J. Stern, Proceedings of IEEE STOC, 1987. | |||
| [TLS] - RFC 2246, "The TLS Protocol Version 1.0", T. Dierks, C. | [TLS] - RFC 2246, "The TLS Protocol Version 1.0", T. Dierks, C. | |||
| Allen, January 1999. | Allen, January 1999. | |||
| [TURBID] - "High Entropy Symbol Generator", John S. Denker, | [TURBID] - "High Entropy Symbol Generator", John S. Denker, | |||
| <http://www.av8n.com/turbid/paper/turbid.htm>, 2003. | <http://www.av8n.com/turbid/paper/turbid.htm>, 2003. | |||
| [USENET] - RFC 977, "Network News Transfer Protocol", B. Kantor, P. | [USENET] - RFC 977, "Network News Transfer Protocol", B. Kantor, P. | |||
| Lapsley, February 1986. | Lapsley, February 1986. | |||
| - RFC 2980, "Common NNTP Extensions", S. Barber, October | - RFC 2980, "Common NNTP Extensions", S. Barber, October | |||
| 2000. | 2000. | |||
| [VON NEUMANN] - "Various techniques used in connection with random | [VON NEUMANN] - "Various techniques used in connection with random | |||
| digits", von Neumannどヨs Collected Works, Vol. 5, Pergamon Press, 1963, | digits", von Neumann's Collected Works, Vol. 5, Pergamon Press, 1963, | |||
| J. von Neumann. | J. von Neumann. | |||
| [WSC] - "Writing Secure Code, Second Edition", Michael Howard, David. | ||||
| C. LeBlanc, Microsoft Press, ISBN 0735617228, December 2002. | ||||
| [X9.17] - "American National Standard for Financial Institution Key | [X9.17] - "American National Standard for Financial Institution Key | |||
| Management (Wholesale)", American Bankers Association, 1985. | Management (Wholesale)", American Bankers Association, 1985. | |||
| [X9.82] - "Random Number Generation", ANSI X9F1, work in progress. | [X9.82] - "Random Number Generation", American National Standards | |||
| Institute, ANSI X9F1, work in progress. | ||||
| Authors Addresses | Author's Addresses | |||
| Donald E. Eastlake 3rd | Donald E. Eastlake 3rd | |||
| Motorola Laboratories | Motorola Laboratories | |||
| 155 Beaver Street | 155 Beaver Street | |||
| Milford, MA 01757 USA | Milford, MA 01757 USA | |||
| Telephone: +1 508-786-7554 (w) | Telephone: +1 508-786-7554 (w) | |||
| +1 508-634-2066 (h) | +1 508-634-2066 (h) | |||
| EMail: Donald.Eastlake@motorola.com | EMail: Donald.Eastlake@motorola.com | |||
| skipping to change at page 46, line 30 ¶ | skipping to change at page 48, line 30 ¶ | |||
| Telephone: +1 617-253-0161 | Telephone: +1 617-253-0161 | |||
| E-mail: jis@mit.edu | E-mail: jis@mit.edu | |||
| Steve Crocker | Steve Crocker | |||
| EMail: steve@stevecrocker.com | EMail: steve@stevecrocker.com | |||
| File Name and Expiration | File Name and Expiration | |||
| This is file draft-eastlake-randomness2-08.txt. | This is file draft-eastlake-randomness2-09.txt. | |||
| It expires February 2005. | It expires April 2005. | |||
| End of changes. 101 change blocks. | ||||
| 246 lines changed or deleted | 367 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||