modularization and some comments (was: Notes from Conversation with Roger)

[Zooko <zooko@zooko.com>]

I'll reply to a couple of specific things, but first a proposal:

Let us have five conceptual modules:

1.  the "Mix Core" module

This is the part that George designs with our help.  Anything which directly 
affects the anonymity of the message mix belongs inside this conceptual module, 
and anything which does not affect the anonymity of the message mix belongs 
outside.  (But see #3 and #4 below...)

2.  the "remailer application"

This does SMTP emit and SMTP input (nymservers).  It is the canonical example of 
an application that can be built on top of the "Mix Core" platform using the Mix 
Core API, without understanding the internals of the Mix Core module.

3.  the "trust management" module

This is a conceptual module, which is responsible for informing the Mix Core 
about what chains (and/or cascades) to use.  One implementation is that the user 
manually specifies.  Another is a random selection algorithm.  A third would be 
transitive trust management such as Roger and Raph Levien are researching.

Regardless of what kind of trust management you want to implement, I hope you 
will agree that it should be conceptually separated from the other modules.

4.  the "MixMinion Transport Protocol" module

Encryption, integrity, forward-secrecy, etc.

5.  the "underlying transport" module

In practice, this is a simple TCP protocol that we specify, but it is useful to 
consider it as a separate conceptual module because (a) it shouldn't interact 
with the MMTP module's security nor the Mix Core modules's anonymity (right??) 
and (b) people might want to use alternatives for firewall-piercing or other 
reasons.  (Disclosure: I am the author of one such alternative transport 
mechanism: EGTP [1].)


Okay now some specific replies.  (Like George, I omit much of the quoted message 
because I agree or don't have a strong opinion.)

 George Danezis <gd@theory.lcs.mit.edu> wrote:
>
> I truly believe that there is a clear need (we may have mentioned before) 
> for a policy language where each mix puts: signature keys, encryption 
> keys, expire dates, mixes it peers with, modules installed, some stats on 
> latency and anonymity. Then we need a mechanism to parse this language and 
> produce candidate routes, given some inputs (minimal) from the user. It 
> would also be nice (wish list) to be able to get the anonymity set of the 
> network from these policy files.

This is interesting.  My first question is: can we make sure that this will be 
outside of the Mix Core module, so that George can finish defining it and we can 
proceed to implement it?

If the user makes all decisions about the node chain (which seems good and 
proper to me), then all of this policy file stuff can be encapsulated in the 
trust management module and we can proceed on the Mix Core module.


> > - What do I need in order to implement?
> >   - For now, I need a spec more than anything.
> 
> The spec should be ready by Friday, for you, my dear friends, to comment 
> on. 

Whoo-hoo!

> It contains pseudo code for processing the 
> packets (That should go up to Andrei for proof)

Andrei who?

> The crypto we are using is Standard NIST stuff (SHA-1, Rijendal) and 
> PKCS#1 RSA-OAEP (Maybe modified a bit) encryption and RSA PSS signatures.
> Maybe there are some libraries around that implement them.

Yes there are!  That "maybe modified" part might require a bit of tinkering, but 
everything else is probably all implemented already.  In addition, we could 
probably persuade Wei Dai (maintainer of Crypto++ [2]) and Ben Laurie 
(maintainer of OpenSSL [3]) to integrate any well-justified tweaks that we 
desire.

Regards,

Zooko

[1] http://sf.net/projects/egtp
[2] http://cryptopp.com/
[3] http://openssl.org/

---
                 zooko.com
Security and Distributed Systems Engineering
---