udpkey.1: Various fixes to the hastily written manual.

diff --git a/udpkey.1 b/udpkey.1
index 4c9df17..272905f 100644 (file)
--- a/udpkey.1
+++ b/udpkey.1
@@ -100,15 +100,15 @@ in the current working directory.
 Listen for incoming requests for key fragments and reply to them.  The
 default is to request key fragments.
 .TP
-.BR "\-r, \-\-random=" seed-file
+.BI "\-r, \-\-random=" seed-file
 Use (an initial portion of) the contents of
 .I seed-file
 to key the program's pseurorandom number generator.  Since
 .B udpkey
 is intended to run early in a system's boot procedure, it's quite
 unlikely that there's a great deal of high-quality entropy available.
-It's therefore useful to generate a key while the system is running, and
-store it somewhere where it can be found during early boot.
+It's therefore useful to generate a seed while the system is running,
+and store it somewhere where it can be found during early boot.
 .SS Client operation
 For each
 .I source-spec
@@ -175,7 +175,7 @@ A request packet contains a key tag identifying the wanted key
 fragment.  The key fragment is located.  If the key data is not a plain
 binary string, or the key has no
 .B clients
-attribute then the request is rejected.  Otherwise the value of the
+attribute, then the request is rejected.  Otherwise, the value of the
 .B clients
 attribute is expected to take the form
 .IP
@@ -214,9 +214,9 @@ utility.
 The security of
 .BR udpkey 's
 protocol (described below, for those who care about such things) is
-based on the difficulty of the \*(DH in cyclic groups.  The client need
-to know the private key; the server need only know the public part.
-Both ends must agree on the attributes associated with the key.
+based on the difficulty of \*(DH problems in cyclic groups.  The client
+needs to know the private key; the server need only know the public
+part.  Both ends must agree on the attributes associated with the key.
 .PP
 Two types of \*(DH groups are supported.  The group type is determined
 from the appropriate key's
@@ -225,8 +225,8 @@ attribute, if present.  The possible values are as follows.
 .TP
 .B dh
 Plain old \*(DH, in a Schnorr group \(en i.e., a prime-order subgroup of
-a the multiplicative group of a prime-order finite field.  An
-appropriate key may be generated using a command such as
+the multiplicative group of a prime-order finite field.  An appropriate
+key may be generated using a command such as
 .RS
 .IP
 .nf
@@ -239,8 +239,8 @@ A prime order subgroup of the group of projective points on an elliptic
 curve.  Catacomb's
 .BR key (1)
 program can't generate such groups, though it knows of a number of
-suitable examples, or you can use your own curves.  An appropriate man
-be generated using a command such as
+suitable examples, or you can use your own curves.  An appropriate key
+can be generated using a command such as
 .RS
 .IP
 .BI "key add \-t" tag " \-aec \-Cnist-p256 udpkey-kem group=ec \fR..."
@@ -277,7 +277,7 @@ attribute is mandatory; its syntax and semantics are described above.
 .SS Protocol description
 Let $G$ be a cyclic group with prime order $q$; we consider this as a
 one-dimensional vector space over the finite field ${roman GF}(q)$.  Let
-$P$ be any nonzero element of the group.
+$P$ be any nonzero vector.
 .PP
 The client's private key is a scalar $x$; its public key is the
 corresponding vector $X = x P$.  When constructing a request, a client
@@ -286,7 +286,7 @@ The request packet consists of the key tag of the wanted key fragment
 followed by a representation of the vector $U$.
 .PP
 When constructing a response, a server selects random scalars $v$ and
-$r$, and computes $U = u P$ and $R = r P$.  It then determines $Y = v U$
+$r$, and computes $V = v P$ and $R = r P$.  It then determines $Y = v U$
 and $Z = r X$, and hashes $R$ and $Z$ to obtain keys for a symmetric
 cipher and MAC.  It encrypts the key fragment and authenticates the
 resulting ciphertext.  Finally, the response consists of the vectors $V$
@@ -327,13 +327,14 @@ encryption is good, then the adversary must have found the key by
 hashing $R$ and $Z$.  Therefore it can recover $Y = R - W$, which solves
 an instance of the harder
 .I Computational
-(actually, Gap) \*(DH problem in $G$.  This analysis can be made
-rigorous and quantitative.
+(actually, Gap) \*(DH problem in $G$.
+.IP
+This analysis can be made rigorous and quantitative.
 .hP \*o
 Neither side attempts to authenticate the other explicitly.  The server
 implicitly authenticates the client by encrypting its key fragment using
 the client's public key.  (This encryption is standard DLIES, and
-security again depends on the Gap \*(DH problem in $G$.) The client
+security again depends on the Gap \*(DH problem in $G$.)  The client
 doesn't attempt to authenticate the server at all, though it can check
 that the response is correct by comparing its hash to a known copy; this
 confirms that the received key fragment is correct, and the client has