symmetric email encryption

[Ingo Klöcker]

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
> 
> by
> 
> --symmetric
> 
> 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 
asynchronously.

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.
> 
> Yeah
> 
> > 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 
(ftp://ftp.pgpi.org/pub/pgp/2.x/doc/pgpdoc1.txt).

=====
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,
type:

    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 
in mind.


> 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
> that.

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 
question) though.


> > 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).


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20140719/1492314a/attachment.sig>