symmetric email encryption
mailinglisten at hauke-laging.de
Sat Jul 19 04:37:56 CEST 2014
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...
(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"
> 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:
> 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"
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
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
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)
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
> 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.
Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/
OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 490 bytes
Desc: This is a digitally signed message part.
More information about the Gnupg-users