symmetric email encryption
kloecker at kde.org
Sat Jul 19 01:42:19 CEST 2014
On Friday 18 July 2014 17:20:27 Hauke Laging wrote:
> Am Fr 18.07.2014, 15:40:34 schrieb Ingo Klöcker:
> > > And, quite important: It would not require serious
> > >
> > > development effort as this possibility is built-in with GnuPGP.
> > I think you underestimate the development effort.
> That is easily possible. But what would have to be done (at least)?
> a) You need a new button.
Yeah. Let's add yet another button to the UI. Let's add an "Encypt
symmetrically" button and let's rename the "Encrypt" button to "Encrypt
assymmetrically". If we add enough buttons then users will eventually
start pressing them. (Sorry, for being sarcastic, but I really don't see
how adding another button can possibly improve the users' willingness to
use email encryption.)
> b) Pressing this button would replace
> --recipient 0x12345678 --encrypt
> in gpg terms – I am not familiar with gpgme but for obvious reasons it
> has to be quite similar.
There is a difference between symmetric and assymmetric encryption that
could make it a bit more difficult than simply calling a different gpgme
function. The latter doesn't require any user input, hence it can be
done synchronously. OTOH, the former requires user input, the password
to use for symmetric encryption, so it's advisable to do it
BTW, additionally to the above mentioned new button the user has to
press he also has to enter a password for each message he wants to send
encrypted. How this additional inconvenience is going to win us more
OpenPGP users is beyond me.
> > Besides, AFAIK, there is no standard for this.
> Of course, there is. Otherwise you would not be asked for a symmetric
> password for certain messages, would you?
This is for inline OpenPGP and that's not part of any standard about
email encryption I know of. Since you are also using KMail I invite you
to test whether KMail is able to decrypt symmetrically encrypted
OpenPGP/MIME messages out-of-the-box. It might just work, but I'm too
lazy and too tired to test this right now.
> > > Is there any reason *not* to support symmetric-only encryption in
> > > a
> > > mail client?
> > There are plenty of reasons.
> I would be satisfied with a single one.
> > I already mentioned the lack of a standard.
> > Then there's the problem of key exchange which you
> > completely ignore.
> Which I can easily ignore as it is out of the scope of message
> handling. How have users ever successfully exchanged encrypted ZIP
> archives without ZIP providing an infrastructure for key exchange...?
Probably by using the same trivial password for all encrypted ZIPs they
exchange with anybody. Which brings me to another issue I have with your
proposal: How do you want to prevent the users from using the same
trivial symmetric encryption password for all "encrypted" messages?
And what's your threat model, i.e. what do you want to achieve by your
symmetric email encryption scheme?
> Why does OpenPGP cover symmetric encryption without providing an
> infrastructure for symmetric key exchange...?
Let's check the PGP 2.6.3i User's Guide
Using Just Conventional Encryption
Sometimes you just need to encrypt a file the old-fashioned way, with
conventional single-key cryptography. This approach is useful for
protecting archive files that will be stored but will not be sent to
anyone else. Since the same person that encrypted the file will also
decrypt the file, public key cryptography is not really necessary.
To encrypt a plaintext file with just conventional cryptography,
pgp -c textfile
This example encrypts the plaintext file called textfile, producing a
ciphertext file called textfile.pgp, without using public key
cryptography, key rings, user IDs, or any of that stuff. It prompts
you for a pass phrase to use as a conventional key to encipher the
file. This pass phrase need not be (and, indeed, SHOULD not be) the
same pass phrase that you use to protect your own secret key. [...]
Apparently, Phil Zimmermann had a specific use-case in mind for
"conventional encryption". And this specific use-case does not require
any symmetric key or passphrase exchange with a second user. I doubt
that Phil Zimmermann meant "conventional encryption" to be used for
exchanging encrypted messages.
> Users are capable of exchanging sheets of paper or having phone calls.
> The typical ways for safe fingerprint exchange are safe enough for
> password exchange, too.
I very much disagree, but I think we have very different threat models
> This is not about offering a great new concept to the public but about
> making an already existing (on the file level) and easily
> understandable feature available for email with very little effort.
Little effort for whom? For the developers of email clients? Maybe.
Maybe not. For the users of those email clients? I don't see "coming up
with and exchanging passwords" as very little effort for the users.
Contrast this with my proposal: More effort for the developers, but, in
the extreme case where the mail client does everything automatically, no
additional effort at all for the user.
> > Related to this, you did not answer Robert's
> > question "if you already have a secure channel over which you can
> > send a key, why not just use that channel for your communications?".
> I not only read it but I think that I gave a quite precise reply to
No. You snipped this part of Robert's message and didn't reply at all to
it. Later you did give an answer to this question in your reply to Doug
Barton's message (who also pointed out that you "skated past" this
> > Instead of support for symmetric encryption I'd rather love to see
> There are many features which would be nice to have. What do you think
> how many orders of magintude this one is more effort to implement
> than my proposal?
See above. Yes, more effort to implement, but magnitudes less additional
effort to use (and in the extreme case even infinitely less effort
because "some non-zero additional effort to use" for your proposal
divided by "zero additional effort to use" for my proposal equals
infinitely more additional effort for your proposal).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the Gnupg-users