While this does seem interesting (minus all the issues with PGP-encypted email), I did find this odd claim about PFS[1]:
> No, OpenPGP doesn’t support Perfect Forward Secrecy. Perfect Forward Secrecy works session-oriented, but E-Mail is asynchronous by nature and often used from multiple devices independently.
Yes, OpenPGP doesn't support PFS. But it's untrue that you need a session-based protocol to use PFS. The Signal protocol (and entire Noise family of protocols including things like WireGuard) beg to disagree.
No, the reason OpenPGP doesn't support PFS is that the design is fundamentally based around long-term keys -- even with separate short-lived subkeys you couldn't practially emulate PFS with PGP.
The proposal you linked is effectively a more formal version of the subkey PFS scheme I alluded to, though it looks like it tries to solve some of the issue with subkeys that make them not a good fit for PFS (though one issue I've had is that subkeys appear to be referenced by their index rather than their keyid, so deleting and replacing them can give you confusing messages on decryption).
> These use a dedicated key per device rather than per season.
For identity, not for encryption (in the PGP world this is the difference between the root key and subkeys -- though the root key cannot be used for encryption in this analogy).
The keys used for encryption are rotated incredibly regularly (for each message in the Signal case, and every two minutes for WireGuard). That is what PFS looks like in asynchronous protocols.
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.
> 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.
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.
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.
> 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.
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?
> 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.
MTAs, if configured correctly, do not talk to anything outside your network that is not specified by MX DNS records. Unless we are talking about emails traversing internal networks and even then competent admins do not transmit data in cleartext, so sniffing is out of question.
Of course, some metadata is always leaked, but that is the reality of most internet protocols, HTTPs notwithstanding. Now if we're talking about backdoors, it's a game over in any scenario.
I love the general idea of this. It is a way of introducing a chat application that is not controlled by some single behemoth. It can take advantage of other people's servers (via email), so there's no real cost associated with it like there would be trying to stand up a server for handling nearly any other protocol. I'm just not sold on PGP. I don't see a point of this as long as metadata leaks.
I wonder if you could do the same, but use usenet. Most usenet providers allow encrypted connections to their servers... But then people would have to have a subscription to usenet.
I really like the idea of this. For some applications it would be very useful assuming the implementation is up to it. Unfortunately, just reading the FAQ a see a few red flags. It doesn't allow importing encrypted keys. This is an automatic "nope" for me. Authentication is as big an issue as encryption, so I need to generate my own keys. But I'm not about to upload an unencrypted key to my phone.
Also, they kind of avoid talking about the very important issue that who you are talking to is not secret. Like I said, IMHO for some applications it's not a big deal. But for some applications it is a huge deal and it's pretty important to warn people up front.
This is not a replacement for Signal. Possibly with some work it could be useful in limited contexts. However it is important to understand that it can't be a replacement for Signal in general.
> Unfortunately, just reading the FAQ a few red flags. It doesn’t allow importing encrypted keys. This is an automatic “nope” for me.
This is answered in the FAQ:
Can I re-use my existing private key?
Yes. The best way is to send an Autocrypt Setup Message from the other e-mail client. Look for something like Start Autocrypt Setup Transfer in the settings of the other client and follow the instructions shown there.
Alternatively, you can import the key manually in “Advanced settings / Manage private keys”. Caution: Make sure the key is not protected by a password, or remove the password beforehand.
If you don’t have a key or don’t even know you would need one - don’t worry: Delta Chat generates one as needed, you don’t have to hit a button for it.
I think you missed the point GP was making. To quote:
> Unfortunately, just reading the FAQ a few red flags. It doesn’t allow importing encrypted keys. [emphasis added]
To which you responded with:
> Alternatively, you can import the key manually in “Advanced settings / Manage private keys”. Caution: Make sure the key is not protected by a password, or remove the password beforehand. [emphasis added]
GP is talking about it using a key which is encrypted with a passphrase, and it seems you agree that this isn't supported (otherwise why would it ask for you to decrypt the key on import?).
For Signal, sealed sender in theory makes some progress towards fixing this problem[1] but given the service fundamentally uses a central server, you could pretty easily figure out who is messaging who.
There was an experimental chat application called Ricochet[2] which used Tor hidden services to anonymise users' social graphs, but unfortunately that project is no longer developed for quite a while. Pond[3] was also a similar system (though it was designed to solve the email problem and also aimed to solve some of the timing attacks against Tor by being a delayed-message protocol).
I personally use Matrix[4] on my own homesever which appears to be the most privacy-preserving choice these days -- only the homeservers involved in a conversation ever see the messages. Unfortunately a lot of people use matrix.org as their homeserver (meaning they in theory have everyone's social graph) but for chats with most of my family and friends that isn't a problem (they are either on my homeserver or on their own).
> but given the service fundamentally uses a central server, you could pretty easily figure out who is messaging who.
How?
In Signal's design nobody ends up knowing this except the sender and recipient.
As a Matrix enthusiast with their own "Homeserver" what you're doing is basically like dressing in head-to-foot desert camouflage gear to stand in Times Square. I guess it does do something, but maybe not what you think it does.
> How? In Signal's design nobody ends up knowing this except the sender and recipient.
The most obvious one is fairly basic traffic correlation using the IPs and timing information. You can figure out which IPs are communicating with which recipients (because the recipient of a message is necessarily public to the server, the device connects to the Signal servers to send the message, and everything is routed through servers controlled by a single party) as well as the IPs of recipients. When combined with timing information and the knowledge that users are only going to be able to talk to at most a few people simultaneously, you find that two people in the same IP-based social graph sending messages with the other person as a recipient at the same time are probably talking to each other.
I'm not saying that Signal is doing this, I'm just saying that it is possible because of the design. This is basically the same reason why single-node VPNs cannot protect your anonymity against internal (and some external) threats and why something like Tor is needed to solve the problem. And note that this isn't even a slightly controversial statement -- it's even mentioned in the blog post announcing the "sealed sender" feature[1]:
> In particular, additional resistance to traffic correlation via timing attacks and IP addresses are areas of ongoing development.
We could argue about what "additional" means in this context, but given the design of the service I'm pretty sure they're just referring to their logging policies and Intel SGX usage.
> what you're doing is basically like dressing in head-to-foot desert camouflage gear to stand in Times Square
I don't understand the point you're making. If I'm talking in a public room, then obviously the messages are public. But if I'm only talking with folks on the same homeserver as me (or on homeservers they run) then only our homeservers know about our communications. Without tools like Ricochet there isn't (as far as I know) a way to get more metadata protection as easily. Don't get me wrong, it definitely isn't perfect and I wish it provided more protection -- but it is practically no worse than Signal in this respect (and it is significantly better for rooms that don't have :matrix.org users in them -- which is something I explicitly mentioned in my original comment).
> The most obvious one is fairly basic traffic correlation using the IPs and timing information.
That is made very difficult by Signal's volume. The more people use Signal and the more things they use it for, the harder it becomes to discern a meaningful pattern.
> I don't understand the point you're making.
No I sort of gathered, which is why I used the Times Square camouflage analogy. You stand out because you've gone out of your way to "protect yourself". That traffic correlation you were so excited might be possible for Signal is instead trivial for your personal homeserver with its handful of users.
You've gone out of your way to make yourself less safe because of a misunderstanding of the threat. It's very common.
Signal can't avoid learning who a message is for (the recipient) in order to deliver it but they can easily avoid learning the sender by not asking. The recipient will learn the sender by decrypting the message, in which the sender proved who they actually are.
The remaining problem for Signal was enabling this without spam. To do that recipients choose whether to tell everybody, or nobody or just people they know (the default) a key. Proving knowledge of this key is enough to send messages to that recipient. If you get messages you don't want, just block that sender, your key is rotated and they won't know the new key.
There are ways that they could know. It's not terribly easy, but I think it would be ingenuous to say it is impossible. With SMTP (which could easily be part of the delivery of email), it's in plaintext going over the public network :-)
This is an interesting proposal. However, there is still a small flaw to privacy, in respects to you making an account with an email attached. Many of us here will know how to make an anonymous email, but for new people and/or people who need to talk in suppressive regimes (that would be able to track back the account to the email it was created with), wouldn't be such a great idea. Although they will not be able to read the contents of the conversation because of the PGP encryption, in many countries, having suspicion of this can lead to torture.
Therefore, I still believe that Briar is the strongest in this. Each individual message has a different key, so if one key is compromised the whole conversation isn't exposed. Furthermore, the signup process us just a username and password - no need for email or phone number. Thus, making it far harder for regimes to track back to the source, especially if they are using Tor when creating the account and when using the account.
This is not to say that Delta isn't a good idea, I just think that it is very similar to Signal (the main difference being the email signup instead of phone number).
I wish push notifications worked better. It's so hard for open source projects. Ideally, a client should be able to, in a standard way, tell a server where to send notifications, maybe provide a key as well, and that's it. No need to register at each individual phone manufacturer etc.
Yeah, push notifications are an absolute shitshow.
A standardised push notifications API where you could swap out providers would be such a breath of fresh air.
That being said, the two applications I run that are doing long-polling sockets (Conversations and K-9 Mail) don't really use a lot of power, according to the battery settings screen on my Lineage device
After the second message, if that user is also using an app based on autocrypt, it should be encrypted.
If I understood right it's just a way to asymmetrically exchange keys. Just instead of you manually sending a pubkey or pulling it from a registry like in PGP they do it for you.
3. The first message sent to the another user is not PGP encrypted but when both users use delta chat the messages are encrypted
If only gmail/yahoo/... supported autocrypt you can communicate with every email user safely, but why would they ? It's a conflict of interest.
Decrypted messages are stored on the client and you can export the keys. Creating a random email address would be an easier way to ensure more privacy I suppose.
Over all the App supports everything WhatsApp does sans VOIP. I wonder how difficult that is ?
Same here - it got stuck at 96% (whatever that means), but it worked when I hit “Log in” the second time.
Strangely, the setup screen doesn’t seem to differentiate between “automatic” (i.e. “simple”) and “advanced” setup and filling out the fields is necessary for both when using the advanced setup mode.
delta chat is nice idea but it is very difficult to make chat like experience as every email provider handles replies and quoting original messages differently
> No, OpenPGP doesn’t support Perfect Forward Secrecy. Perfect Forward Secrecy works session-oriented, but E-Mail is asynchronous by nature and often used from multiple devices independently.
Yes, OpenPGP doesn't support PFS. But it's untrue that you need a session-based protocol to use PFS. The Signal protocol (and entire Noise family of protocols including things like WireGuard) beg to disagree.
No, the reason OpenPGP doesn't support PFS is that the design is fundamentally based around long-term keys -- even with separate short-lived subkeys you couldn't practially emulate PFS with PGP.
[1]: https://delta.chat/en/help#does-delta-chat-support-perfect-f...