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
 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.
 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
 .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
 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
 .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
 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
 .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
 .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
 .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
 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..."
 .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
 .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
 .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
 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$
 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
 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
 .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
 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