public-key: the wrong model for email?

[Bill Stewart]

At 10:19 PM 9/15/2004, Ed Gerck wrote:
>Yes, PKC provides a workable solution for key distribution... when you
>look at servers. For email, the PKC solution is not workable (hasn't been)
>and gives a false impression of security. For example, the sender has no
>way of knowing if the recipient's key is weak (in spite of its length)
>or has some "key-access" feature. Nonetheless, the sender has to use that key.

I don't understand the threat model here.  The usual models are
- Key too short - Obvious to the sender
- Recipient's machine is compromised
         - Not obvious to sender, but not fixable by email program
- Recipient is stupid and careless
         - Often obvious to sender, but not fixable by email program
- Recipient's Public Key generator system generates weak keys
         - Hard for sender to detect and work around
         - Usually requires extra work by recipient to obtain
         compromised software, unless mandated by Corporate IT Droids
         - Recipient can reduce risk by using open source software
- Recipient's Public Key generator mails copy of private key to 
keyserver.kgbvax.gov
         - Indistinguishable from previous case
- Recipient's Client Software mails copy of session key to ashcroft.kgbvax.gop
         - Indistinguishable from previous case
- Recipient's Email Client forwards incoming mail message plaintext
         disguised as bouncegrams or viruses.
         - Indistinguishable from previous case.
- Recipient's Secret Key is recipient's dog's name spelled backwards,
         written on yellow sticky note pasted next to open window,
         under the big mirror with a good view of recipient's keyboard and 
screen.
         - Not a software problem
- Recipient's Computer Disk automatically backed up to optical storage at night
         - No sense subpoenaing cyphertext when you can subpoena plaintext.

You're focusing on a relatively niche threat model,
unless there's some operational aspect here I'm missing.

If you wanted to do something fancy, you could insist that the
recipient send the sender a Diffie-Hellmann Half-Key,
which you use to generate a session key that you use for message encryption,
and transmit your DH half-key along with the encrypted message
for the sender to decrypt.  It's still subject to most of the same threats
as the RSA-like public-key model, though maybe it's a bit easier
to detect weak Diffie-Hellmann keys.  However, unless you want to
force the recipient to change their client interface,
the easier place to implement something is in their SMTP client,
and the obvious way to do that is some variant on SSL-SMTP.

If you _still_ want more control, set up a web server,
and instead of sending your actual secret message, send
Encrypt ( Key=Alice, Message="
         ----- BEGIN PGP SIGNED MESSAGE
         Alice - I've sent you an encrypted message at
                 https://bob.example.net/cookie123456.PGP
                 This URL will self-destruct in 5 business days.
                         - Bob
         ----- END PGP SIGNED MESSAGE
         ")

However, if Alice was using a compromised email client,
she could just as easily be using a compromised browser. 


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com