[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[minion-cvs] Modified spec in response to resolved issues
Update of /home/minion/cvsroot/doc
In directory moria.seul.org:/tmp/cvs-serv26850
Modified Files:
minion-spec.tex
Log Message:
Modified spec in response to resolved issues
Index: minion-spec.tex
===================================================================
RCS file: /home/minion/cvsroot/doc/minion-spec.tex,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -d -r1.30 -r1.31
--- minion-spec.tex 18 Jun 2002 12:57:37 -0000 1.30
+++ minion-spec.tex 18 Jun 2002 17:19:29 -0000 1.31
@@ -301,6 +301,13 @@
to be delivered to the final receipient would be encrypted under his public
key. -GD]
+[XXXX All right. What if we have
+ TAG = PK_ENCRYPT(recipient_pk, nHops|seed) ?
+ This requires
+ that the recipient have a private key, and thus breaks
+ deniability and is nott as 'stateless' as the password-only
+ approach, but it still works if that's what you want. -NM]
+
\subsection{The header structure}
Each type III message has two headers with identical structure. These
@@ -318,18 +325,9 @@
[XXXX not a stream cipher. Encrypt()? -RD]
[XXXX Encrypt _is_ a stream cipher, but we should be specific. -NM]
-(In practice headers and subheaders are constructed in parallel since
-[XXXX in parallel? i don't get it. -RD]
-[XXXX Indeed; my implementation constructs the subheaders serially, in
- reverse order, as described below -NM]
-[XXXX Bad english, sorry. I meant that we build the subheaders while
- constructing the header, since the hash in them depends on
- the others. You cannot just construct all the subheaders
- separetly and plug them together. -GD]
-
-the Digest contained in the subheader is a hash of all the other
-encrypted subheaders and the random data they generate as the message
-travels through the network.)
+(In practice, depends pwe must construct the subheaders serially, from last to
+first, so that each can contain a digest of the subsequent subheaders
+and padding data.)
PROCEDURE: Create a single header.
@@ -516,6 +514,11 @@
KEY'') as a shared key, which is not used anywhere
else, and that cannot derive any other keys used in
the anonymization layer. -GD]
+[XXXX I agree with George. If the application were braindamaged and
+ leaked some of SK, the current node would not provide
+ anonymity. But if the application only leaked HASH(SK,
+ 'APPLICATION KEY'), the Mixminion layer would have already
+ anonymized the packet up to the application layer. -NM]
Module manager.
@@ -534,22 +537,6 @@
Binary Format:
-Begin Marker: 4 bytes
-Version: 2 bytes
-Routing Size: 2 bytes
-Routing Type: 2 bytes
-Routing Info: (Routing Size) bytes
-Use-by-Date: 4 bytes
-SURB size: 2 bytes
-SURB data: (SURB size) bytes
-Filler Key: 20 bytes
-Linked Data Size: 2 bytes
-Linked Data: (Linked Data Size) bytes
-Digest: 20 bytes
-
-Total: 54 bytes + Address Size + SURB size + Linked Data Size
-
-[XXXX In summary of my comments below, I suggest:
Begin Marker: 4 bytes
Version: 2 bytes
Use-by-Date: 4 bytes
@@ -558,17 +545,14 @@
Routing Type: 2 bytes
Routing Info: (Routing Size) bytes
- Total: 14 bytes + Header size + Routing info size. -NM]
-[XXXX I do not have very strong feelings either way, and since the
-format you propose fulfills its functions, I am quite happy to adopt
-it. -GD]
+ Total: 14 bytes + Header size + Routing info size.
* The magic marker contains the ASCII 4-byte string 'SURB'.
* The version number contains the format version of the SURB.
(should be hex 01 and 00 for this standard).
-* Routing type/routing size/routing info: Definded as in subheaders.
- These fields encode the
-
+* Routing type/routing size/routing info: Definded as in subheaders.
+ These fields encode the address of the hop which the SURB user should
+ use as an exit point.
* Use-by-Date: indicated the expiry date the SURB should be used by. Can
be calculated using the key rotation frequencies of the intermediate
nodes.
@@ -582,89 +566,11 @@
the first second of a day. -NM]
* SURB data: Containst the SURB that is created as described
- above. The Junk at the end can be omited (although it is not wise
- to reduce it more than half the size of a full SURB). When the SURB
- is created some data can be bound to it to ensure that they cannot
- be replaced by any malicious third party. To do this instead of
- including junk at the end of the SURB one can include a hash of the
- data:
- H(Address, Use-by-Date, Linked Data)
- That hash is contained in the last 20 bytes of the SURB data.
-
-* Filler: Used to prime the stream cipher to pad the SURB data up to
- 128*16 bytes.
-
- [ XXXX Why not just always include the junk? It'd be easier, and
- omitting the junk never saves more than 1K per SURB. -NM]
- [ XXXX True. Leaving the Junk also does not give away any
- information about the real length of the message. I included
- this possibility because 16 hops is actually quite a lot and 1k
- in a message of 32k could be significant (particularly is more
- than one SURB have to be transported). -GD]
- [ XXXX Hn. As Roger says, this _does_ leak an upper bound on the
- number of hops in a message. Also, by leaking the number of hops
- which the recipient feels are necessary, it may provide
- statistical linkability between a given recipient's SURBs.
-
- I really don't think this is worth it. Anybody who needs to
- send more than 27 SURBs per message should lobby for a bigger
- packet size. ;) -NM]
- [ XXXX Happy to drop it, if an application is so desparate for
- space, it can define a non standard encoding as well -GD]
-
-* Linked Data: Additional data that might have to be linked with the
- SURB.
- [ XXXX Hm. What is the point of this? Leaving it free-form raises
- issues of linkability. I suggest that rather than adding a
- catch-all hook, we just embed SURBs when we want to embed
- them. -NM]
- [ XXXX The rationale for including this additional data is the
- following: we might want to associate a public encryption key or
- someting else with the address itself, so the hash needs to be
- included before the junk. It is better to have a standard place to
- hold and encode this additional data otherwise everyone will be
- finding a different method for doing it. -GD]
- [ XXXX I disagree with the hash, so I disagree with the extra data.
- If we can foresee likely need here, let's design for it now.
- Else, I apply the end-to-end argument: see below. -NM]
- [ XXXX Let's drop the additional data. -GD]
-
-* The Digest is a Hash of all the other fields.
- [ XXXX Why have a digest here? What is the risk? Anybody who can
- tamper with a SURB can recompute the digest. -NM ]
- [ XXXX This is not a security feature, this is a reliability
- one. As the SURBs are transported over email (that can be
- commented etc) it is better if they can be checked as valid. Could
- just be a CRC. Is is nice if it is a hash since we are sure it is
- difficult to find another SURB that hashes to the same ID. -GD]
- [ XXXX So this prevents SURBs from being modified on the wire by
- non-malicious parties.
-
- I think the ``End-to-end'' argument applies:
- (http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.ps)
- ``The function in question can completely and correctly be
- implemented only with the knowledge and help of the application
- standing at the end points of the communication system.
- Therefore, providing that questioned function as a feature of the
- communication system itself is not possible. (Sometimes an
- incomplete version provided by the communications system may be
- useful as a performance enhancement.''
-
- If an application =needs= good SURBs, this hash is inadequate:
- we'll be encrypting them and wrapping with a signed hash. On
- the other hand, if the application =doesn't= need good SURBs,
- this hash is unnecessary. In either case, it's wasted.
-
- Similarly, metadata is best left to the application. What good
- is it to have a generic place to put metadata if that means
- that SURBs for application 1 can't be used with
- application 2? -NM]
- [XXXX I agree with all the above, so ye can drop it. -GD]
+ above.
The ASCII Encoding of SURBs.
-The ASCII compatible format of SURB's is:
-
+The ASCII compatible format of SURBs is:
-----BEGIN SURB-----
Version: x.x
Base64 encoded binary SURB
@@ -673,21 +579,6 @@
The version number should be in decimal ASCII and is the same as the
binary version.
-[ XXXX This should absolutely have a version number. Again, what does
- the digest defend against? -NM]
-[ XXXX It is not a security feature but an ID that uniquely identifies
- this SURB. Can be used by applications that manage SURBs to refer to
- them, and as a 8 character short hand if you want to address an
- email to the SURB -GD]
-[ XXXX See above for arguments against using the digest for integrity.
- I don't believe the digest would be very useful for the purposes
- here, either: (1) applications can compute hashes on their own if they
- like, (2) Any good tool for managing SURBs will provide shorthands
- far better than random 8-char strings. -NM]
-[ XXXX BTW, PEM-encoded stuff seems to use '-----BEGIN FOO-----' (5
- dashes, no space). Any reasons for this convention? -NM
-[ XXXX Changed the encoding and droped the ID -GD]
-
\section{Email Transport exchange format}
This format should be used when the SMTP address type is used for a
@@ -772,7 +663,7 @@
[XXXX Indeed I was thinking of maintaining sessions, even when the TCP
connection is dropped. Notice that re-keying does not involve any
Public key operations. Doing it every 5 minutes is good enough, or
-even doing it when tere is not much other traffic. -GD]
+even doing it when there is not much other traffic. -GD]
Protocol outline: (Portions marked with '*' are normative; other
portions are non-normative descriptions of TLS.)
@@ -887,8 +778,4 @@
Sending SMTP
Local delivery
-
-
-
-