< draft-eastlake-randomness2-00.txt   draft-eastlake-randomness2-01.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 Januray 2001 July 2000 Expires May 2001 November 2000
Randomness Requirements for Security Randomness Requirements for Security
---------- ------------ --- -------- ---------- ------------ --- --------
<draft-eastlake-randomness2-00.txt> <draft-eastlake-randomness2-01.txt>
Status of This Document Status of This Document
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 This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
skipping to change at page 2, line 30 skipping to change at page 2, line 30
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 on many systems can be used for this purpose. It provides
suggestions to ameliorate the problem when a hardware solution is not suggestions to ameliorate the problem when a hardware solution is not
available. And it gives examples of how large such quantities need available. And it gives examples of how large such quantities need
to be for some particular applications. to be for some particular applications.
Acknowledgements Acknowledgements
Special thanks to the authors of "Minimal Key Lengths for Symmetric Special thanks to
Ciphers to Provide Adequate Commercial Security" which is (1) The authors of "Minimal Key Lengths for Symmetric Ciphers to
incorporated as Appendix A. Provide Adequate Commercial Security" which is incorporated as
Appendix A.
(2) Peter Gutmann who has permitted the incorporation into this
replacement for RFC 1750 of materila from is paper "Software
Generation of Practially Strong Random Numbers".
The following other persons (in alphabetic order) contributed to this
document:
(tbd)
The following persons (in alpahbetic order) contributed to RFC 1750, The following persons (in alpahbetic order) contributed to RFC 1750,
the predeceasor of this document: the predeceasor 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, Doug Tygar. Haller, Richard Pitkin, Tim Redmond, Doug Tygar.
Status of This Document....................................1 Status of This Document....................................1
skipping to change at page 3, line 47 skipping to change at page 3, line 47
6.1.1 A Trivial Mixing Function...........................18 6.1.1 A Trivial Mixing Function...........................18
6.1.2 Stronger Mixing Functions...........................19 6.1.2 Stronger Mixing Functions...........................19
6.1.3 Diff-Hellman as a Mixing Function...................20 6.1.3 Diff-Hellman as a Mixing Function...................20
6.1.4 Using a Mixing Function to Stretch Random Bits......21 6.1.4 Using a Mixing Function to Stretch Random Bits......21
6.1.5 Other Factors in Choosing a Mixing Function.........21 6.1.5 Other Factors in Choosing a Mixing Function.........21
6.2 Non-Hardware Sources of Randomness....................22 6.2 Non-Hardware Sources of Randomness....................22
6.3 Cryptographically Strong Sequences....................23 6.3 Cryptographically Strong Sequences....................23
6.3.1 Traditional Strong Sequences........................23 6.3.1 Traditional Strong Sequences........................23
6.3.2 The Blum Blum Shub Sequence Generator...............24 6.3.2 The Blum Blum Shub Sequence Generator...............24
7. Key Generation Standards...............................26 7. Key Generation Standards and Examples..................26
7.1 US DoD Recommendations for Password Generation........26 7.1 US DoD Recommendations for Password Generation........26
7.2 X9.17 Key Generation..................................26 7.2 X9.17 Key Generation..................................26
7.3 The /dev/random Device under Linux....................27
8. Examples of Randomness Required........................28 7.4 additional example....................................28
8.1 Password Generation..................................28 8. Examples of Randomness Required........................29
8.2 A Very High Security Cryptographic Key................29 8.1 Password Generation..................................29
8.2.1 Effort per Key Trial................................29 8.2 A Very High Security Cryptographic Key................30
8.2.2 Meet in the Middle Attacks..........................29 8.2.1 Effort per Key Trial................................30
8.2.3 Other Considerations................................30 8.2.2 Meet in the Middle Attacks..........................30
9. Conclusion.............................................32 9. Conclusion.............................................32
10. Security Considerations...............................32 10. Security Considerations...............................32
Appendix: Minimal Secure Key Lengths Study................33 Appendix: Minimal Secure Key Lengths Study................33
Appendix: Abstract........................................33 A.0 Abstract..............................................33
A.1. Encryption Plays an Essential Role in Protecting.....34 A.1. Encryption Plays an Essential Role in Protecting.....34
A.1.1 There is a need for information security............34 A.1.1 There is a need for information security............34
A.1.2 Encryption to protect confidentiality...............35 A.1.2 Encryption to protect confidentiality...............35
A.1.3 There are a variety of attackers....................36 A.1.3 There are a variety of attackers....................36
A.1.4 Strong encryption is not expensive..................37 A.1.4 Strong encryption is not expensive..................37
A.2. Brute-Forece is becoming easier......................37 A.2. Brute-Forece is becoming easier......................37
A.3. 40-Bit Key Lengths Offer Virtually No Protection.....39 A.3. 40-Bit Key Lengths Offer Virtually No Protection.....39
A.4. Even DES with 56-Bit Keys Is Increasingly Inadequate.40 A.4. Even DES with 56-Bit Keys Is Increasingly Inadequate.40
A.4.1 DES is no panacea today.............................40 A.4.1 DES is no panacea today.............................40
A.4.2 There are smarter avenues of attack than brute force41 A.4.2 There are smarter avenues of attack than brute force41
A.4.3 Other algorithms are similar........................41 A.4.3 Other algorithms are similar........................41
A.5. Appropriate Key Lengths for the Future --- A Proposal42 A.5. Appropriate Key Lengths for the Future --- A Proposal42
Appendix: About the Authors...............................44 A.6 About the Authors.....................................44
Appendix: Acknowledgement.................................45 A.7 Acknowledgement.......................................45
References................................................46 References................................................46
Authors Addresses.........................................49 Authors Addresses.........................................49
File Name and Expiration..................................49 File Name and Expiration..................................49
1. Introduction 1. Introduction
[Other than the addition of Appendix A, the changes in this version Software cryptography has come into wider use and in continuing
from RFC 1750 are relatively minor. Comments and suggestions are spread, although there is a long way to go until it becomes
solicited.] pervasive. Systems like IPSEC, TLS, S/MIME, PGP, DNSSEC, Kerberos,
etc. are maturing and becoming a part of the network landscape
Software cryptography is coming into wider use. Systems like IPSEC, [DNSSEC, IPSEC, MAIL*, TLS]. By comparison, when the previous
TLS, S/MIME, PGP, DNSSEC, Kerberos, etc. are maturing and becoming a version of this document [RFC 1750] was issued in 1994, about the
part of the network landscape [DNSSEC, IPSEC, MAIL*, TLS]. By only cryptographic security specification in the IETF was the Privacy
comparison, when the previous version of this document [RFC 1750] was Enhanced Mail protocol [MAIL PEM].
issued in 1994, about the only cryptographic security specification
in the IETF was the Privacy 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.
For the present, the lack of generally available facilities for For the present, the lack of generally available facilities for
generating such unpredictable numbers is an open wound in the design generating such unpredictable numbers is an open wound in the design
of cryptographic software. For the software developer who wants to of cryptographic software. For the software developer who wants to
build a key or password generation procedure that runs on a wide build a key or password generation procedure that runs on a wide
skipping to change at page 26, line 5 skipping to change at page 26, line 5
i i
( ( 2 )(Mod (( p - 1 ) * ( q - 1 )) ) ) ( ( 2 )(Mod (( p - 1 ) * ( q - 1 )) ) )
s = ( s )(Mod n) s = ( s )(Mod n)
i 0 i 0
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.
7. Key Generation Standards 7. Key Generation Standards and Examples
Several public standards are now in place for the generation of keys. Several public standards and widely deplyed examples are now in place
Two of these are described below. Both use DES but any equally for the generation of keys without special hardware. Two standards
strong or stronger mixing function could be substituted. are described below. Both use DES but any equally strong or stronger
mixing function could be substituted. Then a few widely deployed
examples 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 [DES MODES] as Encryption Standard [DES] in Output Feedback Mode [DES MODES] as
follows: follows:
use an initialization vector determined from use an initialization vector determined from
the system clock, the system clock,
skipping to change at page 28, line 5 skipping to change at page 27, line 19
g = DES ( k, DES ( k, t ) .xor. s ) g = DES ( k, DES ( k, t ) .xor. s )
n n n n
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.
8. Examples of Randomness Required 7.3 The /dev/random Device under Linux
[This section is expected to be modified and to have references to The Linux operating system provides a Kernel resident random number
appendix A added.] generator. This generator makes use of events captured by the Kernel
during normal system operation.
The generator consists of a random pool of bytes, by default 512
bytes (represented as 128, 4 byte integers). When an event occurs,
such as a disk drive interrupt, the time of the event is xored into
the pool and the pool is stirred via a primitive polynomial of degree
128. The pool itself is treated as a ring buffer, with new data
being xored (after stirring with the polynomial) across the entire
pool.
Each call that adds entropy to the pool estimates the amount of
likely true entropy the input contains. The pool itself contains a
accumulator that estimates the total over all entropy of the pool.
Input events come from several sources:
1. Keyboard interrupts. The time of the interrupt as well as the scan
code are added to the pool. This in effect adds entropy from the
human operator by measuring inter-keystroke arrival times.
2. Disk completion and other interrupts. A system being used by a
person will likely have a hard to predict pattern of disk
accesses.
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]
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
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
entropy is similarly decremented.
To ensure a reasonable random pool upon system startup, the standard
Linux startup scripts (and shutdown scripts) save the pool to a disk
file at shutdown and read this file at system startup.
There are two user exported interfaces. /dev/random returns bytes
from the pool, but blocks when the estimated entropy drops to zero.
As entropy is added to the pool from events, more data becomes
available via /dev/random. Random data obtained /dev/random is
suitable for key generation for long term keys.
/dev/urandom works like /dev/random, however it provides data even
when the entropy estimate for the random pool drops to zero. This
should be fine for session keys. The risk of continuing to take data
even when the pools entropy estimate is small is that past output may
be computable from current output provided an attacker can reverse
SHA-1. Given that SHA-1 should not be invertible, this is a
reasonable risk.
To obtain random numbers under Linux, all an application needs to do
is open either /dev/random or /dev/urandom and read the desired
number of bytes.
The Linux Random device was written by Theodore Ts'o. It is based
loosely on the random number generator in PGP 2.X and PGP 3.0 (aka
PGP 5.0).
7.4 additional example
(tba)
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 randomness for security. The first is for moderate security
passwords while the second assumes a need for a very high security passwords while the second assumes a need for a very high security
cryptographic key. cryptographic key.
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
skipping to change at page 29, line 18 skipping to change at page 30, line 17
Assume that a very high security key is needed for symmetric Assume that a very high security key is needed for symmetric
encryption / decryption between two parties. Assume an adversary can encryption / decryption between two parties. Assume an adversary can
observe communications and knows the algorithm being used. Within observe communications and knows the algorithm being used. Within
the field of random possibilities, the adversary can try key values the field of random possibilities, the adversary can try key values
in hopes of finding the one in use. Assume further that brute force in hopes of finding the one in use. Assume further that brute force
trial of keys is the best the adversary can do. trial of keys is the best the adversary can do.
8.2.1 Effort per Key Trial 8.2.1 Effort per Key Trial
How much effort will it take to try each key? For very high security How much effort will it take to try each key? For very high security
applications it is best to assume a low value of effort. Even if it applications it is best to assume a low value of effort. This
would clearly take tens of thousands of computer cycles or more to questions is considered in detail in Appendix A. It concludes that a
try a single key, there may be some pattern that enables huge blocks reasonable key length in 1995 for very high security is in the range
of key values to be tested with much less effort per key. Thus it is of 75 to 90 bits and, since the cost of cryptography does not very
probably best to assume no more than a couple hundred cycles per key. much with they key size, recommends 90 bits. To update these
(There is no clear lower bound on this as computers operate in recommendations, just add 2/3 of a bit per year for Moore's law
parallel on a number of bits and a poor encryption algorithm could [MOORE]. Thus, in the year 2001, this translates to a determination
allow many keys or even groups of keys to be tested in parallel. that a reasonable key length is in 78 to 93 bit range.
However, we need to assume some value and can hope that a reasonably
strong algorithm has been chosen for our hypothetical high security
task.)
If the adversary can command a highly parallel processor or a large
network of work stations, 2*10^10 cycles per second is probably a
minimum assumption for availability today. Looking forward just a
couple years, there should be at least an order of magnitude
improvement. Thus assuming 10^9 keys could be checked per second or
3.6*10^11 per hour or 6*10^13 per week or 2.4*10^14 per month is
reasonable. This implies a need for a minimum of 51 bits of
randomness in keys to be sure they cannot be found in a month. Even
then it is possible that, a few years from now, a highly determined
and resourceful adversary could break the key in 2 weeks (on average
they need try only half the keys).
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
available, a "meet in the middle" attack is possible if the structure available, a "meet in the middle" attack is possible if the structure
of the encryption algorithm allows it. (In a known plain text of the encryption algorithm allows it. (In a known plain text
attack, the adversary knows all or part of the messages being attack, the adversary knows all or part of the messages being
encrypted, possibly some standard header or trailer fields. In a encrypted, possibly some standard header or trailer fields. In a
chosen plain text attack, the adversary can force some chosen plain chosen plain text attack, the adversary can force some chosen plain
text to be encrypted, possibly by "leaking" an exciting text that text to be encrypted, possibly by "leaking" an exciting text that
skipping to change at page 30, line 18 skipping to change at page 30, line 46
An oversimplified explanation of the meet in the middle attack is as An oversimplified explanation of the meet in the middle attack is as
follows: the adversary can half-encrypt the known or chosen plain follows: the adversary can half-encrypt the known or chosen plain
text with all possible first half-keys, sort the output, then half- text with all possible first half-keys, sort the output, then half-
decrypt the encoded text with all the second half-keys. If a match decrypt the encoded text with all the second half-keys. If a match
is found, the full key can be assembled from the halves and used to is found, the full key can be assembled from the halves and used to
decrypt other parts of the message or other messages. At its best, decrypt other parts of the message or other messages. At its best,
this type of attack can halve the exponent of the work required by this type of attack can halve the exponent of the work required by
the adversary while adding a large but roughly constant factor of the adversary while adding a large but roughly constant factor of
effort. To be assured of safety against this, a doubling of the effort. To be assured of safety against this, a doubling of the
amount of randomness in the key to a minimum of 102 bits is required. amount of randomness in a very strong key to a minimum of 176 bits is
required for the year 2001 based on the Appendix A analysis.
This amount of randomness is beyond the limit of that in the inputs
recommended by the US DoD for password generation and could require
user typing timing, hardware random number generation, or 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 but we can not rule that out
without a deep knowledge of the algorithm. Even if a basic algorithm without a thorough knowledge of the algorithm. Even if a basic
is not subject to a meet in the middle attack, an attempt to produce algorithm is not subject to a meet in the middle attack, an attempt
a stronger algorithm by applying the basic algorithm twice (or two to produce a stronger algorithm by applying the basic algorithm twice
different algorithms sequentially) with different keys may gain less (or two different algorithms sequentially) with different keys may
added security than would be expected. Such a composite algorithm gain less added security than would be expected. Such a composite
would be subject to a meet in the middle attack. 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 government traffic and several nations are believed to other nations government traffic and several nations are believed to
spy on commercial traffic for economic advantage. spy on commercial traffic for economic advantage.
8.2.3 Other Considerations
Since we have not even considered the possibilities of special
purpose code breaking hardware or just how much of a safety margin we
want beyond our assumptions above, probably a good minimum for a very
high security cryptographic key is 128 bits of randomness which
implies a minimum key length of 128 bits. If the two parties agree
on a key by Diffie-Hellman exchange [D-H], then in principle only
half of this randomness would have to be supplied by each party.
However, there is probably some correlation between their random
inputs so it is probably best to assume that each party needs to
provide at least 96 bits worth of randomness for very high security
if Diffie-Hellman is used.
This amount of randomness is beyond the limit of that in the inputs
recommended by the US DoD for password generation and could require
user typing timing, hardware random number generation, or other
sources.
It should be noted that key length calculations such at those above It should be noted that key length calculations such at those above
are controversial and depend on various assumptions about the are controversial and depend on various assumptions about the
cryptographic algorithms in use. In some cases, a professional with cryptographic algorithms in use. In some cases, a professional with
a deep knowledge of code breaking techniques and of the strength of a deep knowledge of code breaking techniques and of the strength of
the algorithm in use could be satisfied with less than half of the the algorithm in use could be satisfied with less than half of the
key size derived above. 176 bit key size derived above.
9. Conclusion 9. Conclusion
Generation of unguessable "random" secret quantities for security use Generation of unguessable "random" secret quantities for security use
is an essential but difficult task. is an essential but difficult task.
We have shown that hardware techniques to produce such randomness We have shown that hardware techniques to produce such randomness
would be relatively simple. In particular, the volume and quality would be relatively simple. In particular, the volume and quality
would not need to be high and existing computer hardware, such as would not need to be high and existing computer hardware, such as
disk drives, can be used. Computational techniques are available to disk drives, can be used.
process low quality random quantities from multiple sources or a
larger quantity of such low quality input from one source and produce Computational techniques are available to process low quality random
a smaller quantity of higher quality, less predictable key material. quantities from multiple sources or a larger quantity of such low
In the absence of hardware sources of randomness, a variety of user quality input from one source and produce a smaller quantity of
and software sources can frequently be used instead with care; higher quality, less predictable key material. In the absence of
however, most modern systems already have hardware, such as disk hardware sources of randomness, a variety of user and software
drives or audio input, that could be used to produce high quality sources can frequently be used instead with care; however, most
randomness. modern systems already have hardware, such as disk drives or audio
input, that could be used to produce high quality randomness.
Once a sufficient quantity of high quality seed key material (a few Once a sufficient quantity of high quality seed key material (a few
hundred bits) is available, strong computational techniques are hundred bits) is available, strong computational techniques are
available to produce cryptographically strong sequences of available to produce cryptographically strong sequences of
unpredicatable quantities from this seed material. unpredicatable quantities from this seed material.
10. Security Considerations 10. Security Considerations
The entirety of this document concerns techniques and recommendations The entirety of this document concerns techniques and recommendations
for generating unguessable "random" quantities for use as passwords, for generating unguessable "random" quantities for use as passwords,
skipping to change at page 33, line 23 skipping to change at page 33, line 23
Matt Blaze, AT&T Research, mab@research.att.com Matt Blaze, AT&T Research, mab@research.att.com
Whitfield Diffie, Sun Microsystems, diffie@eng.sun.com Whitfield Diffie, Sun Microsystems, diffie@eng.sun.com
Ronald L. Rivest, MIT LCS, rivest@lcs.mit.edu Ronald L. Rivest, MIT LCS, rivest@lcs.mit.edu
Bruce Schneier, Counterpane Systems, schneier@counterpane.com Bruce Schneier, Counterpane Systems, schneier@counterpane.com
Tsutomu Shimomura, San Diego Supercomputer Center, tsutomu@sdsc.edu Tsutomu Shimomura, San Diego Supercomputer Center, tsutomu@sdsc.edu
Eric Thompson Access Data, Inc., eric@accessdata.com Eric Thompson Access Data, Inc., eric@accessdata.com
Michael Wiener, Bell Northern Research, wiener@bnr.ca Michael Wiener, Bell Northern Research, wiener@bnr.ca
January 1996 January 1996
Appendix: Abstract A.0 Abstract
Encryption plays an essential role in protecting the privacy of Encryption plays an essential role in protecting the privacy of
electronic information against threats from a variety of potential electronic information against threats from a variety of potential
attackers. In so doing, modern cryptography employs a combination of attackers. In so doing, modern cryptography employs a combination of
_conventional_ or _symmetric_ cryptographic systems for encrypting _conventional_ or _symmetric_ cryptographic systems for encrypting
data and _public key_ or _asymmetric_ systems for managing the _keys_ data and _public key_ or _asymmetric_ systems for managing the _keys_
used by the symmetric systems. Assessing the strength required of used by the symmetric systems. Assessing the strength required of
the symmetric cryptographic systems is therefore an essential step in the symmetric cryptographic systems is therefore an essential step in
employing cryptography for computer and communication security. employing cryptography for computer and communication security.
skipping to change at page 44, line 14 skipping to change at page 44, line 14
$10M FPGA .7 seconds 13 hours 70 $10M FPGA .7 seconds 13 hours 70
or ($0.08) ($5,000) or ($0.08) ($5,000)
ASIC .005 seconds 6 minutes ASIC .005 seconds 6 minutes
($0.001) ($38) ($0.001) ($38)
Intellegence Agency Intellegence Agency
$300M ASIC .0002 seconds 12 seconds 75 $300M ASIC .0002 seconds 12 seconds 75
($0.001) ($38) ($0.001) ($38)
Appendix: About the Authors A.6 About the Authors
*Matt Blaze* is a senior research scientist at AT&T Research in the *Matt Blaze* is a senior research scientist at AT&T Research in the
area of computer security and cryptography. Recently Blaze area of computer security and cryptography. Recently Blaze
demonstrated weaknesses in the U.S. government's `Clipper Chip' key demonstrated weaknesses in the U.S. government's `Clipper Chip' key
escrow encryption system. His current interests include large-scale escrow encryption system. His current interests include large-scale
trust management and the applications of smartcards. trust management and the applications of smartcards.
*Whitfield Diffie* is a distinguished Engineer at Sun Microsystems *Whitfield Diffie* is a distinguished Engineer at Sun Microsystems
specializing in security. In 1976 Diffie and Martin Hellman created specializing in security. In 1976 Diffie and Martin Hellman created
public key cryptography, which solved the problem of sending coded public key cryptography, which solved the problem of sending coded
skipping to change at page 45, line 13 skipping to change at page 45, line 13
brute force as well as `smarter' attacks. Regular clients include brute force as well as `smarter' attacks. Regular clients include
the FBI and other law enforcement agencies as well as corporations. the FBI and other law enforcement agencies as well as corporations.
*Michael Wiener* is a cryptographic advisor at Bell-Northern Research *Michael Wiener* is a cryptographic advisor at Bell-Northern Research
where he focuses on cryptanalysis, security architectures, and where he focuses on cryptanalysis, security architectures, and
public-key infrastructures. His influential 1993 paper, Efficient public-key infrastructures. His influential 1993 paper, Efficient
DES Key Search, describes in detail how to construct a machine to DES Key Search, describes in detail how to construct a machine to
brute force crack DES coded information (and provides cost estimates brute force crack DES coded information (and provides cost estimates
as well). as well).
Appendix: Acknowledgement A.7 Acknowledgement
The authors would like to thank the Business Software Alliance, The [Appendix] authors would like to thank the Business Software
which provided support for a one-day meeting, held in Chicago on 20 Alliance, which provided support for a one-day meeting, held in
November 1995. Chicago on 20 November 1995.
References References
[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.
[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.
skipping to change at page 47, line 44 skipping to change at page 47, line 44
Donnerhacke, H. Finney, R. Thayer", November 1998 Donnerhacke, H. Finney, R. Thayer", November 1998
[MAIL S/MIME] - RFC 2633, "S/MIME Version 3 Message Specification", [MAIL S/MIME] - RFC 2633, "S/MIME Version 3 Message Specification",
B. Ramsdell, Ed., June 1999. B. Ramsdell, 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
[MOORE] -
[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.
[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", Aegean Park Press, Revised
Edition 1982, Solomon W. Golomb. Edition 1982, Solomon W. Golomb.
skipping to change at page 49, line 9 skipping to change at page 49, line 9
Allen, January 1999. Allen, January 1999.
[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.
Authors Addresses Authors Addresses
Donald E. Eastlake 3rd Donald E. Eastlake 3rd
Motorola Motorola
140 Forest Avenue 155 Beaver Street
Hudson, MA 01749 USA Milford, MA 01757 USA
Telephone: +1 508-261-5434 (w) Telephone: +1 508-261-5434 (w)
+1 978-562-2827 (h) +1 508-634-2066 (h)
FAX: +1 508-261-4447 (w) FAX: +1 508-261-4447 (w)
EMail: Donald.Eastlake@motorola.com EMail: Donald.Eastlake@motorola.com
Jeffrey I. Schiller Jeffrey I. Schiller
MIT Room E40-311 MIT Room E40-311
77 Massachusetts Avenue 77 Massachusetts Avenue
Cambridge, MA 02139-4307 USA Cambridge, MA 02139-4307 USA
Telephone: +1 617-253-0161 Telephone: +1 617-253-0161
E-mail: jis@mit.edu E-mail: jis@mit.edu
skipping to change at page 49, line 37 skipping to change at page 49, line 37
Suite 100 Suite 100
1319 Shepard Drive 1319 Shepard Drive
Sterling, VA 20164 USA Sterling, VA 20164 USA
Telephone: +1 703-433-0808 x206 Telephone: +1 703-433-0808 x206
FAX: +1 202-478-0458 FAX: +1 202-478-0458
EMail: steve@stevecrocker.com EMail: steve@stevecrocker.com
File Name and Expiration File Name and Expiration
This is file draft-eastlake-randomness2-00.txt. This is file draft-eastlake-randomness2-01.txt.
It expires January 2001. It expires May 2001.
 End of changes. 28 change blocks. 
102 lines changed or deleted 152 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/