symmetric email encryption

[Hauke Laging]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20140719/d94e8b41/attachment.sig>