[Cryptography] [cryptography] Email encryption for the wider public

Derek Atkins derek at ihtfp.com
Thu Sep 18 08:44:16 EDT 2014


Henry,

Henry Augustus Chamberlain <henryaugustuschamberlain at gmail.com> writes:

> On 17/09/2014, Maarten Billemont <lhunath at lyndir.com> wrote:
>>
>> I'm not sure I understand what problem you've just solved.  Senders still
>> need to generate a keypair and encrypt their mail, receivers still need to
>> decrypt their mail.  All you've done is remove key lookup and replaced it
>> with a From: header.
>>
>
> I haven't invented any new cryptography - functionally, it's similar
> to what already exists.
> But I think the reason that encryption still isn't widely used (after
> more than 2 decades!) is the usability. Even if encryption/decryption
> are automated, you still need to understand concepts like public keys
> and digital signatures in case something goes wrong.

You are correct in your observation, however I would argue your
conclusion is still wrong. After having worked on secure email for many
of the past 22 years personally, I can assure you that the issue is
absolutely usability.  However the issue is a combination of key
management and integration, and not with "naming".

> By combining the address and the public key, I think everything makes
> much more sense to the end user: when they send emails to some
> address, they know it can't be intercepted, and when they receive an
> email from some address, they know that it definitely came from there.

There is absolutely no way my mom could send me an email to
<KEYID>@dom.ain.  It's just not going to happen.  There's no way she
could type it in.  There's no way she could remember it.  Sure, once it
gets into her address book she doesn't need to remember it again,
however how does it *get* into her address book?

I'll also note that this is the idea behind HIP, and was also the basis
behind (IIRC) SPKI.  "The Key is the ID".  It works great for machines.
It doesn't work well for people.

Quick, without looking it up anywhere, what's your PGP Key ID?
Now, without looking it up, what's your email address?

I don't know about you but I can rattle off my email address over the
phone very quickly.  No way could I rattle off a keyID and make sure the
other person has it and, more importantly, can type it correctly.

> The encryption/decryption can be handled automatically by something
> like Enigmail, but now the user can easily understand the problem if
> something goes wrong: errors will say things like "this email didn't
> really come from that address", rather than "this digital signature
> doesn't match the key".

That's not the problem.  The problem is that most users out there are
using gmail, or aol, or yahoo, or... *gasp*  Outlook!  Enigmail doesn't
help any of those users.

Here's the issue:  The main email software vendors integrated S/MIME
into their applications.  It already exists in Outlook, Mail.App, and
probably most every major email system.  However S/MIME sucks from a key
management perspective exactly because "getting certificates is hard."

PGP is nice in that anyone can effectively click a button and viola,
they have a certificate.  However none of the mail systems support PGP
natively.

*THAT* is the problem that needs to be solved.  You need to convince
every MUA out there to make generating keys (and/or a certificate) as
easy as PGP, and also make encryption the default.  Indeed, you need to
get to a point where the MUA would pop up a dialog saying "You are about
to send email unencrypted.  Anyone (like the NSA) could read this.  Are
you sure?  y/N"

I recommend you go get Microsoft and Apple on board first.

Good Luck,

-derek

-- 
       Derek Atkins                 617-623-3745
       derek at ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant


More information about the cryptography mailing list