[minion-cvs] Added some ideas about how the API for using the anonym...

[gd@seul.org]

Update of /home/minion/cvsroot/doc
In directory moria.seul.org:/tmp/cvs-serv10744

Modified Files:
	minion-spec.tex nym-desc.tex 
Log Message:
Added some ideas about how the API for using the anonymous network 
would look (IMHO). I am not sure if the discussion should not be 
moved from the nym to the main spec.



Index: minion-spec.tex
===================================================================
RCS file: /home/minion/cvsroot/doc/minion-spec.tex,v
retrieving revision 1.60
retrieving revision 1.61
diff -u -d -r1.60 -r1.61
--- minion-spec.tex	10 Sep 2002 12:49:56 -0000	1.60
+++ minion-spec.tex	10 Sep 2002 14:14:03 -0000	1.61
@@ -413,6 +413,18 @@
 		
 		P = M; exit;
 
+[XXXX We do not actually specify how the TAG field and the BODY are
+found, prior to be given to this function. So the above works for
+delivery via SMTP but not if the final hop is reached via FWD/IP4. The
+options are the following: 
+	- We require the final recipient to have a public/private key
+	  and decode the header to extract the TAG/BODY messages.
+	- We use symmetric encryption for the final header and extract
+	  the TAG field using a secret key.
+Any of the two can be used, and it does not have to be standardized
+since this operation only affects the final client, but we can give
+some advice. -GD]
+
 [I am a bit uneasy that we have not defined any redundancy, or marker,
 that would allow the final recipient to decide if this is a forward
 path message or a SURBed message. Also the size of valid bytes has

Index: nym-desc.tex
===================================================================
RCS file: /home/minion/cvsroot/doc/nym-desc.tex,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -d -r1.3 -r1.4
--- nym-desc.tex	26 Aug 2002 20:13:25 -0000	1.3
+++ nym-desc.tex	10 Sep 2002 14:14:05 -0000	1.4
@@ -16,7 +16,85 @@
 
 Implementing the anonymous primitives using Mixminion
 
-[...]
+We assume the existence of the following procedures from the mixminion
+specifications: 
+
+PROCEDURE: Create a single header.
+Inputs: A_1 .. A_N (addresses of intermediate nodes), 
+	PK_1 .. PK_N (Public keys of intermediate nodes),
+	SK_1 .. SK_N (Secret keys to be shared with intermediate nodes),
+        R Routing type and information of last header (FWD, DROP, SWAP, etc.)
+Output: H (The header)
+
+PROCEDURE: Construct a message.
+Input: H1 (header containing keys SK1_1... SK1_N)
+       and H2 (either a header containing keys SK2_1... SK2_N if
+         we constructed it, or a header with unknown keys if we're
+         using a reply block and a SURB secret key.)
+       P (Payload)
+Output: M (the message)
+
+PROCEDURE: Decode a message.
+Input:  TAG field of sub-header or header where 
+        TAG = ( Encrypt(KEY, nHops | seed) | padding up to 44b).
+        M the body of the message.
+Output: P, the plaintext of the message.
+
+
+We will define the following operations:
+(An API for mixminion clients)
+
+PROCEDURE: Create SURB
+Input: -
+Output: ID of the generated SURB. 
+	SURB data.
+
+The above procedure generates a SURB that is addressed to the local
+machine given the local configuration.
+
+PROCEDURE: Send Anonymous
+Input: Address as specified in the ``Routing information'' section of
+	the mixminion spec.
+       OR 
+       SURB provided by another user.
+       Message to be encoded and sent.
+Output: -
+
+The above procedure sends a sender anonymous (and recipient anonymous
+if a SURB is provided) message.
+
+PROCEDURE: Send
+Input: SURB provided by another user.
+       Message to be encoded and sent.
+Output: -
+
+The ``Send'' procedure sends a normal (non-anonymous) message to an
+anonymous address.
+
+PROCEDURE: Receive Anonymous 
+Input: -
+Output: ID, the id of the SURB used to encode this message.
+	Message, the message received (decoded)
+
+The ID can be zero (0) if the message received did not use a SURB, and
+therefore is not anonymous. It is important to make sure that
+information that is to remain anonymous is not sent back as a reply.
+
+It is important to note that in order to create the new procedures
+from the ones provided in the mixminion specification a lot of
+internal state is required in the client. Hopefully this state should
+be preconfigured in the ``anonymous communication stack'' and then
+hidden from the layer above that should only need the operations above
+to use the anonymity layer. In particular additional information
+required includes:
+- Lists of mixes, with reliability statistics or another strategy to
+choose routes with.
+- Secret keys under which the TAG field is encrypted or public/private
+key pairs to decode normal mixminion headers.
+- A strategy to compute the route lengths.
+- A knowledge of the local host parameters, and preferred modes of
+delivery (IP or SMTP).
+
 
 The requirements of the Nym Server are: