Opportunistic Encryption [Was: Keys not trusted]

Per Tunedal pt@radvis.nu
Tue May 13 18:36:02 2003

Hash: SHA1

At 17:52 2003-05-13 +0400, you wrote:
 >On Sunday 11 May 2003 04:55 pm, Ingo Kl=F6cker wrote:
 >> IMO making the usage of unverified keys too easy (i.e. the user
 >> just has to click away a warning) will result in a weakening and a
 >> slower growth of the web of trust.
 >We should support web-of-trust
 >solutions (i.e. use OpenPGP), but we shouldn't ban opportunistic
 >encryption in order to force the growth of the Web-of-Trust.

Agree, but I do prefere the robot-CA model for "granny encryption".

 >1)  Keysigning parties are never going to catch on with the masses.
 >    It's an expensive operation.  Protocols that require expensive
 >    operations (purchasing a certificate, attending keysigning
 >    parties, etc.) will never catch on with the masses.


 >    In order to protect the masses, we need opportunistic encryption.
 >    Opportunistic encryption may not prevent active attacks, but it
 >    kills the common case (eavesdropping).  To eliminate active
 >    attacks, we have direct key signing, keysigning authorities
 >    schemes, and the Web-of-Trust.

Or rather a simple verification binding the key to the e-mailadress
like the robot-CA.

 >2)  As implemented today, the Web-of-Trust is bad for privacy.
 >    Advertising e-mail addresses combined with a list of your closest
 >    contacts (via signatures) works well for an authentication
 >    protocol, but it's not a good privacy protocol.

True, I'm waiting for the spammers to "tap" the key servers. It can be
done, that's why it will be done eventually. On this list there was a
discussion how to not put the "real" e-mail address in the UID of the
key, but rather a dummy e-mail address "changes@times.u.know.com"

That might be a problem with the robot-CA model!

 >Allow all forms of authentication including no authentication at all.
 >Make adding keys and creating local signatures, directly from the
 >mail client [with or without the help of an external program], as
 >easy as humanly possible.
 >3 Authentication Levels:
 >L1)  No protection (unencrypted, key not available)
 >L2)  Passive attack protection (encrypted, key not verified)
 >L3)  Active attack protection (encrypted, key verified)

I would like to add the robot-CA protection i.e. the e-mail address
connected to the key. (The robot signs the key, encrypts it and sends
it to the e-mail addresses in the UID:s of the key. Only a person
having access to both the e-mail account and the secret key can use
the signatures. http://www.toehold.com/cgi-bin/rcacgi )

 >The difference between (L2) and (L3) could be clearly visable to the
 >user with clever icons. I strongly believe that we can solve this
 >problem without confusing the user or giving them a false sense of


 >Outstanding Question:  How to pick an unauthenticated key?
 >If I'm replying to a signed message (and the reply-to address matches
 >a UID on the signing key), I would pick the key used to sign the
 >received message.  If I'm starting a new message, the choice is less
 >obvious.  When multiple keys with no trust path exist, David Shaw
 >proposes that we encrypt to all valid keys.  Shaw's solution kills
 >the common case of passive eavesdropping (i.e. it's better than what
 >we have now).  Refinements to Shaw's proposal using some form of
 >caching might be possible.

A robot-signature might be useful as it connects the key to the e-mail

 > - Yenot

Per Tunedal
Version: GnuPG v1.2.1 (MingW32)