how email encryption should work

James A. Donald jamesd at
Tue Mar 29 14:14:42 EST 2005

James A. Donald wrote:
> >     * The user should automagically get his
> >     certified key when he sets up the email account,
> >     without having to do anything extra. We should
> >     allow him the option of doing extra stuff, but
> >     the default should be do nothing, and the option
> >     to do something should

Ian G
> For clarity reasons, I think you mean that the default
> should be to not invoke the 'extra stuff' on automagic
> creation, rather than "do nothing"

I have amended the post to read, "the default should not
require any input or clicking or thought from the user" "How email encryption should work"

> it creates a dependency on a server that might not
> exist and even if a good idea, will take a while to
> prove itself.

On what basis then do we create the user's key?

If we create it from the password alone, then his
password can be dictionary attacked, so every signed
post reveals his password, reducing, not increasing, his
security.   If we automagically create a secret key
stored on his computer, then when he wanders over to
another computer, his key changes, surprising both
himself and those he corresponds with, resulting in mail
failures.  Hence my proposal that in the default case
the key be created based on a PDM server's reaction to
his password.

If we have message signed by a key based on a secret
file, we should not encrypt by default.  Perhaps the
default reply policy should be set in the accompanying
certificate, and if no certificate, signature implies
very little except message integrity and persistence of
identity - "this message apparently posted from the same
computer as the last message from <nickname>"

Of course, this could be remedied by explicitly changing
the semantics of petnames, that a petname corresponds to
a particular email address on a particular computer, but
that makes changes of petname too frequent,
unintentional, and to end users, surprising.

James A. Donald:
> >     * The email client learns correspondent's public 
> >     keys by receiving signed email.

Ian G
> The problem I've discovered with this is that the 
> signing of mail is (I suggest) not a good idea unless
> you have a good idea what the signature means.

It means whatever the certificate asserts that it means.
If the signature is accompanied by the certificate
described as the default case in my proposal "How email encryption should work:"
it means you are receiving mail from the someone capable
of receiving email at the sender's address, rather than
a phisher or a virus working through someone's address
book.  (To conceal the infection, viruses make the
"from" address anything in the address book except the
actual from address.)

This provides some immediate utility to the ordinary
user who does not care or know anything about
cryptography - ultimately resulting in signed email
being privileged in spam filters.  Banks will be able to
send out account information in email without being
blocked by spam filters, or setting up their users to be
scammed by phishers, or to have their identity stolen.

One minor problem with whitelists is that I have
frequently been under massive spam attack by virus
generated email supposedly originating from people I
know.   Aggressive whitelisting is going to lead, is
already leading, to aggressive purloining of social
network information to penetrate the whitelists.

> Which means that most people under most circumstances 
> should not send most emails out signed.  Which sort of
> makes "signed emails" a poor carrier pigeon for a key
> exchange.
> (I don't have a solution to this - just pointing out
> what I see as a difficulty.  The workaround is that
> the user turns off signing and has to send an explicit
> blank signed email as a key exchange message.
> Clumsy.)

Turning off signing by default may well be desirable,
certainly desirable if one lacks a certificate that
provides added value to the signature - but any key
exchange is clumsy - making signed letters a key
exchange mechanism that is relatively transparent to the
user.  We could have a mechanism whereby the user
explicitly injects the public key into the email,
thereby turning on the encryption default - but this
requires conscious thought, understanding, and effort. 
I was looking for automatic encryption.  It just works,
so long as both clients are using the same protocol, and
no one has to do anything

If the user is going to send the public key explicitly,
to turn on encrypted communication, then there needs to
be a checkbox "Request encrypted reply" - and if you
request encrypted reply, you automatically send a public
key in the header, but no signature is required.  The
user knows that the only person who can receive his
reply is the person he replies to, but does not
necessarily need to connect that identity to some other

Of course if our goal is not "encrypt everything", but
rather "allow the user to encrypt some few things", then
of course we just use local keys, with no certificate. 
If there is no certificate, then as you suggest the
signature has no semantics, and should not be presented
to the user as a signature, but merely as message
integrity, and we warn the sender requesting an
encrypted reply that the secret key to read the reply
email is stored in a file in such and such a location on
his computer.

My goal was, however, "encrypt everything", much as
paper letters about my family, my niece, and our holiday
in Hawaii are routinely signed and routinely sent in
envelopes.  Unless we have an "encrypt everything"
policy, our system is only going to provide benefits to
the small minority that understand encryption, care
about it, and think about it - which appears to be a few
dozen, insufficient to support decent software.

We need to provide benefits to the masses, without the
masses needing to understand, think about it, or care.

If the client fails to contact the keyserver, we could
fallback from "encrypt everything using a public key
based on the other guys password strengthened through
PDM", to "encrypt selected messages using a public key
based on the other guy's secret file".

The secret file has a transient identity.  Absent a
(possibly self signed) certificate asserting otherwise,
it is assumed to go away quickly, merely proving that
the reply to one letter can only be read by the same
person who sent the previous letter - providing secrecy
and continuity within a particular email thread, not
lasting and long lived identity, hence no petname for a
key without a certificate.   We don't expect the same
person to hold the same uncertified key for very long,
easy to make, easy to discard, hence of limited value
for resisting viral spam and phishing impersonation
attacks, and for securing identity information sent in
email, which is the main added value we can provide for
Joe sixpack. Burmese freedom fighters are a pretty
limited market.

James A. Donald:
> >     * The signature is in the mail headers, not the 
> >     body, and signs the body, the time sent, the 
> >     sender's address, and the intended recipient's 
> >     address. If the email is encrypted, the
> >     signature can only be checked by someone who
> >     possesses the decryption key.

Ian G
> I had an entertaining read of the paper on Naive Sign
> & Encrypt last night.  There are a lot of issues in
> how signatures are combined with encryption, I don't
> think this is a solved issue by any means when it
> comes to email.

A google for "naive sign and encrypt" turns out rather
too many hits.  To what are you referring?

> When cryptograpers say a message is signed, users 
> think that a message has been signed....  getting 
> around that confusion is quite hard.

Ink signatures are closely associated with the person,
and generally persistent for the person's lifetime.
Computer signatures necessarily less so.

In the default case I describe above, the signature has
the semantics. "This email comes from someone who can
receive email at this address, and he is using the same
password as he did last time you received email from
him." - which should, I think, appear literally in the
certificate, or in url in the certificate referring to a
resource that the email client caches.

I have modified the blog post by adding a paragraph on
signature semantics.

         James A. Donald

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at

More information about the cryptography mailing list