Migrate to quantum resistant algorithms
Quantum computing breaking common cryptography algorithms is a future problem that will affect all data that is stolen/collected now and that contains sensitive information we may NEVER want to share
-
Lamparas
commented
> I also followed up my question about SMTP TLS with one about support for HTTPS TLS:
Hello,
thank you for your answer. Are you planning to also incorporate PQ KEX algorithms into the HTTPS layer of Proton's products? I understand that PQ KEX support is still fairly recent in the SMTP/TLS stacks, but it's been widely supported in HTTPS/TLS stacks for over two years at this point.
> Proton's support response:
Hello,
Thank you for asking this. I was just about to sent you an update about this :)
Proton also plans to support PQ KEX in HTTPS/TLS stacks. Our web teams are working on it.
Best Regards,
XXXXXX
Mail Delivery Team
Proton Mail> While I can't be certain, it seems like supporting PQ KEX algos in HTTPS might be coming relatively soon, and most likely earlier than for SMTP TLS.
> From the responses I got, it seems like a having paying customers reach out about things like this is something they do take into consideration when triaging things like this.
-
Someone
commented
Thank you for posting your email and Proton's response, Lamparas. I cannot fathom how this is not being treated as a P1, if not P0 issue right now.
-
Lamparas
commented
> I wrote the following email regarding PQC to Proton's support:
Hello,
I would like to ask about Proton's plan to support PQC in its services, more specifically the TLS stack. There are currently no PQ algorithms available as TLS exchange groups on any of Proton's services (except the CDN, which seems to be hosted by Cloudflare) for either HTTPS, or SMTP.
Checking with `openssl s_client -starttls smtp -connect mail.protonmail.ch:25 -tls1_3 -msg -servername mail.protonmail.ch`, and `openssl s_client -connect mail.proton.me:443`, I can see that neither support PQC exchange groups, and this seems to be the case for every Proton service. This is also the case for BoringSSL: `bssl s_client -starttls smtp -connect mail.protonmail.ch:25`, and `bssl s_client -connect mail.proton.me:443`.
Every single *free* email provider (gmail, yahoo, seznam, etc.) out of the 10 I tried supported a PQ TLS key exchange group (like X25519MLKEM768) for both their email WebUI, and SMTP submission.
This concerns me, because it makes all TLS sessions to Proton's service (including incoming emails) succeptible to SNDL attacks. Making Proton an even likelier target for these future attacks is the fact that many people who might be under threat by well-resourced adversaries use Proton's services. The highly-centralized nature of Proton's infrastrucutre also makes me even more concerned about the feasibility of SNDL against Proton service users.
In the last couple of months, a significant amount of peer-reviewed and credible research has shown that a cryptographically-relevant quantum computers might become available much earlier than previously thought, making many organizations move up their deadlines for PQ transitions by up to five years, all while Proton doesn't currently mitigate even the most pressing PQ threat (Asymetric key exchanges), despite algorithms currently understood to mitigate this threat being available in clients, servers and cryptographic libraries, and already deployed by most mainstream services (many of which are already working on implementing PQ algorithms in areas not succeptible to SNDL). Currently, I can throw Debian on a Raspberry, install Dovecot, Postfix, any webserver/SMTP proxy, and get support for PQ KEX algorithms, and protections against SNDL attacks out of the box.
What are Proton's plans, and timeline, around supporting, at the very least, PQ KEX algorithms for HTTPS/TLS and SMTP in it's product lineup?
Thank you.
> This is the response I received from them:
Hello,
Thank you for the detailed report and for taking the time to test this. We genuinely appreciate the thoroughness of your findings.
Adding PQ KEX support to our TLS/SMTP stack is something we are actively planning. That said, rolling this out responsibly requires significant evaluation and testing across our infrastructure, so we yet to have to a specific timeline at this stage. What we can say is that it is not something we expect to complete in the near term.
We understand the urgency around SNDL threats, especially for our users, and this is not something we are taking lightly.
Thanks again for raising this. Feedback like yours helps us prioritize the right things.
Best Regards,
XXXX
Mail Delivery Team
Proton Mail -
Giuseppe De Francesco (Pino) commented
Looks like nothing moves here, even if PGP now has full support for Quantum-resistant encryption. Why? Your main competitor (Tuta) offers this level of encryption. What's stopping Proton? Do you want us to move to Tuta?
-
Higor
commented
Post-quantum cryptography is very strong. Hopefully, Proton AG will implement this future cryptography.
-
[Deleted User]
commented
I'd like that sooner than later too, especially since Tuta Mail has started (and almost finished) migrating people to Post-Quantum-Encryption.
-
Pete Pete commented
It's critical !!!!!!!!!!!
-
Vincent RAMPAL
commented
Post quantum cryptography will affect Proton both for data at rest and data in transit.
I see your plan for GPG encryption quantum safe but could you please clarify for TLS/QUIC and certificates ?Proton use encryption at different level:
* when Proton exchange mails with other mail servers (encryption in transit)
* when Proton verify the identity of other mail servers (certificate / signature)
* when Proton store mails using GPG (encryption at rest)
* when user connects to Proton servers (encryption in transit)
* when user verifies the identity of Proton servers (certificate / signature)
All of them needs to support post-quantum cryptography.Post quantum crypto is supported in GPG since version 2.5.1.
Source: https://lists.gnupg.org/pipermail/gnupg-announce/2024q3/000485.htmlNIST offer several standard of post quantum crypto.
Source: https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardizationOpen Quantum Safe is also provide several solutions.
Project: https://openquantumsafe.org/
Presentations: https://www.douglas.stebila.ca/research/presentations/Cloudflare is quite active on this topic and you can use it as a reference to see if you are above or bellow competition.
https://www.cloudflare.com/pqc/
https://blog.cloudflare.com/pq-2024/
https://pq.cloudflareresearch.com/ -
pedro chromazzi commented
About https://proton.me/blog/post-quantum-encryption, I don't know much about communication system encryption, but my question is: is the data still safe even if the connection with your server flows? I think that is like a chain; if even one of the rings falls, all the chain is broken. So I think that not only does the server have to adopt pq data encryption, but it also has to require a pq resilient https connection; otherwise, the first encryption is vain.
-
AdminProton
(Admin, Proton)
commented
Thanks for the feedback, you can read about our plans here: https://proton.me/blog/post-quantum-encryption
-
Joey Reid
commented
Very Critical! That would be a huge disaster not only by regular/home users but businesses too! especially for confidential things that business and home business users need! to protect future damages from fradsters and bad actors that may use what ever data stored for what ever their case may be! Damages that may be huge that may come across over the years!
We all Need that extra protection before its to late for (*businesses*) and Regular Home users / Home businesses < 3 votes from yall !!! >
-
D.
commented
I think it's already been implemented years ago. Correct me if I'm wrong though but I think the CEO confirmed that in this : https://www.youtube.com/watch?v=Dp7ght2fMR4&t=4394s
-
secnetsys
commented
Transfering data we may NEVER want to share by email looks like a funny option, IMHO.