From 8d34ef00d95f1a74acc20616aa77c664dba62ba3 Mon Sep 17 00:00:00 2001 From: Mark Wooding Date: Mon, 24 Dec 2012 09:56:44 +0000 Subject: [PATCH] udpkey.1: Various fixes to the hastily written manual. --- udpkey.1 | 33 +++++++++++++++++---------------- 1 file changed, 17 insertions(+), 16 deletions(-) diff --git a/udpkey.1 b/udpkey.1 index 4c9df17..272905f 100644 --- 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 -- 2.11.0