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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users