< draft-eastlake-randomness2-03.txt		draft-eastlake-randomness2-04.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 January 2003 July 2002		Expires February 2004 January 2003
	Randomness Requirements for Security		Randomness Requirements for Security
	---------- ------------ --- --------		---------- ------------ --- --------
	<draft-eastlake-randomness2-03.txt>		<draft-eastlake-randomness2-04.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 RFC 2026. Internet-Drafts are		all provisions of Section 10 of RFC 2026. Internet Drafts are
	working documents of the Internet Engineering Task Force (IETF), its		working documents of the Internet Engineering Task Force (IETF), its
	areas, and its working groups. Note that other groups may also		areas, and its working groups. Note that other groups may also
	distribute working documents as Internet-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."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	Abstract		Abstract
	skipping to change at page 4, line 4 ¶		skipping to change at page 4, line 4 ¶
	6.1.5 Other Factors in Choosing a Mixing Function.........22		6.1.5 Other Factors in Choosing a Mixing Function.........22
	6.2 Non-Hardware Sources of Randomness....................23		6.2 Non-Hardware Sources of Randomness....................23
	6.3 Cryptographically Strong Sequences....................24		6.3 Cryptographically Strong Sequences....................24
	6.3.1 Traditional Strong Sequences........................24		6.3.1 Traditional Strong Sequences........................24
	6.3.2 The Blum Blum Shub Sequence Generator...............25		6.3.2 The Blum Blum Shub Sequence Generator...............25
	6.3.3 Entropy Pool Techniques.............................26		6.3.3 Entropy Pool Techniques.............................26
	7. Key Generation Standards and Examples..................28		7. Key Generation Standards and Examples..................28
	7.1 US DoD Recommendations for Password Generation........28		7.1 US DoD Recommendations for Password Generation........28
	7.2 X9.17 Key Generation..................................28		7.2 X9.17 Key Generation..................................28
			More Table of Contents
	7.3 The /dev/random Device under Linux....................29		7.3 The /dev/random Device under Linux....................29
	8. Examples of Randomness Required........................31		8. Examples of Randomness Required........................31
	8.1 Password Generation..................................31		8.1 Password Generation..................................31
	8.2 A Very High Security Cryptographic Key................32		8.2 A Very High Security Cryptographic Key................32
	8.2.1 Effort per Key Trial................................32		8.2.1 Effort per Key Trial................................32
	8.2.2 Meet in the Middle Attacks..........................32		8.2.2 Meet in the Middle Attacks..........................32
	9. Conclusion.............................................34		9. Conclusion.............................................34
	10. Security Considerations...............................34		10. Security Considerations...............................34
			Intellectual Property Considerations......................34
	Appendix: Minimal Secure Key Lengths Study................35		Appendix: Minimal Secure Key Lengths Study................36
	A.0 Abstract..............................................35		A.0 Abstract..............................................36
	A.1. Encryption Plays an Essential Role in Protecting.....36		A.1. Encryption Plays an Essential Role in Protecting.....37
	A.1.1 There is a need for information security............36		A.1.1 There is a need for information security............37
	A.1.2 Encryption to protect confidentiality...............37		A.1.2 Encryption to protect confidentiality...............38
	A.1.3 There are a variety of attackers....................38		A.1.3 There are a variety of attackers....................39
	A.1.4 Strong encryption is not expensive..................39		A.1.4 Strong encryption is not expensive..................40
	A.2. Brute-Forece is becoming easier......................39		A.2. Brute-Forece is becoming easier......................40
	A.3. 40-Bit Key Lengths Offer Virtually No Protection.....41		A.3. 40-Bit Key Lengths Offer Virtually No Protection.....42
	A.4. Even DES with 56-Bit Keys Is Increasingly Inadequate.42		A.4. Even DES with 56-Bit Keys Is Increasingly Inadequate.43
	A.4.1 DES is no panacea today.............................42		A.4.1 DES is no panacea today.............................43
	A.4.2 There are smarter attacks than brute force..........43		A.4.2 There are smarter avenues of attack than brute
	A.4.3 Other algorithms are similar........................43		force...............................................44
	A.5. Appropriate Key Lengths for the Future - A Proposal..44		A.4.3 Other algorithms are similar........................44
	A.6 About the Authors.....................................46		A.5. Appropriate Key Lengths for the Future --- A
	A.7 Acknowledgement.......................................47		Proposal.............................................45
			A.6 About the Authors.....................................47
			A.7 Acknowledgement.......................................48
	References................................................48		Informative References....................................49
	Authors Addresses.........................................52		Authors Addresses.........................................53
	File Name and Expiration..................................52		File Name and Expiration..................................53
	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, DNSSEC,		maturing and becoming a part of the network landscape [SSH, DNSSEC,
	IPSEC, MAIL*, TLS]. By comparison, when the previous version of this		IPSEC, MAIL*, TLS]. By comparison, when the previous version of this
	document [RFC 1750] was issued in 1994, about the only cryptographic		document [RFC 1750] was issued in 1994, about the only Internet
	security specification in the IETF was the Privacy Enhanced Mail		cryptographic security specification in the IETF was the Privacy
	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.
	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 12, line 35 ¶		skipping to change at page 12, line 35 ¶
	selected by fetching 32 bytes of data from a random starting point in		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		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
	CD/DVD recording or any other large public database. If the		publicly available CD/DVD recording or any other large public
	adversary has access to the same database, this "selection from a		database. If the adversary has access to the same database, this
	large volume of data" step buys very little. However, if a selection		"selection from a large volume of data" step buys very little.
	can be made from data to which the adversary has no access, such as		However, if a selection can be made from data to which the adversary
	system buffers on an active multi-user system, it may be of help.		has no access, such as system buffers on an active multi-user system,
			it may 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
	skipping to change at page 22, line 31 ¶		skipping to change at page 22, line 31 ¶
	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.5 Other Factors in Choosing a Mixing Function		6.1.5 Other Factors in Choosing a Mixing Function
	For local use, AES has the advantages that it has been widely tested		For local use, AES has the advantages that it has been widely tested
	for flaws, is reasonably efficient in software, and will be widely		for flaws, is reasonably efficient in software, and is widely
	documented and implemented with hardware and software implementations		documented and implemented with hardware and software implementations
	available all over the world including source code available on the		available all over the world including open source code. The SHA*
	Internet. The SHA* family are younger algorithms but there is no		family are younger algorithms but there is no particular reason to
	particular reason to believe they are flawed. Both SHA* and MD5 were		believe they are flawed. Both SHA* and MD5 were derived from the
	derived from the earlier MD4 algorithm. Some signs of weakness have		earlier MD4 algorithm. Some signs of weakness have been found in MD4
	been found in MD4 and MD5. They all have source code available [SHA*,		and MD5. They all have source code available [SHA*, MD*].
	MD*].
	AES and SHA* have been vouched for the the US National Security		AES and SHA* have been vouched for the the US National Security
	Agency (NSA) on the basis of criteria that primarily remain secret,		Agency (NSA) on the basis of criteria that primarily remain secret,
	as was DES. While this has been the cause of much speculation and		as was DES. While this has been the cause of much speculation and
	doubt, investigation of DES over the years has indicated that NSA		doubt, investigation of DES over the years has indicated that NSA
	involvement in modifications to its design, which originated with		involvement in modifications to its design, which originated with
	IBM, was primarily to strengthen it. No concealed or special		IBM, was primarily to strengthen it. No concealed or special
	weakness has been found in DES. It is almost certain that the NSA		weakness has been found in DES. It is very likely that the NSA
	modifications to MD4 to produce the SHA* similarly strengthened these		modifications to MD4 to produce the SHA* similarly strengthened these
	algorithms, possibly against threats not yet known in the public		algorithms, possibly against threats not yet known in the public
	cryptographic community.		cryptographic community.
	AES, DES, SHA*, MD4, and MD5 are believed to be royalty free for all		AES, DES, SHA*, MD4, and MD5 are believed to be royalty free for all
	purposes. Continued advances in crypography and computing power have		purposes. Continued advances in crypography and computing power have
	cast doubts on MD4 and MD5 so their use is generally not recommended.		cast doubts on MD4 and MD5 so their use is generally not recommended.
	Another advantage of the SHA* or similar hashing algorithms over		Another advantage of the SHA* or similar hashing algorithms over
	encryption algorithms in the past was that they are not subject to		encryption algorithms in the past was that they are not subject to
	skipping to change at page 32, line 24 ¶		skipping to change at page 32, line 24 ¶
	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. This		applications it is best to assume a low value of effort. This
	question is considered in detail in Appendix A. It concludes that a		question is considered in detail in Appendix A. It concludes that a
	reasonable key length in 1995 for very high security is in the range		reasonable key length in 1995 for very high security is in the range
	of 75 to 90 bits and, since the cost of cryptography does not vary		of 75 to 90 bits and, since the cost of cryptography does not vary
	much with they key size, recommends 90 bits. To update these		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		recommendations, just add 2/3 of a bit per year for Moore's law
	[MOORE]. Thus, in the year 2002, this translates to a determination		[MOORE]. Thus, in the year 2004, this translates to a determination
	that a reasonable key length is in 79 to 94 bit range.		that a reasonable key length is in 81 to 96 bit range.
	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 32, line 47 ¶		skipping to change at page 32, line 47 ¶
	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 very strong key to a minimum of 178 bits		amount of randomness in the very strong key to a minimum of 162 bits
	is required for the year 2002 based on the Appendix A analysis.		is required for the year 2004 based on the Appendix A analysis.
	This amount of randomness is beyond the limit of that in the inputs		This amount of randomness is beyond the limit of that in the inputs
	recommended by the US DoD for password generation and could require		recommended by the US DoD for password generation and could require
	user typing timing, hardware random number generation, or other		user typing timing, hardware random number generation, or other
	sources.		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 deep knowledge of the algorithm. Even if a basic algorithm
	is not subject to a meet in the middle attack, an attempt to produce		is not subject to a meet in the middle attack, an attempt to produce
	skipping to change at page 33, line 31 ¶		skipping to change at page 33, line 31 ¶
	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.
	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
	178 bit key size derived above.		162 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.
	Hardware techniques to produce such randomness would be relatively		Hardware techniques to produce such randomness would be relatively
	simple. In particular, the volume and quality would not need to be		simple. In particular, the volume and quality would not need to be
	high and existing computer hardware, such as disk drives, can be		high and existing computer hardware, such as disk drives, can be
	used.		used.
	skipping to change at page 35, line 5 ¶		skipping to change at page 34, line 36 ¶
	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,
	cryptographic keys, initialiazation vectors, sequence numbers, and		cryptographic keys, initialiazation vectors, sequence numbers, and
	similar security uses.		similar security uses.
			Intellectual Property Considerations
			The IETF takes no position regarding the validity or scope of any
			intellectual property or other rights that might be claimed to
			pertain to the implementation or use of the technology described in
			this document or the extent to which any license under such rights
			might or might not be available; neither does it represent that it
			has made any effort to identify any such rights. Information on the
			IETF's procedures with respect to rights in standards-track and
			standards-related documentation can be found in BCP-11. Copies of
			claims of rights made available for publication and any assurances of
			licenses to be made available, or the result of an attempt made to
			obtain a general license or permission for the use of such
			proprietary rights by implementors or users of this specification can
			be obtained from the IETF Secretariat.
			The IETF invites any interested party to bring to its attention any
			copyrights, patents or patent applications, or other proprietary
			rights which may cover technology that may be required to practice
			this standard. Please address the information to the IETF Executive
			Director.
	Appendix: Minimal Secure Key Lengths Study		Appendix: Minimal Secure Key Lengths Study
	Minimal Key Lengths for Symmetric Ciphers		Minimal Key Lengths for Symmetric Ciphers
	to Provide Adequate Commercial Security		to Provide Adequate Commercial Security
	A Report by an Ad Hoc Group of		A Report by an Ad Hoc Group of
	Cryptographers and Computer Scientists		Cryptographers and Computer Scientists
	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
	skipping to change at page 48, line 5 ¶		skipping to change at page 49, line 5 ¶
	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).
	A.7 Acknowledgement		A.7 Acknowledgement
	The [Appendix] authors would like to thank the Business Software		The [Appendix] authors would like to thank the Business Software
	Alliance, which provided support for a one-day meeting, held in		Alliance, which provided support for a one-day meeting, held in
	Chicago on 20 November 1995.		Chicago on 20 November 1995.
	References		Informative References
	[AES] - "Specification of theAdvanced Encryption Standard (AES)",		[AES] - "Specification of theAdvanced Encryption Standard (AES)",
	United States of America, Department of Commerce, National Institute		United States of America, Department of Commerce, National Institute
	of Standards and Technology, Federal Information Processing Standard		of Standards and Technology, Federal Information Processing Standard
	197, November 2001.		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 50, line 44 ¶		skipping to change at page 51, line 44 ¶
	[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.
	[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", Aegean Park Press, 1984, Wayne G. Barker.
	[SHA-1] - "Secure Hash Standard (SHA-1)", United States of American,		[SHA-1] - "Secure Hash Standard (SHA-1)", United States of American,
	National Institute of Science and Technology, Federal Information		National Institute of Science and Technology, Federal Information
	Processing Standard (FIPS) 180-1, April 1993.		Processing Standard (FIPS) 180-1, April 1993.
	- RFC 3174, "US Secure Hash Algorithm 1 (SHA1)", D. Eastlake, P.		- RFC 3174, "US Secure Hash Algorithm 1 (SHA1)", D. Eastlake,
	Jones, September 2001.		P. Jones, September 2001.
	[SHA-2] - "Secure Hash Standard", Draft (SHA-2156/384/512), Federal		[SHA-2] - "Secure Hash Standard", Draft (SHA-2156/384/512), Federal
	Information Processing Standard 180-2, not yet issued.		Information Processing Standard 180-2, not yet 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
	Cryptograhically Secure", Proceedings of IEEE STOC, 1987, J. Stern.		Cryptograhically Secure", Proceedings of IEEE STOC, 1987, J. Stern.
	[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.
	[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 Laboratories
	155 Beaver Street		155 Beaver Street
	Milford, MA 01757 USA		Milford, MA 01757 USA
	Telephone: +1 508-851-8280 (w)		Telephone: +1 508-851-8280 (w)
	+1 508-634-2066 (h)		+1 508-634-2066 (h)
	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
	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-03.txt.		This is file draft-eastlake-randomness2-04.txt.
	It expires January 2003.		It expires February 2004.
End of changes. 25 change blocks.
	52 lines changed or deleted		80 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/