how email encryption should work (and how to get it used...)

[Amir Herzberg]

I think this is a good summary of how it should work, except, that I 
don't think messages should be signed by default, only authenticated 
(MAC). Users should be clearly aware of making a non-repudable statement.

Plus, it may be preferable to use something like matasignatures.org to 
ensure authenticated e-mail does not alarm recipient with non-compliant 
e-mail clients.

A missing element is motivation for getting something like this 
deployed... I think spam could offer such motivation; and, I strongly 
believe that a cryptographic protocol to penalize spammers could be one 
of the most important tools against spam. I've presented such a simple 
crypto protocol (SICS) in SCN'04 [available off my site], and now work 
on open-source implementation (with student Jonathan Levi) of an 
improved version (SICSv2...), to be published soon. [I can send draft to 
experts willing to provide feedback...]

Best, Amir Herzberg

James A. Donald wrote:
>     --
> In my blog http://blog.jim.com/ I post "how email 
> encryption should work"
> 
> I would appreciate some analysis of this proposal, which 
> I think summarizes a great deal of discussion that I 
> have read.
> 
>     * 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 
>     be labelled with something intimidating like 
>     “Advanced custom cryptographic key management" so 
>     that 99% of users never touch it.
> 
>     * In the default case, the mail client, if there are 
>     no keys present, logs in to a keyserver using a 
>     protocol analogous to SPEKE, using by default the 
>     same password as is used to download mail. That 
>     server then sends the key for that password and 
>     email address, and emails a certificate asserting 
>     that holder of that key can be reached at that email 
>     address. Each email address, not each user, has a 
>     unique key, which changes only when and if the user 
>     changes the password or email address. Unless the 
>     user wants to deal with “advanced custom options”, 
>     his “from” address must be the address that the 
>     client downloads mail from – as it normally is.
> 
>     * The email client learns correspondent's public 
>     keys by receiving signed email. It assigns petnames 
>     on a per-key basis. A petname is also shorthand for 
>     entering a destination address (Well it is shorthand 
>     if the user modified it. The default petname is the 
>     actual address optionally followed by a count.)
> 
>     * The email client presents two checkboxes, sign and 
>     encrypt, both of which default to whatever was last 
>     used for this email address. If several addresses 
>     are used, it defaults to the strongest that was used 
>     for any one of them. If the destination address has 
>     never been used before, then encrypt is checked if 
>     the keys are known, greyed out if they are unknown. 
>     Sign is checked by default.
> 
>     * 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.
> 
>     * If the user is completely oblivious to encryption 
>     and completely ignores those aspects of the program, 
>     and those he communicates with do likewise, he sends 
>     his public key all over the place in the headers, 
>     signs everything he sends, and encrypts any messages 
>     that are a reply to someone using similar software, 
>     and neither he nor those he corresponds with notice 
>     anything different or have to do anything extra – 
>     other than that when he gets unsigned messages, or 
>     messages with an key different from the previously 
>     used key, a warning comes up – an unobtrusive and 
>     easily ignored warning if he has never received a 
>     signed message from that source, a considerably 
>     stronger warning if he has previously received 
>     signed mail from that source.
> 
>     --digsig
>          James A. Donald
>      6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
>      gOiN3HXQALAQHbKEOYdu/aZClRbPTEfjzyLpGAMx
>      4dJddm3vIwGuBnfc933djUV6zT4DWvM26KobmzFyC
> 
> 
> 
> ---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
> 
> .
> 

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