Live data from Hacker News

How to make e-mail encrypted for everyone

friendlybit.com

41–47 of 47 posts

Re: How to make e-mail encrypted for everyone

#43

As many others have pointed out - this doesn't keep the email encrypted from the providers at either end. We're already basically there for what this is suggesting - opportunistic TLS between providers is so high that the only sites that aren't doing it are the ones who aren't going to be deploying any new solution either. And it still requires secure DNS to avoid being MITM degraded. Once you assume secure DNS is re…

Please see the other comments to find lots of real world examples of people sending unencrypted e-mail via their ISP without knowing about it. These are the audience for these kinds of ideas, not people that already have PGP installed. I don't see where you got that idea from?

Re: How to make e-mail encrypted for everyone

#44
post #22

Earlier quoted context omitted.

I don't think this is about inventing a new protocol. It's about getting Gmail and Thunderbird on board. Has anyone put them in a room together?

Yes, we all got together this week in Paris.

Who do you represent? Who got together?

Re: How to make e-mail encrypted for everyone

#46
post #36

Key management also needs to get a lot simpler and there need to be best practices! If I only have one key for everything, it's quite dangerous for the key, because it must be on all my devices. If I create a key for each device though, how do you know which key to use? And the more keys I create the more I need to remember which is for which, when to replace one, etc. Last but not least it is REALLY HARD to erase st…

In p≡p there's both, automatic key management and a KeySync protocol (yet being tested, not activated already) to sync private key material across the devices you want to read the same messages on.

See the source code on that:

- https://letsencrypt.pep.foundation/trac/browser/asn.1

- https://letsencrypt.pep.foundation/trac/browser/sync

As you say correctly, of course you've to take care: as a common denominator an id is used, in case of e-mail a certain mail address, whose e-mail channel for communicaion functions as the key exchange channel, too (meaning the devices send themselves messages ("beacons"), which are considered as technical messages by the p≡p engine and thus never shown to the user as such).

=> If you fear to have a cell phone hacked or lost, it's better to not put that in a device group. Also you can seperate business from private accounts or have different accounts and on top of that aliases for whatever purposes, referencing the same id (mail address). In short: you can have (like mostly today) no device group at all or just different device groups meeting your needs and "paranoia levels" (based on the trust you put in your devices).

The devices agree on a device group key pair, being the master key pair, still they sync all devices' private keys for that specific id, such that you can read all of your messages received on all of your devices (even if there were changing pubkeys in between used for encryption, because of your different devices, which were not yet synced in the past).

If a device is lost or stolen, that has to be manually signalized by one of the other devices in the device group and then the devices have to agree on an new device group key pair to encrypt their future communications (we're talking of PGP encryption here, so no forwad secrecy).

Re: How to make e-mail encrypted for everyone

#47

As many others have pointed out - this doesn't keep the email encrypted from the providers at either end. We're already basically there for what this is suggesting - opportunistic TLS between providers is so high that the only sites that aren't doing it are the ones who aren't going to be deploying any new solution either. And it still requires secure DNS to avoid being MITM degraded. Once you assume secure DNS is re…

> there's no "middleman" unless you are using an e-mail forwarding service

Each time an e-mail passes through an e-mail service that service is required to add a "Received" header to the e-mail. So you can easily check out of your real e-mails to see if you are using any middleman or not. The first e-mail I opened looks like this:

    Received: from exdb06.ug.kth.se (192.168.32.116) by exdb02.ug.kth.se
    Received: from mx5.kth.se (130.237.32.10) by exdb06.ug.kth.se (192.168.32.116)
    Received: from mx5.kth.se (localhost [127.0.0.1])
    Received: from mx5.kth.se ([127.0.0.1])
    Received: from buffalo.birch.relay.mailchannels.net (buffalo.birch.relay.mailchannels.net [23.83.209.24])
    Received: from relay.mailchannels.net (localhost [127.0.0.1])
    Received: from uscentral412.accountservergroup.com (ip-10-27-139-41.us-west-2.compute.internal [10.27.139.41])
    Received: from uscentral412.accountservergroup.com (uscentral412.accountservergroup.com [10.102.194.57])
    Received: from friendly by uscentral412.accountservergroup.com with local (Exim 4.87)
Post reply on HN