[liberationtech] to encrypt or not to encrypt?

[Martin Uecker]

On 06/21/2013 10:00 AM, Eugen Leitl wrote:
> On Fri, Jun 21, 2013 at 06:51:11PM +0200, phryk wrote:
>> On Fri, 21 Jun 2013 11:55:57 -0400
>> Nadim Kobeissi <nadim at nadim.cc> wrote:
>>
>>> The solution to this is to make encryption more and more widely used.
>>> By increasing the number of people with access to encryption
>>> technology for their communications, we dilute this threat.
>> My thought exactly, just encrypt ALL THE THINGS and let those people
>> deal with humungous amounts of data, most of which will be completely
>> useless even if decrypted.
> You want it to happen, you get opportunistic encryption to happen
> on as a low level as possible, on as many devices as possible.
>
> Target consumer routers which run Linux or Freedombox-like
> devices. Sooner or later it will move to Android, other
> mobiles and desktops. Put it into the application layer.
>
Yes, securing the lower levels would seem to be an important long term goal.
But even if this is achieved, this will not provide any security 
benefits to an
average user who uses facebook/gmail/etc ...

In my opinion, the first priority should be to secure email. For a 
variety of
reasons:

- email is used a lot (also for important stuff)
- almost everybody has an email account
- email plays an important role for authentication of other services
   (passwords / links to reset passwords are sent by email)
- technology to secure email is readily available
- the importance to encrypt email is easy to explain
- if a lot of people start to encrypt their emails this would
   send a clear message and others might follow

The problem is not technical, it is education. Still, some changes in
email clients would help a lot:

- have crypto integrated (not as a stupid plugin deactivated by default)
- offer to create a key by default, educate the user at that time
- sign by default (or at least indicate in some header that you have a key)
- automatically download keys from a keyserver when receiving a signed email
- opportunistically encrypt if a key is available

- drop that broken web-of-trust model instead use the model used in ssh:
   warn about a possible MITM attack if the key has changed for some reason

Martin