PrivacyGuides' email-security page is misleading

There is a more current ‘plan’ to implement forward secrecy once the crypto refresh (RFC 9580 - OpenPGP) is standardised.

Upcoming improvements

After the crypto refresh of the OpenPGP standard is released, we plan to continue to work with the OpenPGP Working Group to bring even more advanced cryptography and additional features to PGP, such as:

Security improvements

  • Post-quantum cryptography (a topic that we’ve already been working on. We’ll publish a separate blog post about it shortly.)
  • Forward secrecy (protecting messages sent today even if a key is compromised tomorrow)
  • Domain separation for signing and/or encryption
1 Like

I agree, make something better. But that is different than barging in here and saying the email overview is wrong.

I also find it curious that 2 accounts recently created after I asked arcane chat about something, both are trying to defend a relatively unknown service.

Proton is doing reasonable work. Last I read GnuPGP was blocking their work.

for your information, I shared the link to this post in some Delta Chat users community group of +100 people:

write a PoC, I already provided you access to a full raw email with headers and all, exploit it, show me what you got

I think it would help if the guide started with a short explanation of what is defined as “email” by it, DeltaChat, Thunderbird with encryption etc. certainly are email and are compatible with each other. Same with ArcaneChat it is not an “closed-off system” it can interact with other email servers. Maybe the guide should start with “we refer with email to using gmail, outlook, etc. with a half-assed email client from the 80s without proper encryption support”

(@mountainofmeat replaying to you in older post because I reached the number of post per day :frowning: it seems “new” members are limited)

E-Mail is not “secure”. Services want interoperability with each other so they have to make compromises. It doesn’t matter if your isolated service uses the SMTP protocol in a special way, it doesn’t make e-mail more secure, only your closed-off system. Quite literally the exception to the rule, but if you start listing exceptions to everything we’ll never find the end of it.

Changing the definition because a technical-minded individual disagrees is not productive. E-Mail should continue to refer to the commonly used services. If you have to jump through multiple hoops to make it secure, you might as well use a protocol that was designed for it from the start instead of hacking features onto an old one designed to be “electronic mail”, a way to send messages easier than paper mail.

Can you share a link? I’d like to read up on this.

You keep not understanding the point. You seem to have not understanding of IETF works, how standards are implemented, and how terms are important. Your users have similar technical illiteracy guessing from the two sockpuppets here. It makes me very worried about whatever software you are making. I won’t engage further due to the ad hominems. I will also be advising folks the same, adding you to the list of projects that do not understand what shoulders of giants they stand on, led by coders who never graduated to become actual programmers. Keep twisting words you cannot comprehend.

I would also like to just register my confusion that the moderators have not stepped to curb these personal attacks in, yet simple off topic posts are flagged within seconds. I am not sure if this is because the person breaking community guideline is some minor dev, or if they simply missed it. For now as remedy I have blocked the dev and their sockpuppets. (The offending post is now removed, happy to see prompt response from the moderators.)

Sorry, just saw this. Here you go: A Schism in the OpenPGP World | Hacker News

1 Like

You keep saying this, but disappearing messages are a feature pretty much every secure messenger supports, so it isn’t really a slam dunk to be one of the only security-focused messengers besides iMessage that doesn’t have this basic functionality.

you will not see this message, but I am sorry if my joke was offensive, maybe it was a bit over the top to send a meme.

But you keep talking about other people as “sockpuppets” and undermining Delta Chat users etc. which is also not nice of you.

FYI I am a graduated of Computer Science, but anyways I find your comment very offensive, there are people out there that never graduated in university and know a lot more than me and absolutely much more than you.

it exists but do every single user have this feature enabled? does Signal forces disappearing messages for PFS to be secure and make sense? if most users don’t use disappearing messages because they don’t want to lose their messages history, what is the point? and if you need to use disappearing messages for PFS to make sense, how is it then better than just using OpenPGP and creating a temporary account/key and drop it after a while? besides when you have a central server collecting messages then PFS sounds more interesting because the attacker needs to control de server to collect the messages and decrypt them later when the key is compromised, but with decentralized servers there is no easy way for the attacker to control the particular server you might decide to use (or even self-host)

Curious: What’s the threat model for this? As in, what kind of adversary do we have in mind?

1 Like

Honestly there is quite a bit on bad faith being thrown around. I feel like this is two conversations: one about DeltaChat/ArcaneChat, the other about email by itself.

An analogy I see here is that WireGuard uses UDP. I would not consider UDP by itself a secure protocol. I consider WireGuard built atop UDP as secure. There are ways to secure UDP outside of WireGuard through other encryption schemes.

Email by itself has privacy leaks. DeltaChat built atop email is more private than traditional email. There are also ways to maintain some privacy in email outside of DeltaChat like through PGP.

Rather than compare apples to oranges, I’m curious how DeltaChat compares to email with PGP.

EDIT: and then truly compare the differences between DeltaChat using email (I’m assuming the base is SMTP/POP/IMAP related protocols) as transport layer, vs Matrix, vs Signal.

2 Likes

It isn’t a specific threat, it’s just a general privacy principle to minimize unnecessary data storage whenever possible.

1 Like

I’ve only given a quick read and it has been mentioned already, but I feel like the primary point of contention is interoperability.

Email can be called secure, only if you’re able to maintain that security while sending an email to any random address I give you (without them having to use another service to open the mail).

I’ve never looked at DeltaChat and ArcaneChat and don’t know what they are exactly, but can an ArcaneChat user send a secure email that I can read from my Tuta client? Or maybe to a mail(.)com or yahoo(.)com user? If not, I personally wouldn’t consider email secure, because this is how email is meant to be used.

This is actually not correct. Thunderbird does not do this by default. You can enable it.

3 Likes

Hm, minimize data storage by whom?

Afaik, Perfect Forward Secrecy thwarts a class of offline attacks where malicious actors eavesdrop on encrypted comms with the intention of decrypting it at a later date, probably after they compromise the keys (or break encryption).

These malicious actors are usually corporates and nation states.

Is this what you have in mind, too?

Not sure about the storage portion, but PFS does this:

Forward secrecy is designed to prevent the compromise of a long-term secret key from affecting the confidentiality of past conversations.

Assuming the encryption is not broken, it increases the cost of breaking communication by making the adversary compromise all future keys consistently. It stops sloppy key management from being the weak point in defence. It prevents one malicious application update (done by the dev or from a hijacked repository) from compromising the past. It is not just “store now decrypt later” attack prevention.

Perplexity had an answer close enough to what I wanted to say: https://www.perplexity.ai/search/use-case-of-perfect-forward-se-9q8HLbFxTtSX5m_ZlVMwgA

The threat model from “storage” PoV is what I outlined.

From Wikipedia:

… forward secrecy is limited not only by the assumption that an adversary will attack a server by only stealing keys … but it is also limited by the assumption that the adversary will only passively collect traffic on the communications link and not be active using a man-in-the-middle attack.

And this “storage” stuff is something state actors like NSA are known to do, in the off chance a bug like Heartbleed (TLS) ends up compromising long-term keys in a large deployment of servers in one fell swoop.

One important property is called “perfect forward secrecy,” but only some servers and only some browsers are configured to support it. Sites that use perfect forward secrecy can provide better security to users in cases where the encrypted data is being monitored and recorded by a third party. That particular threat may have once seemed unlikely, but we now know that the NSA does exactly this kind of long-term storage of at least some encrypted communications as they flow through telecommunications hubs, in a collection effort it calls “upstream”.

Source: eff (mirror).

(So, correct me if I’m wrong Jonah) Competent and deep-pocket actors like nation state actors is also why PFS is table stakes for encryption.

You’ll have to outline your thoughts yourself as that page comes up blank for me.

1 Like

To be fair, it seems DeltaChat has solved the subject problem by ignoring it entirely and building a protocol routing system atop of information in the encrypted body. It’s definitely not how one imagines email, but it does solve that problem. But DeltaChat does not intend to function as a traditional email server but a messenger, and I assume users aren’t using their personal emails in DeltaChat.

But the two things remaining problems to solve for DeltaChat would be:

  1. No long term storage of messages. Unsure if not storing server side is a problem that needs solving based other messengers as I’m unsure if they do.
  2. Forward secrecy.

I’ve re read the recommendations for messengers. I think the most compelling comparison to existing messengers would be DeltaChat against SimpleX, or against Session. @adbenitez I’m no expert in this, so I think you’ll be more apt to provide good details how on DeltaChat ranks against these two services.

this is not a problem, the client can be configured to delete messages after download for classic email servers, and for chatmail servers this is the default when user doesn’t have multi-device setup, in any case the server deletes all messages older than 20 days automatically

this is more useful in a platform where accounts are scarce resources, like when you log-in with your phone number and you are always using the same identity for everything for years, some day talking with family, the next revolting? :wink: with Delta Chat creating a new anonymous profile is a trivial matter easier than changing clothes, you could then use that for some important operation and throw it away afterwards, you will be completely safe you didn’t left any trace behind, no message no social graph, while when mixing all communications in a single profile you are more prone to mistakes, everyone likes “PFS” but ask around how many people actually understand the implications and the need of disappearing messages to be enabled to have any real impact and you will realize in practice people are just getting overconfident, just having certain contact in your chats or contact list could be enough metadata to get you in trouble…

that said, this thread is not about DeltaChat, and Thunderbird, k9mail etc. allow to encrypt/protect the subject as well, as some other autocrypt capable clients, my point here is that the guide would be more helpful pointing people to the tools that can do the job than just claiming “it is not possible to protect the subject, it will always be leaked” while deliberately not informing / hiding the fact that there are tools out there to do the job