Operating system
macOS
What issue do you have?
Hi, are there any plans to make Joplin post-quantum safe? Everyone seems to be talking about it.
Great timing on this question actually, there is a Google research paper going around right now on this exact topic which got a lot of people worried.
But here is the thing, even the researchers themselves say no quantum computer powerful enough to actually do this exists yet. Qubits, the building blocks of quantum computers, are incredibly unstable right now. Think of them like a coin that randomly flips, you need hundreds of thousands of near perfect stable ones to break real encryption and we are nowhere close to that.
For Joplin specifically your notes are encrypted with AES-256 which actually holds up fine even in a post quantum world. The only weak spot worth mentioning is the PPK feature, which is used when sharing encrypted notebooks between different users, that part uses RSA which would be a concern down the line. But honestly most people never even have that enabled.
So worth watching for sure, but your notes are safe today.
1 Like
@keshav0479 I had the same conclusion about the AES-256 encryption (as itās asymmetric encryption rather than symmetric encryption which is a quantum safety risk), but I hadnāt looked at the note sharing. Can you elaborate on what the āPPK featureā and why most people donāt have it enabled? Do you just mean people that donāt use the note sharing feature?
1 Like
yes pretty much @mrjo118 ! PPK is the Public Private Key pair,it is used when you share an encrypted notebook with someone.The master key gets re-encrypted to the recipient's public key and when they accept it gets re-encrypted back under their own master password, note content itself always stays AES encrypted, RSA only comes into play for that key handoff.
One thing i should clarify though, PPK does get auto generated during sync when E2EE is enabled, even before any sharing happens but RSA is only actually used when the sharing key exchange takes place, not for encrypting notes directly.
So yes to answer your question directly, people who never share encrypted notebooks are not really exposed to the RSA side of things.
1 Like
Just for clarification, if a user does share notes, is it just the shared notes which are exposed as being potentially not quantum safe, or it is the whole note collection?
just the shared notebook, when a notebook is shared, Joplin generates a completely separate encryption key specifically for it. RSA only comes into play to hand that key off to the recipient, once that is done RSA is out of the picture. Every other notebook has its own independent key that never touches RSA at all.
1 Like
and even that RSA exposure is very theoretical right now, breaking RSA-2048 needs somewhere under a million physical qubits, those are the raw unstable hardware bits, which then get grouped into around 1400 error corrected logical qubits to actually do the work. Google Willow, their latest chip, has 105, still nowhere close.
Does that mean that AES-128 is obsolete by now? I remember that the introduction of AES-256 resulted in a rollback to 128 due to performance issues, but I may be wrong and things might have changed by now.
As I've been using Joplin for six years now: Can I be sure that there are no notes with the old encryption standard left in my set of data?
Joplin is not post-quantum safe. I do not believe you should call something post-quantum resistant until all crypto in the application is secured.
At the moment if you enforce X25519MLKEM768 (a post-quantum resistant TLS key exchange) during TLS key exchange for your sync target then you get an error:
Completed: 2026.01.12 14:28 (21s)
Last error: FetchError: request to ``https://mywebdavurl/info.json`` failed, reason: write EPROTO 36850827480576:error:10000410:SSL routines:OPENSSL_internal:SSLV3_ALERT_HANDSHAKE_FAILURE:../../third_party/boringssl/src/ssl/tls_record.cc:486:SSL alert number 40
This is true of both the Linux desktop application (3.4.12), and Android app (3.5.8). Joplin 3.4.6 worked on Linux with X25519MLKEM768, but then broke again shortly after.
This has been true since I first tested it on 2025-08-23. I keep meaning to dig in and find out how boringssl is built in the dependency tree so I can replace it with something more up to date, but has been low on my todo list. This article A Cryptography Engineerās Perspective on Quantum Computing Timelines brought it to my attention again:
Any non-PQ key exchange should now be considered a potential active compromise, worthy of warning the user like OpenSSH does, because itās very hard to make sure all secrets transmitted over the connection or encrypted in the file have a shorter shelf life than three years.
1 Like
@newAM If you enable E2EE in Joplin, then even if someone cracks the TLS encryption of your network packets in transport to and from the sync target, your data would still be protected with AES-256 encryption if intercepted and the packets decrypted, which would be considered quantum safe at this point in time.
Whether someone can crack the TLS encryption of the connection to the server of your sync target however, is a different matter in terms of quantum safety. But with E2EE enabled, your data is essentially double encrypted in transport.
Joplin is not post-quantum safe. I do not believe you should call something post-quantum resistant until all crypto in the application is secured.
I guess youāre right in that regard though. There could be a risk of your server auth being compromised as quantum technology advances, but even if your server is compromised, the data would still be protected there with the AES-256 encryption
1 Like
Yeah store now decrypt later is one of the concerns here, though honestly that's true for pretty much everything on the internet right now.
1 Like
It's likely a minority of the internet that isn't using a PQ resistant TLS key exchange. In October last year it was about 50/50, it's likely that in the 6 months since this data PQ resistant TLS key exchange is used in majority of connections: State of the post-quantum Internet in 2025
Sadly I'm not using E2EE, I run my own webdav server, and wanted to be able to do plaintext backups. I have a very large dataset, and for some reason enabling E2EE corrupts ~100 objects and I need to restore from backup to resolve the error messages. This is another bug I want to fix eventually, but it's lower on my todo list than PQ TLS.
There are external reasons I want to get X25519MLKEM support into Joplin clients, my TLS terminating reverse proxy that I share for many applications has a global setting for key exchange, and I want to lock this down to PQ resistant algorithms. All the other applications I self-host and their clients work with X25519MLKEM, Joplin is the only reason I can't enforce PQ key exchange server-side.
Thinking of the Joplin mobile apps, apparently Android does not currently have a PQ enabled TLS stack available publically, according to ChatGPT:
Androidās TLS stack isnāt PQ-enabled (publicly)
Android apps rely on:
- Conscrypt (default TLS provider)
- Or system OpenSSL/BoringSSL
These currently donāt expose stable PQ TLS APIs for apps, even if experimental support exists internally (e.g., in BoringSSL).
Iām wondering if this is just outdated information in the AI, or there is in fact a large gap in terms of mobile app support for PQ TLS. @newAM Can you point to any sources which say otherwise?
I am not as familiar with TLS stacks on Android as I am Linux, but as I understand it applications can bring their own TLS stack on Android (unlike iPhone), so this answer may not hold true system-wide.
PQ TLS works with Google chrome, Firefox, and Firefox Nightly on Android, as proven by accessing my own server with X25519MLKEM enforced, and https://pq.cloudflareresearch.com/
The immich and home assistant apps also work with X25519MLKEM.
I guess web browsers are leading the way with PQ TLS support then, but I doubt you can say a minority of mobile apps arenāt using PQ resistant TLS key interchange, if the app has to provide its own TLS stack. Also the Joplin mobile app uses React Native, and there is apparently no ready made PQ TLS library for it currently.
Are you able to point me to the source file that defines where react native gets included in the Android build?
I do want to explore this further on my own to see if I can resolve this, but I haven't touched Android app development in 10+ years.
On the Linux side Joplin also bundles it's own TLS stack via electron. The boringssl version used there does contain X25519MLKEM768 support, and the string āX25519MLKEM768ā appears in the compiled Joplin binary, and yet this key exchange doesn't work. I need to dig a lot deeper to find out where the discrepancy is for Linux. I suspect it will be a similar effort for Android.
React native is not a dependency, the Android and iOS apps are written in React Native (javascript / typescript) and are compiled into native apps. So the mobile apps come with the restrictions which the React Native framework entails.
I figured out enough to fix this. Thereās a shim layer for HTTP requests that is shared by Android & Linux (and others). In this shim layer the default key exchange does not include X25519MLKEM768, even though it is supported by the bundled boringssl version. Explicitly setting the key change methods to include X25519MLKEM768 allows Joplin to sync with a PQC webdav server.
Pull-request is here: All: shim-init-node: add support for PQC TLS by newAM Ā· Pull Request #15055 Ā· laurent22/joplin Ā· GitHub
@newAM Oh nice one! Did you actually test the change works correctly on both Linux and Android though? Could you add details of all the testing you did on the PR?
Also regarding Joplin server, would Joplin server itself need to add support for PQ TLS, or is it only the web server which hosts Joplin server which needs to support it?