PrivacyGuides' email-security page is misleading

Site Development
46

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

47

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
48

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.

49

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

50

I don’t understand why there is confusion of PFS in this thread. It has no relation to disappearing messages or creating new accounts.

PFS is absolutely mandatory to prevent trivially breaking past, present, and future messages if a key is leaked or broken.

The server and transports, whether you run it or trust it, should be considered hostile. You should assume that an attacker will have a copy of ciphertext and try to break it at some point. PFS substantially raises the bar by requiring given N messages to each have their own key broken.

if they aren’t default enabled, they’re not going to be used.

edit: some feedback about ArcaneChat

  • I had to enable compatibility mode on GrapheneOS to make the app load.
    • edit: Was 64-bit, and seems incompatible with hmalloc.
  • There was a proxy option to use, but Orbot integration would be nice as not everyone knows the port combo.
    • edit: For reference it is socks5://127.0.0.1:9050
  • And most importantly the current proxy implementation is global not per account. So the server in this case could trivially correlate accounts.
    • edit: it does seem per profile, but not obvious at first.
  • I couldn’t find the option to delete my account from the server, only the app.
  • I didn’t see an option to force encryption, only prefer it.
4 Likes
51

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.

Yes, both do that. I use Deltachat as my now primary email client and have no trouble talking with people on their institution’s servers, on yahoo, on gmail, etc…

What Deltachat and Arcanechat do is also add an autocrypt header so that the receiving party can start exchanging encrypted email if they so desire. There is an even better way to make this secure by avoiding easy MITM thanks to yet another addition (securejoin) which only those implement, but guarantee E2EE (instead of one that can be intercepted)

Both applications try to move the email ecosystem forward by showing how it can be done. There is nothing super specific about any of the things that are above.

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 actually an old RFC draft, as said above: see my message above about standards

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.

There’s a bit of a misunderstanding here: DeltaChat and chatmail are made by the same people, complement each other, but you don’t have to use both. I and other people use DeltaChat as an email client, not just as a messenger. Many emails are well managed with the messenger mindset (not all, of course). But it is entirely a client. Chatmail is the server (basically a bundling of standard postfix and dovecot) and DeltaChat offers to create an account on it easily.

52

you can’t detach theory from practice, you might have PFS, you assumed the friendly server supporting you is hostile and is storing all your messages, but you don’t see the relation with disappearing messages, you feel safe, then your real “attacker” unlocks (or force you to) your phone and gets access not only to your keys, they don’t need to go running to the server to then decrypt messages, they have your messages already in their hands in your phone together in the key because you said “It has no relation to disappearing messages”.

About creating accounts, the thing is that when you create a new account you also create a new key, when you delete the account the key together with all the messages are gone forever, so you have the same effect as PFS, this is a practical view of the outcome not a theoretical, I am not interested in discussing theory detached from practical reality.

it is the default in ArcaneChat tho

you probably installed some 32bit version

false, proxy is per profile, not global, you can use different proxies of different protocols per each account, including ShadowSocks VPNs!

mmmh yes that is a bit hard to discover: click your avatar at the top bar, then long-press your profile in the account switcher and select “delete”, I will add this option to somewhere in the profile settings so people discover it more easily, thanks for the feedback!

encryption is forced by default and it is in fact that “prefer encryption” option, I reused the string from Delta Chat but in fact will rename it to a more clear “enforce encryption” or so

this thread is not really about ArcaneChat so I would prefer if we continue this talk in the ArcaneChat community group, write to me at:

53

An attacker having physical access is a separate issue from PFS, even if they have the same outcome (accessing messages).

2 Likes
54

so your threat model is: “attacker controls server and used brute force to guess your key”? or in what situation does the attacker get access to the key without access to the messages in, let’s say, Signal?

55

I don’t trust Signal’s pinky promise either and we should assume they’re storing ciphertext too in some form, but at least their client actually has PFS.

As mentioned above, we know parties are storing this data. There will inevitably be advancements in computing or shortcuts to break encryption.
They will be able to break yesterday’s or today’s crypto eventually and will decrypt our messages. We shouldn’t make it easy for them.

You as a developer, PG as a recommendation source, and us (the technical) overall must continually raise the bar and not ignore this.

3 Likes
56

this doesn’t answer my question, please, how does the attacker get your signal key other than getting access to your device (and then having already access to the messages without needing the server)?

EDIT: thanks for updating your comment

so your assumption is that they will be able to easily brute-force/crack the key in the future, in that case, how does PFS helps much here? they can crack the key of every message then in that far-away future, we will likely be dead by then tho, it is also a question of when does it matter, and still creating a temporary profile and throwing it away has the same effect.

57

Why would they need to get your device?

58

Yes, both do that. I use Deltachat as my now primary email client and have no trouble talking with people on their institution’s servers, on yahoo, on gmail, etc…

But it stops being encrypted/secure while doing that I’m guessing?

59

Because having each message with its own key directly raises the time/monetary cost of breaking it. That is all security is ultimately about: increasing cost.

This cannot be assumed.

2 Likes
60

It’s not encrypted because my correspondents don’t have a key, yes. If they had one and used autocrypt, DeltaChat would import their key when they send me a message and we would have an encrypted conversation.

61

If that’s the only issue, then it seems like it’s a minor correction easily updated. Instead of say “not possible” just say “traditional email clients” and call it a day.

I feel as though these are technicalities of phrasing, which seem trivial to update. PG does take PRs to update the site, maybe throw up a draft PR?

62

This is contrived/unlikely.
Most messengers, while they may encrypt their storage, only store the messages in plaintext.
ie. PFS has no use/benefit here

However in the context of email, it is common for MUAs to just store the original/raw .mbox or whatever.

63

Yes, that’s not true because you can encrypt the entire message and have a hash of that message. You can retrieve that message in a Tokyo Cabinet with a key index hash table lookup.

64

I don’t really see a compelling reason to build and instant messenger and bolt that on top of an email+PGP anyway.

The reason PGP is used for email is because established mime types and support in email clients. There simply is no alternative except S/MIME and that requires a certificate.

There is an effort for compatibility, but to what goal? You still need the software to realistically communicate with recipients anyway. At that stage wouldn’t it be better just to use something that achieves all these goals.

In terms of email that has never been a particularly reliable protocol in terms of deliverability, rate limits and other server side factors.

Not to mention modern expectations of video, voice calls and multi device support. PGP does not have mullti device support unless you use the same keys everywhere (no such thing as cross signing device keys etc). The whole way that attachments are done (mime encoding a file and slapping it on the end) seems like something you’d want to avoid.

I guess this is why arcane chat reduces the size of voice, and images? I saw that mentioned:

  • It is possible to disable profiles to completely disconnect them saving data/bandwidth
  • Voice messages have more aggressive compression in “worse quality” mode to save data plan
  • Automatic download of messages limited to 640KB by default

These all seem like reasons in 2025 to not use this software.

I wouldn’t assume anything about users. If they can they will and this just seems like an unnecessary footgun.

3 Likes