4 ms·

If you care about metadata encryption or being selected for targeted attacks this is horrible. The nsa and other actors that inspect email traffic for non-legal

If you care about metadata encryption or being selected for targeted attacks this is horrible. The nsa and other actors that inspect email traffic for non-legal reasons love PGP [1]. You can't encrypt metadata with it, it doesn't matter what you do, the MTA's and other mail servers add header fields tha not only uniquely identify sender and recipient but details about the conversation and attachments. Email was insecure, but ovet decades features were piled onto it. Then people started trying to secure it. Now it's a dangerous protocol, that leaves users with a false sense of security. There is no way to properly secure email, you can improve email security but you should never use it in place of something modern. I am routinely shocked about how modern tech companies treat email. One finance related tech company was shocked when I refused to send PII to authenticate myself in order to make account changes over unencrypted email. At least this chat thing uses PGP. I am at a point where I am thinking of conspiracy theories about all the chat protocols these days. Either they have a small but critical flaw in the confidentiality property or they have non-obvious metadata collection that can be used to identify targets for additional targeted attacks against their device. I still haven't found a chat app/protocol I can trust. [1] https://www.theregister.co.uk/2016/01/27/nsa_loves_it_when_you_use_pgp/ https://www.theregister.co.uk/2016/01/27/nsa_loves_it_when_y...

0xdeadb00f 6y ago
> The nsa and other actors that inspect email traffic for non-legal reasons love PGP [1] Hey! You didn't actually link to [1] ! ;)
- badrabbit 6y ago
  Sorry, just updated. :) https://www.theregister.co.uk/2016/01/27/nsa_loves_it_when_you_use_pgp/ https://www.theregister.co.uk/2016/01/27/nsa_loves_it_when_y...
asdkhadsj 6y ago
Shame, really. I love distributed P2P applications built around dumb, simple techniques or tools. Super complex abstractions are useful but as a project creator it's difficult to rely on new technology if you can't support it yourself. Email is one of those dumb, old systems I've often wanted to push a ton of stuff into. Ala' the days of Twitter and SMS, The role of email and how widely it's used just seems perfect for dumb distributed applications... if not for the issues you cited.
- badrabbit 6y ago
  There are dumb systems you can use, email just happens to be ill suited. Netcat+gpg comes to mind.
u801e 6y ago
> MTA's and other mail servers add header fields tha not only uniquely identify sender and recipient but details about the conversation and attachments. That really depends on how the server is configured. If the servers used are under the participants' control, then other than Received headers, nothing else should be exposed if the client does not include or encrypts the headers in addition to the body. So, if the sender were to send an email using the following SMTP session: EHLO random_string MAIL FROM: <random.email@addr> RCPT TO: <recipient@email.addr> DATA <PGP BLOCK> . then other than the received headers that are added by the MTAs, it wouldn't expose much information at all.
- badrabbit 6y ago
  Even if you control your mail server, all of your recipients will also need to run their own mail server. and even then they may slip up and add X-headers. You will need to encrypt the subject and attachment names. If one recipient uses a different client/provider the whole scheme might fall apart. If you need everyone to run their own mail servers and a specific client then why bother with email at all?
  - u801e 6y ago
    > You will need to encrypt the subject and attachment names. That's why I specified that the DATA session should consist solely of a PGP encrypted block of text. This means that the headers and body are included and there's no unencrypted text in that phase other than the CRLF.CRLF that terminates it. This means that it wouldn't be possible for the MTA to determine what the subject or attachment names are. > If you need everyone to run their own mail servers and a specific client then why bother with email at all? TBF, the article has the following statement: >> Delta Chat doesn’t have their own servers but uses the most massive and diverse open messaging system ever: the existing e-mail server network. It can't be considered open if everyone is just using the big mail providers.
    - badrabbit 6y ago
      There is a Subject header outside if the data section. Some clients add on variations of it or a "thread id" ,"coversation" and such.
wyck 6y ago
Ya I agree, I wonder what happened to lavabit's dark mail server / client, they got funding but the development seems to have stalled years ago.
dane-pgp 6y ago
Fortunately there is work being done on standardising the encryption of message headers when using PGP: https://datatracker.ietf.org/doc/draft-autocrypt-lamps-protected-headers/ https://datatracker.ietf.org/doc/draft-autocrypt-lamps-prote... It should be possible to go a step further, though, if mail providers offered a well-known reserved address like switchboard@domain which Alice could send an encrypted email to, and it would decrypt it to determine that the intended recipient was bob@domain. Ideally, Alice's mail provider would rewrite the sender headers to something generic too, relying on Bob to extract those from the email he decrypts. That way the sending server would only know the recipient server (not the local-part of the recipient address) and the recipient server would only know the sending server (not the local-part of the sender). Of course, this would make server-side spam filtering much harder, so it would benefit from some sort of bearer token system for bypassing such filters. The Autocrypt standard already uses special headers for signalling state between sender and recipient, but this header would require the mail provider to detect the new header and change their filtering rules based on it.
- rakoo 6y ago
  And it should be noted that DeltaChat is the most complete Autocrypt implementation, so metadata _is_ encrypted (albeit not all of it)
zajio1am 6y ago
> the MTA's and other mail servers add header fields tha not only uniquely identify sender and recipient but details about the conversation and attachments. Well this is misleading. While is true that PGP has non-ecrypted header files, MTAs/servers cannot add significant details about conversation, because they do not have any other information that is not already publicly known. Some non-encrypted details about conversation (e.g. In-Reply-To header) is unencrpypted, but added by originating mail client, not server. Subject is also well-known to be unencrypted. Attachments, their content, types, filenames and lengths are all parts of messaged data (in OpenPGP) and are therefore encrypted.
blackrock 6y ago
> you should never use it in place of something modern A lot of complaints here, but no actual substance. Exactly what modern tool do you suggest here? And why is it even better? All of the tools today seem insecure anyways.

0xdeadb00f 6y ago

> The nsa and other actors that inspect email traffic for non-legal reasons love PGP [1] Hey! You didn't actually link to [1] ! ;)

badrabbit 6y ago
Sorry, just updated. :) https://www.theregister.co.uk/2016/01/27/nsa_loves_it_when_you_use_pgp/ https://www.theregister.co.uk/2016/01/27/nsa_loves_it_when_y...

asdkhadsj 6y ago

Shame, really. I love distributed P2P applications built around dumb, simple techniques or tools. Super complex abstractions are useful but as a project creator it's difficult to rely on new technology if you can't support it yourself. Email is one of those dumb, old systems I've often wanted to push a ton of stuff into. Ala' the days of Twitter and SMS, The role of email and how widely it's used just seems perfect for dumb distributed applications... if not for the issues you cited.

badrabbit 6y ago
There are dumb systems you can use, email just happens to be ill suited. Netcat+gpg comes to mind.

u801e 6y ago

> MTA's and other mail servers add header fields tha not only uniquely identify sender and recipient but details about the conversation and attachments. That really depends on how the server is configured. If the servers used are under the participants' control, then other than Received headers, nothing else should be exposed if the client does not include or encrypts the headers in addition to the body. So, if the sender were to send an email using the following SMTP session: EHLO random_string MAIL FROM: <random.email@addr> RCPT TO: <recipient@email.addr> DATA <PGP BLOCK> . then other than the received headers that are added by the MTAs, it wouldn't expose much information at all.

badrabbit 6y ago
Even if you control your mail server, all of your recipients will also need to run their own mail server. and even then they may slip up and add X-headers. You will need to encrypt the subject and attachment names. If one recipient uses a different client/provider the whole scheme might fall apart. If you need everyone to run their own mail servers and a specific client then why bother with email at all?
- u801e 6y ago
  > You will need to encrypt the subject and attachment names. That's why I specified that the DATA session should consist solely of a PGP encrypted block of text. This means that the headers and body are included and there's no unencrypted text in that phase other than the CRLF.CRLF that terminates it. This means that it wouldn't be possible for the MTA to determine what the subject or attachment names are. > If you need everyone to run their own mail servers and a specific client then why bother with email at all? TBF, the article has the following statement: >> Delta Chat doesn’t have their own servers but uses the most massive and diverse open messaging system ever: the existing e-mail server network. It can't be considered open if everyone is just using the big mail providers.
  - badrabbit 6y ago
    There is a Subject header outside if the data section. Some clients add on variations of it or a "thread id" ,"coversation" and such.

wyck 6y ago

Ya I agree, I wonder what happened to lavabit's dark mail server / client, they got funding but the development seems to have stalled years ago.

dane-pgp 6y ago

Fortunately there is work being done on standardising the encryption of message headers when using PGP: https://datatracker.ietf.org/doc/draft-autocrypt-lamps-protected-headers/ https://datatracker.ietf.org/doc/draft-autocrypt-lamps-prote... It should be possible to go a step further, though, if mail providers offered a well-known reserved address like switchboard@domain which Alice could send an encrypted email to, and it would decrypt it to determine that the intended recipient was bob@domain. Ideally, Alice's mail provider would rewrite the sender headers to something generic too, relying on Bob to extract those from the email he decrypts. That way the sending server would only know the recipient server (not the local-part of the recipient address) and the recipient server would only know the sending server (not the local-part of the sender). Of course, this would make server-side spam filtering much harder, so it would benefit from some sort of bearer token system for bypassing such filters. The Autocrypt standard already uses special headers for signalling state between sender and recipient, but this header would require the mail provider to detect the new header and change their filtering rules based on it.

rakoo 6y ago
And it should be noted that DeltaChat is the most complete Autocrypt implementation, so metadata _is_ encrypted (albeit not all of it)

zajio1am 6y ago

> the MTA's and other mail servers add header fields tha not only uniquely identify sender and recipient but details about the conversation and attachments. Well this is misleading. While is true that PGP has non-ecrypted header files, MTAs/servers cannot add significant details about conversation, because they do not have any other information that is not already publicly known. Some non-encrypted details about conversation (e.g. In-Reply-To header) is unencrpypted, but added by originating mail client, not server. Subject is also well-known to be unencrypted. Attachments, their content, types, filenames and lengths are all parts of messaged data (in OpenPGP) and are therefore encrypted.

blackrock 6y ago

> you should never use it in place of something modern A lot of complaints here, but no actual substance. Exactly what modern tool do you suggest here? And why is it even better? All of the tools today seem insecure anyways.