
Email based PGP encrypted chat - arpa
http://delta.chat
======
cyphar
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.

[1]: [https://delta.chat/en/help#does-delta-chat-support-
perfect-f...](https://delta.chat/en/help#does-delta-chat-support-perfect-
forward-secrecy)

~~~
dependenttypes
There is [https://tools.ietf.org/html/draft-brown-pgp-
pfs-03](https://tools.ietf.org/html/draft-brown-pgp-pfs-03) but I do not think
that anyone implements it. Regardless I think that not having PFS is not
necessarily a drawback.

> 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.

~~~
cyphar
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.

------
badrabbit
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_y...](https://www.theregister.co.uk/2016/01/27/nsa_loves_it_when_you_use_pgp/)

~~~
u801e
> 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.

~~~
arpa
it should be less than that, if the servers are controlled by competent admins
- everything after STARTTLS should be garbage to beholder.

~~~
badrabbit
The MTAs are hostile,they are the threat. Email can traverse multiple servers
that have nothing to do with the sender or recipient.

Competency won't prevent them from allowing backdoor access or sniffing and
selling metadata.

~~~
arpa
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.

------
chooseaname
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.

~~~
mimsee
An alternative for this is Matrix.

See: [https://matrix.org](https://matrix.org)

------
mikekchar
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.

~~~
swiley
> Also, they kind of avoid talking about the very important issue that who you
> are talking to is not secret.

Which chat apps fix this? I’m sure the people operating signal know who you
talk to.

~~~
cyphar
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).

[1]: [https://signal.org/blog/sealed-sender/](https://signal.org/blog/sealed-
sender/) [2]: [https://ricochet.im/](https://ricochet.im/) [3]:
[https://github.com/agl/pond](https://github.com/agl/pond) [4]:
[https://matrix.org/](https://matrix.org/)

~~~
tialaramex
> 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.

~~~
swiley
>In Signal's design nobody ends up knowing this except the sender and
recipient.

I’d like to see an explanation for that, it sounds magical.

~~~
tialaramex
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.

[https://signal.org/blog/sealed-sender/](https://signal.org/blog/sealed-
sender/)

------
sha3owwalker
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).

------
amaccuish
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.

~~~
therealidiot
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

------
Multicomp
I tried this about 2 years ago on an Android and it worked just fine, the
problem was I could only use a single email account at a time.

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.

------
foobar_
This is cool! It's simple and clean. I'm wondering how does the initial key
exchange work. That seems to be the biggest problem with PGP.

I would recommend giving it a more different look than WhatsApp.

~~~
dirtnugget
Apparently there is a protocol, they name it in the FAQ:

[https://autocrypt.org/](https://autocrypt.org/)

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.

~~~
foobar_
It seems after installing the app

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 ?

~~~
dirtnugget
GMails business model is basically based on scanning your mail.

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

------
carc1n0gen
I expected this to be easy to setup since it's just email. Yet using the exact
same credentials my mail client uses fails to connect.

~~~
christefano
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.

------
malinens
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

------
reinhardt1053
Does provides any sort of forward secrecy?

~~~
cyphar
No, as mentioned in the FAQ[1]. Though to be fair, this is because of the
design of OpenPGP (it's almost anti-PFS by design).

[1]: [https://delta.chat/en/help#does-delta-chat-support-
perfect-f...](https://delta.chat/en/help#does-delta-chat-support-perfect-
forward-secrecy)

------
jswizzy
Isn't email insecure by design?

~~~
avhon1
PGP doesn't hide the fact that you are communicating with someone, but it will
keep the content of your conversation pretty private.

