Purism has written a new blog article:
Yeah, but what if the whatsit steals my whoozle?
Contact Purism support to replace it.
Can anyone explain what specific tools or standards Purism is using that are quantum safe? The article seems like nothing more than a marketing fluff piece. Yes, it links to some NIST stuff, but it doesn’t specify what Purism is doing with the NIST stuff
ML-KEM (0:16), but Purism has more information about the implementation details:
Somewhat but there are two specific points:
- Anyone can claim that their platform is quantum-safe but with an open source platform you can actually verify that to be true (audit it).
- Keys are kept on device (so your security, no matter how good, is not hostage to some other company).
Don’t get me wrong - I am fully on board with Purism’s mission, and I’ve been using their products for like 8 years now. I just think that the quality of their blog posts has declined substantially in the past year or so. So many seem to just say the same thing over and over again. I appreciate the technical posts, but those seem less frequent now.
You are misreading that post. It says “Becoming quantum safe with the recently finalized Post-Quantum Encryption Standards is now possible with Purism.”. Meaning, it’s possible for someone to start using those recommended algorithms (if they add them) that are hard even for a quantum computer to crack using brute force in reasonable time, based on current understanding. Nowhere did I see what algos are used or that they are implemented as default, or even available. The possibility is good - L5 has a lot of potential, as always, again and again - but I’ll wait to hear that something has been done.
There are only three options at the moment:
The video mentions ML-KEM at 0:16, which is used for encryption. The other two finalists are for signatures, with another signature algorithm still pending release:
The blog post really should have made an effort to be more informative as, yes, those are the three most likely alternatives (there were more just a while ago but still, after years, they are/maybe finding flaws - hence the “current understanding” caveat). Nice to know that C-K was renamed (didn’t recognize that from video). But still, possibility is not the same as available by default - the latter means they would actually be used much more likely.
Another thing I just noticed (which would have been good to point out in the blog too), is that the video showed that quantum resistant algos are usable (not prohibitively slow) on L5 hardware. Some may be under the misconception that it needs a lot of computing power. Edit to add: L5 is a technical device for technically minded people (and some random others) that is not like the polished alternatives from which we try to escape, so it’s a bit odd that technological details are not more prominent, deeper and wider in the blogs, info and other content.
Purism had already made a post describing how one can set up encrypted chats here: https://puri.sm/posts/hardware-encrypted-comsec-bundle-by-purism/.
The exact instructions are linked here: https://source.puri.sm/Librem5/debs/pkg-chatty/-/wikis/Hardware-Encrypted-Communication-Setup. This only works with the Chatty app and the video in this latest post appears to also be using Chatty on the Librem 5s while the Librem 14 shown appears to be using the Element client.
That’s part of the puzzle (second bullet point in my original reply) but does the OpenPGP card support any quantum-safe algorithms?
No it does not, at least for storing them on its key slots.
So it would require a quantum leap to the next generation of OpenPGP cards.
It should be noted that Purism’s post was cautious in its wording: they used the term “Quantum-safe” and avoided the use of “Quantum-secure”, which are two different things.
Remember the 5 NIST finalists for proposed post-quantum cryptographic (PQC) algorithms, which suddenly became 4 when one of them got cracked?
“The SIKE crack shows us, any quantum-safe encryption will be safe only until it is cracked.”
I remember some 20-30 years ago, when AES, Blowfish and other encryption algos were developed that back then there was similar ambivalence towards them. There was a use strategy for a while that stuff should be encrypted with three different algos, just in case one of them would be found flawed or had a backdoor. With these, I just hope apps and systems will have an option to select which one to use - as opposed to have one randomly selected and hardcoded.