[Nym3-commit] r431 - trunk/doc

[nickm at conuropsis.org]

Author: nickm
Date: 2005-11-28 18:44:39 +0100 (Mon, 28 Nov 2005)
New Revision: 431

Modified:
   trunk/doc/nym-spec.txt
Log:
Sync nym-spec.txt with version in mixminion repo; update TODO at end.

Modified: trunk/doc/nym-spec.txt
===================================================================
--- trunk/doc/nym-spec.txt	2005-11-27 23:52:14 UTC (rev 430)
+++ trunk/doc/nym-spec.txt	2005-11-28 17:44:39 UTC (rev 431)
@@ -1,4 +1,4 @@
-$Id: nym-spec.txt,v 1.8 2004/08/18 18:50:22 nickm Exp $
+$Id: nym-spec.txt,v 1.11 2005/05/04 10:49:46 nickm Exp $
 
                                Mix3:Nym
     Underhill: A Proposed Type 3 Nymserver Protocol Specification
@@ -380,9 +380,9 @@
          XXXX]
 
       2. The nymserver then forms a synopsis of the email; generates a
-         random 20-octet message ID for the email; encrypts the email
-         for receipt by the nymholder, and decrements the email's size
-         from the user's available quota.
+         cryptographically random 20-octet message ID for the email;
+         encrypts the email for receipt by the nymholder, and
+         decrements the email's size from the user's available quota.
 
 2.3. Relaying emails to the user
 
@@ -506,10 +506,10 @@
    To encrypt an octet sequence, the nymserver first compresses the
    octet sequence (as described in E2E-spec.txt).  Next, the nymserver
    pads the octet sequence to the nearest multiple of 128 octets in
-   length.  The nymserver then generates a random 160-bit key;
-   LIONESS-encrypts the padded compressed data with the key; and
-   prepends to the encrypted data the RSA-encrypted key.  We use the
-   same trick as minion-spec.txt to minimize wasted space.
+   length.  The nymserver then generates a cryptographically random
+   160-bit key; LIONESS-encrypts the padded compressed data with the
+   key; and prepends to the encrypted data the RSA-encrypted key.  We
+   use the same trick as minion-spec.txt to minimize wasted space.
 
    PROCEDURE: Encrypt an octet sequence to a nymholder.
    INPUTS:
@@ -547,7 +547,7 @@
    by prepending to each one the following 22 octet header, and then
    concatenating the synopses.
 
-        ID     [20 octets]   (A randomly generated message ID.)
+        ID     [20 octets]   (A cryptographically random message ID.)
         LEN    [2 octets]    (Length of the synopsis, in octets.)
 
    (Note that the nymserver must associate with each encrypted set of
@@ -578,11 +578,11 @@
             CS    Command data size (3 octets)
             CD    Command data      (variable length; CS octets)
 
-   The 'Signature' field is equal to the RSA-OAEP signature of a
-   SHA-1 hash of the remainder of the message.  The NL field is equal
-   to the length of NYM.  The NYM field is equal to the Nym to which
-   these commands apply.  The SEQNO field holds a random value used
-   by the nymserver later to acknowledge this message.
+   The 'Signature' field is equal to the RSA-OAEP signature of a SHA-1
+   hash of the remainder of the message.  The NL field is equal to the
+   length of NYM.  The NYM field is equal to the Nym to which these
+   commands apply.  The SEQNO field holds a cryptographically random
+   value used by the nymserver later to acknowledge this message.
 
    The value of each 'CS' field must be the big-endian representation
    of the size of the immediately following CD field.
@@ -604,7 +604,8 @@
 
    The body of a CREATE command has the following structure:
          NNym  Number of candidate nyms  (1 octet)
-         PW    Proof of work             (??? octets)
+	 PWL   Proof of work Length	 (1 octet)
+         PW    Proof of work             (variable length; PWL octets)
        Sequence of:
          NL    Candidate Nym Length      (1 octet)
          Nym   Candidate Nym             (variable length; NL octets)
@@ -616,7 +617,9 @@
    given in the NEWPK command.  The nymserver replies with a CREATED
    command, which the nymholder confirms with a CREATE2 command.)
 
-   [XXXX specify a proof-of-work system.]
+   The PW field MUST be empty and the corresponding PWL field set to
+   0. Future version of the protocol MAY understand a non-empty PW
+   field.
 
 4.3.2. CREATE2 [0x01]
 
@@ -645,8 +648,8 @@
      ID   Identity key          (variable length; ID_L octets)
      ENC  Encryption key        (variable length; remainder of command)
 
-   The key length fields MUST be 128 or 256.  The key fields hold
-   ASN.1 encoded RSA public keys.  Their exponents must be 65537.
+   The key fields hold ASN.1 encoded RSA public keys.  Their exponents
+   must be 65537. Their modulus must have a size of 2048 bits.
 
    Because the nymserver may not receive the message, the nymholder
    should continue to sign commands with its previous identity key
@@ -753,8 +756,8 @@
             CD    Command data      (variable length; CS octets)
 
    The NYM field is equal to the Nym to which these commands apply.
-   The NONCE field holds a random value used by the nymserver later to
-   acknowledge this message.
+   The NONCE field holds a cryptographically random value used by the
+   nymserver later to acknowledge this message.
 
    The value of each 'CS' field must be the big-endian representation
    of the size of the immediately following CD field.
@@ -878,5 +881,13 @@
    - We need some kind of entry format for nymservers' server
      descriptors.
 
-   - What is in George's and Peter's nymserver specifications that I
-     missed?
+   - change the packet format to use canonical [WWW] S-EXP
+     - once we use s-exp, we can make everything more extensible.
+   - add email address to CREATED msgs
+   - add a way for users to destroy nym accounts.
+     - (using the client, or using a pregenerated revocation cert)
+     - (should msgs to closed accounts get dumped, or get bounced?)
+   - change the canonical specification from mixminion CVS to nymbaron SVN
+     repository.
+
+