[Freedombox-discuss] Email Encryption Basics

[Eugen Leitl]

On Fri, Nov 16, 2012 at 07:04:44AM -0600, Nick M. Daly wrote:

> For no reason I can explain, my box can send outgoing mail without issue
> (I haven't purchased or defined an MX record or smarthost, IIRC).  It

Are you on residential broadband? Do you have a dynamic address pool?
If still yes, then your pool might escape having been blacklisted.
For time being.

> can't receive anything at all, but mail goes out without problem, which

You will need unblocked port 25. If you're behind NAT, you will need
to forward the port 25 to your machine with the MTA, assuming your
provider doesn't block port 25.

> allows service signups and the like.  I'll try to figure out why I can
> send mail one of these days.
> 
> > Alternatively, the FBX could act as a PGP proxy for an existing email
> > account: the FBX would encrypt email before sending it to the existing

This is a bad solution, as you will need an email account with a
a third (corporate, subpoenable, gag-orderable) party, and will 
need to tell your FBX what smarthost or relay to use. StartTLS
doesn't help you if your relayhost is rotten.

If you want your FBX to be unaffected by third parties, you will
need a darknet, period. The sooner you get this, the sooner we
can move on and start implementing this.

> > account's SMTP server and decrypt it after collecting and deleting it

PGP doesn't scale due to key management issues, 
though there are nice ways like Steed http://lwn.net/Articles/464137/
http://code.google.com/p/gpg-mailgate/

Notice you will need a DNS substitute anyway (e.g. pseudo domain .fbx)
so you can use that to publish your keys for Steed.

> > from the existing account's POP/IMAP server. No email would be stored

Your IMAP server should be on your FBX.

> > long-term on the provider's servers, which is a legally important

Where we're going, we don't need provider's servers.

> > distinction in the US. The FBX would use Tor to store and retrieve PGP
> > public keys on multiple independently operated keyservers, making it

No. Use a DNS substitute to publish your keys. You will need it,
anyway.

> > difficult for any keyserver to replace a user's key with a MITM key
> > without detection.
> 
> Very interesting!  As long as we tie ourselves to someone else's
> infrastructure, re-serving as a client becomes easy.

This is a dead end approach. You should trust your ISP to route your
encrypted packets, that's it. In future, you'd rather add local LoS
mesh and other personally owned, and operated infrastructure.
Definitely look into Serval, Byzantium, DTN patched kernel, and so on.