Email based PGP encrypted chat
delta.chat
delta.chat
> 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...
> The Signal protocol (and entire Noise family of protocols including things like WireGuard) beg to disagree.
These use a dedicated key per device rather than per season.
> 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.
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_y...
Hey! You didn't actually link to [1] ! ;)
https://www.theregister.co.uk/2016/01/27/nsa_loves_it_when_y...
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.
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>
.
If you need everyone to run their own mail servers and a specific client then why bother with email at all?
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.
Competency won't prevent them from allowing backdoor access or sniffing and selling metadata.
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.
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.
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.
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.
See: https://matrix.org
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.
Which chat apps fix this? I’m sure the people operating signal know who you talk to.
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).
[1]: https://signal.org/blog/sealed-sender/ [2]: https://ricochet.im/ [3]: https://github.com/agl/pond [4]: https://matrix.org/
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.
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).
[1]: https://signal.org/blog/sealed-sender/#the-future-is-in-tran...
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.
I’d like to see an explanation for that, it sounds magical.
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.
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.
> 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?).
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).
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
Unfortunately it's not available on Safari for iOS and also doesn't work with native apps.
This meant that I could not use work accounts to chat with wlperdonal folks and vice versa via the official work email.
since I don't want to pollute my personal emails with work stuff, that somewhat limited what I could do.
once they fix that, I would be glad to use this quite a bit more.
Edit : looks like they added multiple account Support after all... I will definitely be trying it again today.
I would recommend giving it a more different look than WhatsApp.
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.
1. It logs into email via SMTP / OAuth
2. It creates a folder called delta chat
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 ?
It should be possible if they can work out how to put WebRTC with transformable streams in there.
It’s the most feature complete messenger. Maybe it’s possible to hook it up to ProtonMail
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.
[1]: https://delta.chat/en/help#does-delta-chat-support-perfect-f...