I’d like to summarize my understanding and ask if it is correct:
If I use AES-256 encryption with a strong, long password, are all my notes considered post-quantum safe?
Is that true as long as I do not share any notes?
If I do share one note, do the remaining notes stay safe?
Is the main current weak point only the transport encryption to services like Dropbox, Joplin Cloud, etc.?
Did I understand this correctly?
@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.
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”.
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
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.
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).
@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.
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.
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
What Android 17 actually changed
The “quantum-safe TLS” (hybrid post-quantum key exchange) is currently enabled at the browser layer, mainly via:
Chrome
WebView (Gadget Hacks)
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)
What that means for React Native apps
React Native network requests typically use:
fetch/XMLHttpRequestbacked by native stacks like:
OkHttp (Android)
platform TLS (BoringSSL/Conscrypt)
These are NOT WebView-based.
So:
No automatic quantum-safe TLS
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)
Important edge cases
You do get it if:
Your RN app uses WebView for requests/content
- e.g. loading pages, embedded flows
You use:
fetch
axiosGraphQL clients
Or anything using OkHttp / native networking
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)
Practical takeaway
For a typical React Native app:
Feature Applies automatically? Quantum-safe TLS (hybrid PQ) ECH (TLS privacy) Standard TLS security
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)
Bottom line
Android 17 is “quantum-safer”, but:
It mainly protects browser/WebView traffic, not general app networking.
A React Native app using
fetchwon’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.
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
