Re: Notes from Conversation with Roger

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

> <side note>
> This is a good point, but the fact came up that it's (in theory) harder
> to construct an anonymous paper letter than an anonymous electronic
> message.  If you don't want to have a paper message sent to you, you
> need to think about paper, envelopes, DNA from your saliva if you lick
> the envelope, the mineral content from your water supply if you moisten
> the envelope, fingerprints, handwriting, ink, typewriters, printers, the
> location from which you mail, and so on.
> </side note>
> 

I agree but the list you give is independent of the "labeling" of the 
transport medium. I foresee quite a few people using MixMinion who are not 
going to take enough precautions traced back for reasons outside 
MixMinon's control. 

> 
> Hmn.  I'm looking forward to seeing this.  You may want to include a
> rationale for using MMTP instead of SSL/TLS.
> 

Ok this is interesting... Here is the moral choice:

Ideally we would like the transport protocol to provide
- Forward secrecy (you cannot decrypt traffic from the past)
- Efficiency (you want to reuse some knowledge from the previous 
  discussion, so that expensive asymmetric encryption and signing 
  operations are not repeated).
- Permanent passive attack. (We would like to force the attacker, 
  even if they get the key to start with, to have to intercept and 
  process every message to keep up with the current keys).

MMTP is a protocol that does the above, but at the same time replicates a 
lot of the functionality of SSL/TLS (the bottom line is that they are both 
key exchange protocols + secure comms protocols). So if we go for this we 
will have to re implement 
(and reverify) the MMTP protocol. Of course we do not need a vast choice 
of cipher suites, export control stuff, renegotiation of keys ... so in 
fact it is simpler than SSL.

SSL/TLS is a fine protocol but does not exactly provide the features we 
want. You can start the connection with ephemeral Diffie Hellman keys and 
chuck them away (that provides forward secrecy) but then there is no 
efficient way of doing the key updating between records sent. Therefore 
the DH has to be repeated on each message to have full forward secrecy 
(expensive). The third property is not true either since an attacker that 
knows the key at any point can decrypt any part of the stream (in the 
future and the past, correct me if I am wrong).

The positive thing about SSL/TLS is that it is an extensible protocol! 
Therefore we should be able to create an new type of packet called "key 
update" and implement the above properties that are missing. 

Questions:
- How easy it is to hack OpenSSL to add a new record type, and define how 
it should be processed? (nick?) Are there any hooks to the library that 
would allow us to do this without getting our hands dirty?
- Can we hack it cleanly without modifying any of the standardized parts 
(I guess this is a question for me!)
- Can we make sure that it will still be secure? (I take care of that as 
well)
- How do people feel about the above choice between custom made vs. SSL? 
(no commitment - just feeling)

> 
> BTW, what's the PRNG?
> 

I know very little of what is on the market these days. What about Bruce's 
"Yarrow"?
http://www.counterpane.com/yarrow.html