Comments on minion-spec.txt

[George Danezis <gd@theory.lcs.mit.edu>]

Dear All,

I have just finished reading, and correcting, the main server spec 
"minion-spec.txt" (v1.4). I had some thoughts and I would be grateful if 
you could comment back on them.

1) The "modules" support we have could be entirely scrapped and replaced 
by whatever custom delivery types people are going to think of in the 
future. Right now the only additional service it offers, in comparison 
with the message being delivered to a mixminion client is a shared key. 
Unless clients provide an API to get this shared key (the current one does 
not) it is pretty useless. It feels that all the functionality could be 
implemented E2E and module support can therefore be scrapped. 

2) A lot of the code seems to become more complicated because we have a 
variable length field to describe variable length addressing information. 
Is that as useful as originally thought? How many of the current remailers 
use MMTP, and how many use SMTP to talk to each other? 

Would it just be simpler if only the last sub header could contain a
"long"  email address (This can be done painlessly since the last
sub-header in a header has a lot of free space anyway). That can be
implemented in a much simpler way. We could still put aside enough space
even for IPv6 addresses to fit.

3) (The slim-fast cure) 

Putting information inside the OAEP encryption assures that headers are
smaller. Should we reduce the size of headers, since we can fit up to 16
sub headers in less space. Was the original number of 16 headers per
sub-header realistic or should it be reduced (I have no strong feelings
about his).

The OAEP encryption contains a magic label L which for the moment is 
simply set to the hash of an inspiring quote. If, along with the inspiring 
quote, we hash the rest of the header we do not actually need a hash 
inside the mixminion sub-header (save 20 bytes with no reduction in 
security!) Downside: some implemetations of OAEP might not allow labels to 
be set (this would be a rpoblem anyway since we include our quote!)

Semi-controversial: The OAEP padding also uses a random seed (in order to 
fully hide the message from guessing attacks). We can use this random seed 
as our master key! This saves 16 bytes.

Controversial: Right now we use the full 160 bit SHA-1, but I still have 
not found any attacks relying on the full collision resistance (find any A 
and B such that H(A) = H(B) is O(n^80) ). I think, with some confidence, 
that we could reduce the hash functions down to 80 bits (10 bytes). This 
way the overhead of OAEP is just 22 bytes. 

[All the above should really go past OAEP experts before implemeting 
them]

The above modifications would keep the length of SURBs under 1kb, without 
losing any security (if the OAEP assertion above are correct).

4) Question: is it possible to implement an IPv6 server from the spec? 
(even if there are difficulties talking to the IPv4 world.)

Looking forward to comments and/or attacks,

George