Re: Notes from Conversation with Roger

[Nick Mathewson <nickm@reputation.com>]

On Thu, 2002-03-21 at 09:19, George Danezis wrote:
  [...]
> <political content> 
> I think the best response to this is that you cannot 
> make technology impossible to abuse. Particularly when abuse is 
> such an ill defined term. Someone who want to send a 
> threatening message of less than 1k can print it on a piece of paper leave 
> it on someone's door or even post it. Its funny that they are still looking 
> for the guy (or girl) who was sending the anthraxed mail! 
> So what we should emphasize is that MixMinion is not the weakest link in 
> the world, and if you really want to send threatening messages you can do 
> it with less hassle in other ways.
> </political content>

<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>

 
 [...]
> > - Client software should gripe about sending documents in formats like 
> >   MS Word.  Word documents are less anonymous than people think.
> 
> We should certainly make a note in the documentation but I do not think we 
> should go as far as filtering content, to check if people have included 
> their names. Do not forget: in most "institutional" applications, where 
> for example Reuters HQ wants to communicate with an undercover 
> investigative journalist in Angola. The two communicating parties are 
> quite happy knowing who each other is, but no one in the middle should be 
> able to make a connection.

I agree that filtering content is not worth it, but still believe that
users ought to be warned if they're using a format (like Word) that may
leak more information than they intend to leak.

Better IMO to warn people who can afford for recipients to learn their
identities, than not to warn people who want to be anonymous to
recipients.


 [...]
> >    STRATEGY NOTE 4: We should keep the trust network human for now.
> >    We should track performance of nodes, but let humans decide how to
> >    choose paths.
> 
> As I said before I would rather have an automatic generation for random 
> routes, or at least a validator of routes against server policies.

This is reasonable, and probably a good idea for testing, anyway.  What
I think Roger was arguing against was trying to build a full-blown,
performance-based trust analysis system.

 [...]
> >    STRATEGY NOTE 7: We should only include legitimate, legal, generally 
> >    positive examples in our documentation.  (e.g., let's not write 
> >    "Alice wants to hire a hit-man named Bob to kill Carol, who sold her 
> >    some bad heroin."  Let's stick to "Alice wants to tell an 
> >    investigative journalist named Bob about the bogus accounting 
> >    practices of her employer, Carol."  It's not that the former 
> >    necessarily makes us legally liable: it's just bad PR.)
> 
> Both examples above are criminal in some jurisdiction. Generally it is 
> safe to assume that
> 
> THEOREM 1: For every action A there exists a jurisdiction B in which A is 
> illegal or immoral.
> 
> Therefore I do not think we should be too bothered, but I agree that we 
> should emphasize the "good" use that MixMinion could have.

Agreed.  The use of anonymity itself is illegal some places, so we'll
not be able to keep everybody happy.  Nevertheless, it's best to present
ourselves as the idealistic, responsible lot that we are.  This isn't
just for PR reasons: if Mixminion seems unsavory, fewer people will use
it--and thus those who do will have smaller anonymity sets.


> >    OBSERVATION 11: End-user convenience is inversely proportional to 
> >    resistance against adversaries who can get access to your computer.
> >        - In this case, saving messages is a no-no.
> >        - Preference files are evidence, esp. if they name names.
> >        - We should provide client software that works for users with 
> >          these needs and for users without them.
> >        - An intermediate option is to encrypt such data, as GPG encrypts
> >          keyrings.
> 
> Full system integration with other tools that provide privacy and 
> anonymity is outside the scope of this project I feel. I think we should 
> concentrate on the security and robustness of the communication and let 
> other people construct the (A)inux OS that integrates MixMinion as default 
> (and only) way of talking to the outside world, the steganographic file 
> system, Tempest fonts, and the halt and self destruct button on the front.

Oh, I agree.  It _is_ a secret goal of mine that the reference
implementation be good enough for nearly everyone... but since we're
only going to get the features people bother to implement, I think we're
safe from having a steganographic turnip twaddler any time soon.

 [...]
> <Advertisement>
> The spec is a simplified and rewritten version of the previous spec, 
> reflecting our discussion. It contains pseudo code for processing the 
> packets (That should go up to Andrei for proof), and a detailed 
> description of the MMTP (MixMinion Transport Protocol) that is a forward 
> secure channel, with cashed keys, that even if compromised would require 
> the baddies to look at all communication to decrypt it (this should go 
> through some protocols people around here for verification)! 
> </Advertisement>

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

> >   - Soon, we'll need to discuss licensing and strategic decisions.
> >   - I'm putting off writing crypto and net stuff; I'll have to do so
> > soon.
> 
> 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. Otherwise 
> contributing open source libraries doing these is by itself a valuable 
> contribution.

Oh, the great thing about standards is that there are so many to pick
from.  There are already a nice handful of Python wrappers for OpenSSL
and kin.

BTW, what's the PRNG?

-- 
Nick