/[pkg-mixmaster]/trunk/Docs/draft-moeller-v2-01.txt
ViewVC logotype

Diff of /trunk/Docs/draft-moeller-v2-01.txt

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 531 by weaselp, Sat Jun 21 01:29:08 2003 UTC revision 532 by rabbi, Sat Jun 21 02:18:20 2003 UTC
# Line 67  Table of Contents Line 67  Table of Contents
67     2.1 Message Creation     2.1 Message Creation
68     2.2 Remailing     2.2 Remailing
69     2.3 Message Reassembly     2.3 Message Reassembly
70     3. Message Format     3. Pool Behavior
71     3.1 Payload Format     3.1 Pool Mix Algorithm
72     3.2 Cryptographic Algorithms     3.2 Dummy Traffic
73     3.3 Packet Format     4. Message Format
74     3.3.1 Header Section Format     4.1 Payload Format
75     3.3.2 Body Format     4.2 Cryptographic Algorithms
76     3.4 Mail Transport Encoding     4.3 Packet Format
77     4. Key Format     4.3.1 Header Section Format
78     5. Pool Mix Behavior     4.3.2 Body Format
79     5.1 Pool Mix Algorithm     4.4 Mail Transport Encoding
80     5.2 Dummy Traffic     5. Key Format
81       5.1 Key Rotation
82     6. Delivery of Anonymous Messages     6. Delivery of Anonymous Messages
83     7. Security Considerations     7. Security Considerations
84     8. Acknowledgements     8. Acknowledgements
# Line 184  part of a certain message. To all the ot Line 185  part of a certain message. To all the ot
185  independent.  independent.
186    
187    
188  3. Pool Functionality  3. Pool Behavior
189    
190  3.1 Cottrell pool mix algorithm  3.1 Cottrell Pool Mix algorithm
191    
192  In order to obfuscate the link between incoming and outgoing messages  In order to obfuscate the link between incoming and outgoing messages,
193  Mixmaster uses a pooling scheme.  Messages that are to be forwarded  Mixmaster uses a pooling scheme.  Messages that are to be forwarded
194  anonymously are stored in a pool.  In regular intervals the Mix fires  anonymously are stored in a pool.  In regular intervals the remailer fires
195  and sends some random messages from the pool to either the next hop or their  and sends some random messages from the pool to either the next hop or
196  final recipient.  their final recipients.
197    
198  The pooling scheme used in Mixmaster is Cottrell mixing which has  The pooling scheme used in Mixmaster is the "Cottrell Pool Mix", which has
199  the following three parameters:  the following three parameters:
200    t       mixing interval    t       mixing interval
201    min     minimum number of messages in the pool    min     minimum number of messages in the pool
# Line 208  Every t seconds: Line 209  Every t seconds:
209    
210  3.2. Dummy Traffic  3.2. Dummy Traffic
211    
212    "Dummy messages" are multi-hop messages of type NULL with five randomly
213    selected nodes as their chain.
214    
215  Older versions of Mixmaster (2.0.4 - 2.9.0) allowed for the creation of  Older versions of Mixmaster (2.0.4 - 2.9.0) allowed for the creation of
216  "dummy message" cover traffic, but provided no automated means for introducing  dummy message cover traffic, but provided no automated means for introducing
217  this dummy traffic into the system. Beginning in version 3.0, Mixmaster employs  this dummy traffic into the system. Beginning in version 3.0, Mixmaster employs
218  an internal dummy policy.  an internal dummy policy.
219    
220  Every time a message is placed in the pool Mixmaster chooses a random number  Every time a message is placed in the pool, the remailer chooses a random
221  from a geometric distribution and create that many dummy messages which are  number from a geometric distribution and creates that many dummy messages
222  placed in the pool.  Dummy messages are multi hop messages using several random  which are also placed in the pool.
223  nodes as their chain.  Similarly each time just before we run the mixing  
224  algorithm described above we also choose a random number from a different  Similarly, prior to each execution of the mixing algorithm described in
225  geometric distribution and add that many dummy messages to the pool as well.  section 3.1, the remailer selects a random number from a different geometric
226    distribution and adds that many dummy messages to the pool as well.
227  The distributions' parameters are chosen so that on average we create one  
228  dummy for every 32 messages coming in and one every 9 mixing rounds.  The distributions' parameters are chosen so that on average the remailer
229    creates one dummy for every 32 messages coming in and one every 9 mixing
230    rounds.
231    
232  4. Message Format  4. Message Format
233    
# Line 339  as follows: Line 345  as follows:
345       Triple-DES key                       [ 24 bytes]       Triple-DES key                       [ 24 bytes]
346       Packet type identifier               [  1 byte ]       Packet type identifier               [  1 byte ]
347       Packet information      [depends on packet type]       Packet information      [depends on packet type]
348       Timestamp                            [  7 bytes] (optional)       Timestamp                            [  7 bytes]
349       Message digest                       [ 16 bytes]       Message digest                       [ 16 bytes]
350       Random padding               [fill to 328 bytes]       Random padding               [fill to 328 bytes]
351    
# Line 371  Triple-DES key: used to encrypt the foll Line 377  Triple-DES key: used to encrypt the foll
377  packet body.  packet body.
378    
379  Initialization vectors: For packet type 1 and 2, the IV is used to  Initialization vectors: For packet type 1 and 2, the IV is used to
380  symmetrically encrypt the packet body. For packet type 0, there is one  symmetrically encrypt the packet body. For packet type 0, there is one IV
381  IV for each of the 19 following header sections (Note: This is solved  for each of the 19 following header sections. The IV for the last header
382  more efficiently in later versions of the protocol). The IV for the  section is also used for the packet body.
 last header section is also used for the packet body.  
383    
384  Remailer address: e-mail address of next hop.  Remailer address: e-mail address of next hop.
385    
# Line 386  with 1. Line 391  with 1.
391    
392  Number of chunks: Total number of chunks.  Number of chunks: Total number of chunks.
393    
394  Timestamp: A timestamp is introduced with the byte sequence (48, 48,  Timestamp: A timestamp is introduced with the byte sequence (48, 48, 48,
395  48, 48, 0). The following two bytes specify the number of days since  48, 0). The following two bytes specify the number of days since Jan 1,
396  Jan 1, 1970, given in little-endian byte order. A random number of up  1970, given in little-endian byte order. A random number of up to 3 may be
397  to 3 may be subtracted from the number of days in order to obscure  subtracted from the number of days in order to obscure the origin of the
398  the origin of the message. To avoid partitioning attacks [CITE?],  message.
399  implementations SHOULD make use of the timestamp packet.  
400    Early implementations of Mixmaster did not generate a timestamp packet.
401    Implementors should be aware of the partitioning attack implications if
402    they chose to permit processing of packets without timestamps.
403    
404  Message digest: MD5 digest computed over the preceding elements of the  Message digest: MD5 digest computed over the preceding elements of the
405  encrypted header part.  encrypted header part.
406    
407  In the case of packet type 0, header sections 2 .. 20 and the packet  In the case of packet type 0, header sections 2 .. 20 and the packet body
408  body each are decrypted separately using the respective initialization  each are decrypted separately using the respective initialization vectors.
409  vectors.  In the case of packet types 1 and 2, header sections 2 .. 20 are ignored,
410  In the case of packet types 1 and 2, header sections 2 .. 20 are  and the packet body is decrypted using the given initialization vector.
 ignored, and the packet body is decrypted using the given  
 initialization vector.  
411    
412    
413  4.3.2 Body Format  4.3.2 Body Format
# Line 450  public RSA key: Line 456  public RSA key:
456    
457  The attributes are listed in one line separated by spaces:  The attributes are listed in one line separated by spaces:
458    
459   identifier:      a human readable string identifying the remailer   identifier:       a human readable string identifying the remailer
460   address:         the remailer's Internet mail address   address:          the remailer's Internet mail address
461   key ID:          public key ID   key ID:           public key ID
462   version:         the Mixmaster software version number   version:          the Mixmaster software version number
463   capabilities:    flags indicating additional remailer capabilities   capabilities:     flags indicating additional remailer capabilities
464   creation date:   date stamp in the format YYYY-MM-DD (optional)   creation date:    date of the key's creation
465   expiration date: date stamp in the format YYYY-MM-DD (optional)   expiration date:  date of the key's expiration
466    
467  The identifier consists of lowercase alphanumeric characters, beginning with an  The identifier consists of lowercase alphanumeric characters, beginning
468  alphabetic character. It must not contain whitespace.  with an alphabetic character. It must not contain whitespace.
469    
470  The encoded key packet consists of two bytes specifying the key length  The encoded key packet consists of two bytes specifying the key length
471  (1024 bits) in little-endian byte order, and of the RSA modulus and  (1024 bits) in little-endian byte order, and of the RSA modulus and
# Line 474  hexadecimal string. Line 480  hexadecimal string.
480    
481  The capabilities field is optional. It is a list of flags represented  The capabilities field is optional. It is a list of flags represented
482  by a string of ASCII characters. Clients should ignore unknown  by a string of ASCII characters. Clients should ignore unknown
483  flags. The following flags are used in version 2.0.4:  flags. The following flags are used in version 2.0.4 through 3.0:
484    
485   C     accepts compressed messages.   C     accepts compressed messages.
486   M     will forward messages to another mix when used as final hop.   M     will forward messages to another mix when used as final hop.
487   Nm    supports posting to Usenet through a mail-to-news gateway.   Nm    supports posting to Usenet through a mail-to-news gateway.
488   Np    supports direct posting to Usenet.   Np    supports direct posting to Usenet.
489    
490    The date fields introduced in version 3.0 are optional. They are ASCII
491    date stamps in the format YYYY-MM-DD. The first date indicates the key
492    creation date; the second date indicates its expiration. If only one date
493    is present, it is treated as the key creation date.
494    
495  Digital signatures [RFC 2440] should be used to ensure the  Digital signatures [RFC 2440] should be used to ensure the
496  authenticity of the key files.  authenticity of the key files.
497    
498    5.1 Key Rotation
499    
500    [Describe key rotation here. We need a good policy for this -- is what we
501    do in CVS the right thing wrt to partitioning implications? -LS]
502    
503  6. Delivery of Anonymous Messages  6. Delivery of Anonymous Messages
504    
Legend:
Removed from v.531  
changed lines
  Added in v.532
  ViewVC Help
Powered by ViewVC 1.1.5