grammar fixens from Andrey Smagin

1 files changed, 37 insertions, 37 deletions

diff --git a/sys/dev/rnd.c b/sys/dev/rnd.c
index 875f6f3a152..9a0edf69e40 100644
--- a/sys/dev/rnd.c
+++ b/sys/dev/rnd.c
@@ -1,7 +1,7 @@
-/*	$OpenBSD: rnd.c,v 1.60 2002/06/19 03:03:28 mickey Exp $	*/
+/*	$OpenBSD: rnd.c,v 1.61 2002/11/11 19:53:24 mickey Exp $	*/
 
 /*
- * random.c -- A strong random number generator
+ * rnd.c -- A strong random number generator
  *
  * Copyright (c) 1996, 1997, 2000-2002 Michael Shalayeff.
  *
@@ -56,20 +56,20 @@
  *
  * Computers are very predictable devices.  Hence it is extremely hard
  * to produce truly random numbers on a computer --- as opposed to
- * pseudo-random numbers, which can easily generated by using a
+ * pseudo-random numbers, which can be easily generated by using an
  * algorithm.  Unfortunately, it is very easy for attackers to guess
  * the sequence of pseudo-random number generators, and for some
- * applications this is not acceptable.  So instead, we must try to
+ * applications this is not acceptable.  Instead, we must try to
  * gather "environmental noise" from the computer's environment, which
- * must be hard for outside attackers to observe, and use that to
+ * must be hard for outside attackers to observe and use to
  * generate random numbers.  In a Unix environment, this is best done
  * from inside the kernel.
  *
  * Sources of randomness from the environment include inter-keyboard
  * timings, inter-interrupt timings from some interrupts, and other
  * events which are both (a) non-deterministic and (b) hard for an
- * outside observer to measure.  Randomness from these sources are
- * added to an "entropy pool", which is mixed using a CRC-like function.
+ * outside observer to measure.  Randomness from these sources is
+ * added to the "entropy pool", which is mixed using a CRC-like function.
  * This is not cryptographically strong, but it is adequate assuming
  * the randomness is not chosen maliciously, and it is fast enough that
  * the overhead of doing it on every interrupt is very reasonable.
@@ -78,7 +78,7 @@
  * the random number generator's internal state.
  *
  * When random bytes are desired, they are obtained by taking the MD5
- * hash of the contents of the "entropy pool".  The MD5 hash avoids
+ * hash of the content of the entropy pool.  The MD5 hash avoids
  * exposing the internal state of the entropy pool.  It is believed to
  * be computationally infeasible to derive any useful information
  * about the input of MD5 from its output.  Even if it is possible to
@@ -93,22 +93,22 @@
  * random numbers; however, an attacker may (at least in theory) be
  * able to infer the future output of the generator from prior
  * outputs.  This requires successful cryptanalysis of MD5, which is
- * not believed to be feasible, but there is a remote possibility.
+ * believed to be not feasible, but there is a remote possibility.
  * Nonetheless, these numbers should be useful for the vast majority
  * of purposes.
  *
  * Exported interfaces ---- output
  * ===============================
  *
- * There are three exported interfaces; the first is one designed to
- * be used from within the kernel:
+ * There are three exported interfaces.
+ * The first one is designed to be used from within the kernel:
  *
  *	void get_random_bytes(void *buf, int nbytes);
  *
  * This interface will return the requested number of random bytes,
  * and place it in the requested buffer.
  *
- * The two other interfaces are two character devices /dev/random and
+ * Two other interfaces are two character devices /dev/random and
  * /dev/urandom.  /dev/random is suitable for use when very high
  * quality randomness is desired (for example, for key generation or
  * one-time pads), as it will only return a maximum of the number of
@@ -116,7 +116,7 @@
  * contained in the entropy pool.
  *
  * The /dev/urandom device does not have this limit, and will return
- * as many bytes as are requested.  As more and more random bytes are
+ * as many bytes as were requested.  As more and more random bytes
  * requested without giving time for the entropy pool to recharge,
  * this will result in random numbers that are merely cryptographically
  * strong.  For many applications, however, this is acceptable.
@@ -136,7 +136,7 @@
  *	void add_audio_randomness(int n);
  *
  * add_true_randomness() uses true random number generators present
- * on some cryptographic and system chipsets. entropy accounting
+ * on some cryptographic and system chipsets.  Entropy accounting
  * is not quitable, no timing is done, supplied 32 bits of pure entropy
  * are hashed into the pool plain and blindly, increasing the counter.
  *
@@ -149,19 +149,19 @@
  * add_net_randomness() times the finishing time of net input.
  *
  * add_tty_randomness() uses the inter-keypress timing, as well as the
- * character as random inputs into the "entropy pool".
+ * character as random inputs into the entropy pool.
  *
  * add_disk_randomness() times the finishing time of disk requests as well
  * as feeding both xfer size & time into the entropy pool.
  *
  * add_audio_randomness() times the finishing of audio codec dma
  * requests for both recording and playback, apparently supplies quite
- * a lot of entropy, i'd blame on low resolution audio clock generators.
+ * a lot of entropy. I'd blame it on low resolution audio clock generators.
  *
  * All of these routines (except for add_true_randomness() of course)
- * try to estimate how many bits of randomness a particular randomness
- * source.  They do this by keeping track of the first and second order
- * deltas of the event timings.
+ * try to estimate how many bits of randomness are in a particular
+ * randomness source.  They do this by keeping track of the first and
+ * second order deltas of the event timings.
  *
  * Ensuring unpredictability at system startup
  * ============================================
@@ -173,7 +173,7 @@
  * entropy pool below the value in entropy_count.  In order to
  * counteract this effect, it helps to carry information in the
  * entropy pool across shut-downs and start-ups.  To do this, put the
- * following lines an appropriate script which is run during the boot
+ * following lines in appropriate script which is run during the boot
  * sequence:
  *
  *	echo "Initializing random number generator..."
@@ -184,8 +184,8 @@
  *	fi
  *	dd if=/dev/urandom of=/etc/random-seed count=1
  *
- * and the following lines in an appropriate script which is run as
- * the system is shutdown:
+ * and the following lines in appropriate script which is run when
+ * the system is shutting down:
  *
  *	# Carry a random seed from shut-down to start-up
  *	# Save 512 bytes, which is the size of the entropy pool
@@ -196,7 +196,7 @@
  * usually /etc/rc.d/rc.local and /etc/rc.d/rc.0, respectively.
  *
  * Effectively, these commands cause the contents of the entropy pool
- * to be saved at shut-down time and reloaded into the entropy pool at
+ * to be saved at shutdown time and reloaded into the entropy pool at
  * start-up.  (The 'dd' in the addition to the bootup script is to
  * make sure that /etc/random-seed is different for every start-up,
  * even if the system crashes without executing rc.0.)  Even with
@@ -221,12 +221,12 @@
  * Ideas for constructing this random number generator were derived
  * from Pretty Good Privacy's random number generator, and from private
  * discussions with Phil Karn.  Colin Plumb provided a faster random
- * number generator, which speed up the mixing function of the entropy
+ * number generator, which speeds up the mixing function of the entropy
  * pool, taken from PGPfone.  Dale Worley has also contributed many
  * useful ideas and suggestions to improve this driver.
  *
  * Any flaws in the design are solely my responsibility, and should
- * not be attributed to the Phil, Colin, or any of authors of PGP.
+ * not be attributed to the Phil, Colin, or any of the authors of PGP.
  *
  * Further background information on this topic may be obtained from
  * RFC 1750, "Randomness Recommendations for Security", by Donald
@@ -326,8 +326,8 @@ int	rnd_debug = 0x0000;
  * that periodicity is not a concern.
  *
  * The input hash is much less sensitive than the output hash.  All
- * that we want of it is that it be a good non-cryptographic hash;
- * i.e. it not produce collisions when fed "random" data of the sort
+ * we want from it is to be a good non-cryptographic hash -
+ * i.e. to not produce collisions when fed "random" data of the sort
  * we expect to see.  As long as the pool state differs for different
  * inputs, we have preserved the input entropy and done a good job.
  * The fact that an intelligent attacker can construct inputs that
@@ -482,13 +482,13 @@ void arc4maybeinit(void);
  * is used as a stream cipher called "arcfour" in Tatu Ylonen's ssh
  * package.
  *
- * The initialization function here has been modified not to discard
- * old state, and its input always includes the time of day in
+ * The initialization function here has been modified to not discard
+ * the old state, and it's input always includes the time of day in
  * microseconds.  Moreover, bytes from the stream may at any point be
  * diverted to multiple processes or even kernel functions desiring
  * random numbers.  This increases the strength of the random stream,
- * but makes it impossible to use this code for encryption--There is
- * no way ever to reproduce the same stream of random bytes.
+ * but makes it impossible to use this code for encryption, since there
+ * is no way to ever reproduce the same stream of random bytes.
  *
  * RC4 is a registered trademark of RSA Laboratories.
  */
@@ -642,7 +642,7 @@ randomclose(dev, flag, mode, p)
 }
 
 /*
- * This function adds a byte into the entropy "pool".  It does not
+ * This function adds a byte into the entropy pool.  It does not
  * update the entropy estimate.  The caller must do this if appropriate.
  *
  * The pool is stirred with a primitive polynomial of degree 128
@@ -690,13 +690,13 @@ add_entropy_words(buf, n)
 }
 
 /*
- * This function adds entropy to the entropy "pool" by using timing
+ * This function adds entropy to the entropy pool by using timing
  * delays.  It uses the timer_rand_state structure to make an estimate
  * of how many bits of entropy this call has added to the pool.
  *
  * The number "num" is also added to the pool - it should somehow describe
- * the type of event which just happened.  This is currently 0-255 for
- * keyboard scan codes, and 256 upwards for interrupts.
+ * the type of event which just happened.  Currently the values of 0-255
+ * are for keyboard scan codes, 256 and upwards - for interrupts.
  * On the i386, this is assumed to be at most 16 bits, and the high bits
  * are used for a high-resolution timer.
  *
@@ -728,7 +728,7 @@ enqueue_randomness(state, val)
 	nbits = 0;
 
 	/*
-	 * Calculate number of bits of randomness we probably
+	 * Calculate the number of bits of randomness that we probably
 	 * added.  We take into account the first and second order
 	 * deltas in order to make our estimate.
 	 */
@@ -863,7 +863,7 @@ dequeue_randomness(v)
 #endif
 
 /*
- * This function extracts randomness from the "entropy pool", and
+ * This function extracts randomness from the entropy pool, and
  * returns it in a buffer.  This function computes how many remaining
  * bits of entropy are left in the pool, but it does not restrict the
  * number of bytes that are actually obtained.