Postquantum safe?

Features
21

I’d like to summarize my understanding and ask if it is correct:

  1. If I use AES-256 encryption with a strong, long password, are all my notes considered post-quantum safe?

  2. Is that true as long as I do not share any notes?

  3. If I do share one note, do the remaining notes stay safe?

  4. Is the main current weak point only the transport encryption to services like Dropbox, Joplin Cloud, etc.?

Did I understand this correctly?

22

@Mario11 Yes to all 4 points.

Just one thing to add, the master password is the weakest point when using the E2E encryption, because while the note data will have very strong encryption using a master key, the master key itself is stored with the data on the server, but it is encrypted using your master password.

So if your server is compromised, someone with enough knowledge of the Joplin internals could try to brute force to decrypt the master key, and if they succeed, they will be able to decrypt everything else.

Also, what might be considered a strong password today, may not be considered as strong anymore some decades from now, as GPU hardware evolves over time. But to mitigate this, you can review the strength of your master password every few years, and change it to a stronger password if and when the need arises. The data itself would not need to be re-encrypted, unless AES-256 encryption becomes obsolete.

23

Thanks again for all the detailed explanations in this thread.
One last question from my side:
Are there any concrete plans or a roadmap to add post-quantum cryptography to Joplin?
I understand that AES‑256 itself is considered safe even in a post-quantum world for now, but I’m wondering if Joplin plans to adopt standardized post-quantum algorithms once they are mature and widely supported, so that the whole stack can be called “post-quantum safe”.

24

I’m not aware of any plans for this considered currently, but it likely will be considered more strongly as quantum computing becomes more of a threat. In any case Joplin is open source and anyone is welcome to make code contributions to be considered for acceptence into the codebase. @newAM has submitted a PR in attempt to address the PQ TLS interaction from the Joplin side at least on the desktop apps, though he has not commented on whether testing has actually been done on the Android app

25

I have zero doubts that the team will update the cryptography as required and as they have in the past. E2EE is a touted feature. And so … I trust the cryptography will be upgraded over time.

26

I did test on Android, the changes for the desktop app didn’t work sadly.

Android needs a deep dive that I don’t have a lot of time for right now. Any advice or pointers from those more experienced in Android development would be appreciated.

I tried updating to the Android 17 beta that has PQC system-wide by default (source: Android 17 Quantum-Safe Security: What's Protected and What's Not << Android :: Gadget Hacks ), but this also did not change the behavior of the Joplin app.

I haven’t looked into Joplin server. If Joplin server uses a reverse proxy for termination (such as nginx) then only nginx (and it’s TLS library, typically OpenSSL) needs to support PQC TLS. If Joplin bundles its own TLS stack then that underlying stack needs to support it, but most already do that out of the box since ~2024.

@Mario11 I concur with everything said already, if you have E2EE enabled then you are post quantum secure (at least in terms of what post-quantum cryptography means today).

27

@newAM That’s good news. I think the React Native network clients will use the native TLS stack by default. However it might be the case that you need to bring the target SDK level of the app to 37 in order to make use of the updated TLS stack (see joplin/packages/app-mobile/android/build.gradle at 6e7c9c059dac600d00ad7dc01e746284bae5b1d0 · laurent22/joplin · GitHub ).

We shouldn’t upgrade it at this point, as it increases the minimum required version of Android to run the app, but we will have to bring it to 37 eventually, as Google increases the minimum compliance level every year, in order for the app to remain on the Play store. If iOS implements similar from a minimum version of their OS, it could be a similar story.

EDIT: Did you read the whole of the article you quoted? It actually says Android 17 is not known to have introduced quantum safety at platform level, so we might need to wait for future Android releases for that:

March 25, 2026, there is no publicly documented Android 17 platform-wide shift to post-quantum cryptography in Conscrypt, the Keystore, or general app networking. No announced changes to the platform APIs that non-browser apps use for their own cryptographic operations. No public roadmap for BoringSSL defaults at the OS level.

28

EDIT: Did you read the whole of the article you quoted? It actually says Android 17 is not known to have introduced quantum safety at platform level, so we’ll need to wait for future Android releases for that:

Yeah, I did read it, there’s a lot going on at the platform level, but it also says the basics (TLS) have been covered by 2024. There’s no “publicly documented” platform wide shift, but the support for x25519mlkem768 has been there quite a while. I figured Android 17 may have some additional updates that I’m not aware of? X25519MLKEM768 does appear to be a default now for all apps that can use it, but I forgot to save a wireshark capture before I updated to Android 17, this might have been true before as well.

I still don’t have a good mental model of all the TLS possibilities in Android.

29

From ChatGPT:

Prompt: Android 17 seems to enable quantum safe tls by default, but will it apply to network requests in a react native app?

Short answer: no, not automatically for most React Native network requests.

Here’s the nuanced reality of Android 17’s “quantum-safe TLS” story and how it affects React Native :backhand_index_pointing_down:

:brain: What Android 17 actually changed

  • The “quantum-safe TLS” (hybrid post-quantum key exchange) is currently enabled at the browser layer, mainly via:

  • There is no confirmed platform-wide switch that upgrades all app TLS stacks (e.g. Conscrypt / BoringSSL used by apps) to post-quantum by default (Gadget Hacks)

  • Android 17 does add some TLS-related improvements like:

    • ECH (Encrypted Client Hello) for privacy — opportunistically used if the networking stack supports it (Android Developers)

:mobile_phone: What that means for React Native apps

React Native network requests typically use:

  • fetch / XMLHttpRequest

  • backed by native stacks like:

    • OkHttp (Android)

    • platform TLS (BoringSSL/Conscrypt)

:backhand_index_pointing_right: These are NOT WebView-based.

So:

  • :cross_mark: No automatic quantum-safe TLS

  • :cross_mark: No guarantee of hybrid PQ key exchange

  • :cross_mark: Depends entirely on the underlying networking library

From the current evidence:

Apps that handle their own TLS stack or don’t use WebView are not covered by the new defaults (Gadget Hacks)

:warning: Important edge cases

:white_check_mark: You do get it if:

  • Your RN app uses WebView for requests/content

    • e.g. loading pages, embedded flows

:cross_mark: You likely don’t if:

  • You use:

    • fetch

    • axios

    • GraphQL clients

  • Or anything using OkHttp / native networking

:locked_with_key: What does still apply to RN apps

Even without PQ TLS, Android 17 still affects your network layer:

  • ECH (Encrypted Client Hello)
    → May apply if your HTTP client (e.g. OkHttp version) supports it and server supports it (Android Developers)

  • Certificate Transparency enabled by default (Android Developers)

  • Stricter network security config & HTTPS expectations
    → Same behavior you already see in RN (HTTP blocked, TLS required) (AgileSoftLabs)

:puzzle_piece: Practical takeaway

For a typical React Native app:

Feature Applies automatically?
Quantum-safe TLS (hybrid PQ) :cross_mark: No
ECH (TLS privacy) :warning: Maybe (depends on client + server)
Standard TLS security :white_check_mark: Yes

:hammer_and_wrench: If you want quantum-safe TLS in RN

Right now, you’d need to:

  • Wait for:

    • OkHttp / Android TLS stack to adopt PQC by default

  • OR:

    • Use a custom networking layer that supports PQC (rare today)

:compass: Bottom line

Android 17 is “quantum-safer”, but:

It mainly protects browser/WebView traffic, not general app networking.

A React Native app using fetch won’t magically become quantum-safe just by targeting Android 17.

If you want, I can break down how OkHttp or Hermes networking might evolve here—or what to watch in upcoming Android releases.

30

Note that the master key is encrypted with a stronger encryption method, so it's harder (time consuming) to brute force it. As time goes we could update the encryption method to make it stronger still as we previously did

31

I had a lot to learn about modern Android app development. These things may sound obvious to those with a mobile background, but I come from firmware and back-end work. User-facing applications and their ecosystems are far outside my usual territory.

At the risk of sounding naive, here's what I learned. Hopefully it saves someone else the same detours. This thread now ranks highly in Google searches for Android and PQC TLS key exchange :expressionless:

  • Google is inconsistent. Android and Chromium are both Google products but have entirely different security models and update cadences. What made research difficult is that Google discourages apps from managing their own TLS stack, while routinely ignoring that rule for their own products.
  • The Android TLS stack (Conscrypt) is a fork, and it's old. I couldn't pin the exact version, but x25519mlkem768 support has been in upstream Conscrypt for some time, and it still isn't present in Android 17 Beta 4.
  • React Native is not a web app. It uses native UI elements and therefore does not use the WebView TLS stack. This was a significant point of confusion for me, Joplin does use WebViews for note rendering, but that's a separate code path.
  • The Home Assistant app achieves x25519mlkem768 because it is a WebView app and inherits the WebView TLS stack directly.

I got x25519mlkem768 partially working in Joplin Android by swapping in the Chromium network stack (Cronet), which supports PQC TLS and can be used as an OkHttp transport via cronet-okhttp. However, this only covered standard fetch() traffic. HTTP requests for file transfers go through rn-fetch-blob, which installs its own response interceptor and is incompatible with cronet-okhttp.

rn-fetch-blob is archived. The common migration target, react-native-blob-util, has the same problem.

I find this frustrating. Google is not keeping Android's native TLS APIs current, while simultaneously making it difficult for developers to fix this themselves.

As I see it, my options for securing my Joplin notes in a post-quantum world are:

  1. Fix the end-to-end encryption errors on my dataset and rely on E2EE rather than transport security.
  2. Switch to GrapheneOS or another Android build I can compile myself with an updated TLS backend.
  3. Replace rn-fetch-blob with a custom native module that drives Cronet directly, and probably maintain a Joplin fork, since asking the project to carry this workaround is unreasonable.

At the moment I'm leaning towards 1. I think it will be the easiest solution, while also helping others that may be facing the problems I am when encrypting a large dataset.

32

Based on your last post I'm going to assume you do use the mobile app for at least one of your Joplin clients. I'd agree using Joplin's E2EE would be the best solution transport security is improved at the OS level on Android.

Before doing so though, bear in mind there is this bug Mobile: Entering the wrong password in encryption config causes local notes to be encryted with a corrupt or non-existent encryption key · Issue #14975 · laurent22/joplin · GitHub (see my last comment) in the current stable version of Joplin for Android and iOS. I'd recommend you wait until Joplin 3.6 is released before enabling E2EE (should be within the next month), or if you use Android, at least wait until Joplin 3.6.17 is released, which will include a fix for this issue

33

Thanks for the heads up @mrjo118, and more generally for the discussion here :slightly_smiling_face:

I took that into consideration, but enabled E2EE anyway. I keep very regular (5m) backups of my Joplin data both client and server side.

I started with a blank slate in a development VM, no prior application data, and enabling E2EE for my notes worked this time, no errors. Not sure if an update fixed the problem I experienced before, or if wiping out application data fixed my problems, but E2EE works on all my clients now.

34

Notes are stored in plain text on the client machine and every app process including the least secure apps in 99% user setups can exfiltrate data and you folks worry about quantum :laughing::ok_hand:t3:

35

The existence of worse problems doesn't make this problem not exist.

36

There is no such thing as "safe" encryption standard or post quantum. It's mearly "presumed or assumed" to be safe.

TrueCrypt was an example, which Veracrypt is a now patched fork of. Keys can be stolen, hardware encryption keys can be backdoored as can software encryption algorithms weather intentionally or not.

The algorithm might be implemented correctly and have zero bugs. But keys are stored in memory while a file or drive is decrypted.

At best only while it's being decrypted will the password be stored in memory, which malware could still grab it from, but so could a plain old key logger. So post quantum encryption still has these issues.