Email encryption for the wider public

Cathal Garvey cathalgarvey at cathalgarvey.me
Fri Sep 19 04:43:33 PDT 2014


> Regarding the memorability issue, all I can say is that end-to-end
> encryption really does require sharing 100+ bit keys - it's essential!
> You may be able to memorise your email address at the moment, but
> that's only half the story, since you can't memorise your public key!

But you can memorise a passphrase and email address, and generate your
public key on the fly using key generation algorithms like the one used
in miniLock/deadLock. This deterministic key approach has its
disadvantages, but it addresses two key issues with PGP:

1) Your key doesn't exist when you're not "logged in" to a program
implementing the standard, so it can't be scooped and
brute-force-decrypted by an evil maid or the later installation of a
rootkit.

2) When out with friends, if you discover a friend who likes crypto or
convince someone else to try it, you can generate your pubkey on the fly
by "logging in", either on your own computer or theirs. Yes, this
transiently generates your private key on potentially untrusted
hardware, so it's a risk that must be carefully measured.

I think the "mail encryption for all" problem is entirely crackable. I
feel this would be trivial if we'd accept encryption tied to particular
devices, because that would hand off entirely the key management issue.
But, we don't want to be tied to particular devices, so we end up with
stupid problems like OTR keys that are different between phone and
laptop, or PGP keys not trusted on a phone, so can't decrypt. Key
generation on the fly helps to some extent, but it's hard to patch into
an existing system.

It would be nice if some future "email" was an entirely on-the-fly
affair; "logging in" deterministically generates a keypair *and* the
address in a DHT to visit to collect your most recent mail. Same process
on any device, uses proven primitives. With some UX to forbid weak keys
(like the key strength checker in miniLock) and a well designed, costly
key derivation function, you're pretty secure, and your mail can be
stored in plaintext or kept encrypted locally at the option of the
implementor or user.

On 19/09/14 10:33, Henry Augustus Chamberlain wrote:
> Hi all,
> 
> Some very interesting points so far. To avoid making this email too
> long, I'm going to reply without quoting - I hope this doesn't
> inconvenience anyone.
> 
> Regarding the memorability issue, all I can say is that end-to-end
> encryption really does require sharing 100+ bit keys - it's essential!
> You may be able to memorise your email address at the moment, but
> that's only half the story, since you can't memorise your public key!
> I can't solve every problem with PGP, but I still think this proposal
> solves a fair few of them. In some cases it improves on PGP, and in
> the other case it's at least no worse: you can still use online
> institutional directories etc if you want.
> 
> Don't forget all the advantages this scheme could bring! Simplicity
> and transparency for the end user is really important! They're more
> likely to understand the significance of a public key if it forms part
> of the address (despite not understanding why it has to be this way).
> 
> Perhaps it doesn't help Derek's mum - nor my mum, for that matter -
> but there are plenty of people for whom PGP is to complex whereas this
> scheme would be manageable. If you wish, you can send some emails
> encrypted and others unencrypted, just like you can with PGP - in this
> case, you'd just need two addresses (which is surely no worse than
> PGP, where you have an address and a key).
> 
> Regarding telephone conversations: if it's with a mobile phone,
> perhaps a text message would work; if it's a landline, you probably
> have internet access, so an initial unencrypted email would work if
> you're not worried about man-in-the-middle attacks. (If you are
> worried about such attacks, then a bit of effort might be required,
> beyond just rattling off a short email address over the phone.)
> 
> By the way, I'm suggesting printable characters to encode the key, not
> arbitrary bytes. An alphanumeric character stores nearly 6 bits (or 5
> if it isn't case-sensitive), so 256-bit keys would require around 50
> characters. Email standards allow 64 characters for the local part of
> the address, so there's room for error-correction too.
> 
> Regarding the point about forged email addresses: for cryptography to
> work, you need to identify people using their keys, not their
> addresses. With PGP, you could send an email to my mum, using my email
> address but the wrong signature; if my mum is just relying on the
> email address, then that defeats the purpose of PGP. Of course, most
> PGP systems compare the key with that stored in the address book; a
> similar system can be used for my proposal, but with the advantage
> that forged emails don't give rise to the situation where the address
> is known but the key is unknown, which might lead a naive user to
> assume something's broken with the crypto software.
> 
> Regarding webmail... I still haven't solved that one. Maybe there's an
> inherent contradiction in trying to include webmail in an end-to-end
> encryption system.
> 
> I like the idea of using the "address+key at gmail.com" technique,
> although it does contradict the idea of "identify people using the
> key, not the address". Also, in my original proposal, I suggested
> using the private key (instead of a password) to login to the email
> server. I reckon Gmail is unlikely to allow that in the near future :)
> 
> Best wishes,
> 
> Henry
> 

-- 
Twitter: @onetruecathal, @formabiolabs
Phone: +353876363185
Blog: http://indiebiotech.com
miniLock.io: JjmYYngs7akLZUjkvFkuYdsZ3PyPHSZRBKNm6qTYKZfAM
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x988B9099.asc
Type: application/pgp-keys
Size: 6176 bytes
Desc: not available
URL: <http://lists.cpunks.org/pipermail/cypherpunks/attachments/20140919/a486bdfd/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cpunks.org/pipermail/cypherpunks/attachments/20140919/a486bdfd/attachment-0001.sig>


More information about the cypherpunks mailing list