Am Sa 19.07.2014, 01:42:19 schrieb Ingo Klöcker: > 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.)
Yeah and this works the other way round, doesn't it? Doing nothing about the GUI will finally magically improve the situation... https://bugs.kde.org/show_bug.cgi?id=318005 (Please not that this was written before the Cryptoparty community became well known.) > 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. Yes, until someone decides to combine this with kwallet... > How this additional inconvenience is going to win us > more OpenPGP users is beyond me. That is quite easy to understand though: As the handling of asymmetric keys is easier (and the "encrypt symmetrically" feature would point the user at this fact every time) there is a certain pressure upon the user to switch to asymmetric keys. Is there any easier solution with symmetric encryption? Sometimes poeple are told to use encrypted ZIP archives. I have no idea how often this is done. But this is a "how big is your desire to encrypt this email?" problem. If the user wants it encrypted then he will enter the password. If people who are not prepared to use asymmetric crypto (those 99%) want password encryption in a certain situation then I don't want them to have to use something different from OpenPGP. I don't want them to have an "This big thing can't even handle password encryption" experience. I want them to have a "This can handle password encryption but it can do better and more convenient if you spend some time learning how" experience. > 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. It does work. It seems not to work with Thunderbird/Enigmail though. But maybe I have done something wrong. The Enigmail console output looks good to me... I have prepared a mail file for those who want to give this a try: http://www.crypto-fuer-alle.de/docs/mail-symmetric/mail.cr-lf.eml > 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? The only thing I want to prevent them from doing is using some other technology for symmetric encryption. I am not going to advocate this as "the way to go". It seems to me that you (and Rob) are completely missing the intention. > And what's your threat model, i.e. what do you want to achieve by your > symmetric email encryption scheme? Same answer: This is for users who don't need any threat model consideration. What do you think what the computers of people who didn't care to create a key pair yet look like? Stronger crypto is the last thing they need. Even bad crypto is the most secure part of their digital life. I don't want to achieve anything technical by this. I want to achive something social by this. I want to exploit people's familiarity with passwords for pushing them in the right direction. > [PGP 2.6.3i User's Guide] > Since the same person that encrypted the file will also > decrypt the file, public key cryptography is not really necessary. Doesn't make any sense to me. If I encrypt data for myself then I encrypt it for my own key. The exception to this rule is data which may be needed on systems which don't have my private key installed. And that's precisely the same for my proposal: It's for encryption for people who don't have a private key at all. > 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. And you are probably right if the number of emails or contacts exceeds a certain value. But this is probably not how users act. They will not try to understand both systems in order to calculate what is easier (in the long run). They will compare a) install software and do something I understand (password) with b) install software, configure software which I don't understand and do something I don't understand (asymmetric key handling). I bet the majority of the 99% prefers to start with (a). This is a smaller step which prepares them for the next one (which has become smaller due to their getting familiar with encryption). > 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. I am in no way trying to prevent you from developing that. I don't understand what this comparison shall be good for. That would be relevant if using resources for implementing mine would prevent yours from being done. But the resources used for this thread already would probably be enough for implementing mine. > > 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. You didn't understand that my remark was a reply. I wouldn't dare to ignore Robert's questions anyway... His question – as I understand it – was completely unrelated to my proposal as he criticized something that would never happen. He argued with the behaviour of a group who is not supposed to use this feature at all. > See above. Yes, more effort to implement, but magnitudes less > additional effort to use OK when will it be there? Five years from now? Mine could be there tomorrow. How many new users would be generated by my proposal over the next five years? I don't even believe that using crypto must become easier. Using it on average level is already easier that more or less everything you learn at school. I guess the solution is educating the people. Not because of technical difficulties but because of laziness and group effects. even if your idea is ready one day then people will still have to learn to do it the right way. Hauke -- Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5
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