[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Comments on minion-spec.txt
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
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
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,