Issue #5
"So Long, Farewell"
Welcome to the fifth edition. This week we explore the meaning of names, the death of an old friend, and the trade-offs we must face. Let’s dive right in…
What’s in a Name?
It's nearly time to forget the names Kyber, Dilithium, SPHINCS+ and Falcon.
NIST always renames algorithms when it standardises them. For instance, AES used to be called Rijndael (pronounced rain-dahl). SHA-3 was formerly known as Keccak (pronounced “ketchak”).
The same is true for our post-quantum algorithm friends. When they are standardised next year, they will adopt far less friendly names:
CRYSTALS-KYBER ⇢ ML-KEM (or "Module-Lattice-Based Key-Encapsulation Mechanism Standard")
CRYSTALS-DILITHIUM ⇢ ML-DSA (or "Module-Lattice-Based Digital Signature Standard")
SPHINCS+ ⇢ SLH-DSA (or "Stateless Hash-Based Digital Signature Standard")
FALCON ⇢ FN-DSA (or "FFT Over NTRU Lattices Digital Signature Standard") - proposed name, not yet released
Don't they just roll off the tongue? I'm sure we'll get used to them, but I'll certainly miss the old names.
Goodbye, Old Friend
A big change just happened in the world of cryptography. Our old favourite crypto library, OpenSSL v1.1.1 has reached end-of-life.
OpenSSL underpins a LOT of cryptographic systems used on Linux-based systems, as well as some Windows applications. Heavily used programs, like Apache web server, rely on OpenSSL to do their cryptographic heavy lifting.
OpenSSL 1.1.1 was a long-term-support (LTS) version, which was guaranteed to be supported for 5 years. That time has now expired, so applications must migrate to the newer LTS version, OpenSSL v3.0.
Most applications will just need to be recompiled, so it's not a major change.
However, this end-of-live announcement is great news for those of us who write plugins for OpenSSL. The OpenSSL architecture was rewritten in v3.x, and it became far more modular and easier to work with.
That being said, I'm sure we'll see v1.1.1 in production for a long time. Not least because companies can purchase a $50k annual support package for v1.1.1 if they want to keep using it.
Link to the EOL announcement: https://www.openssl.org/blog/blog/2023/09/11/eol-111/.
Back to School
If you want to learn the basics of post-quantum crypto, IBM just announced a new training course which looks useful.
To be clear, I've only scanned the agenda, but it seems to cover the bases. The lessons are mostly text-based, although there are some Python examples you can play with.
According to IBM, by the end of the course you can expect to know more about:
Cryptographic primitives that underpin current cryptographic systems:
Cryptographic Hashing
Asymmetric Cryptography
Symmetric Cryptography
The quantum threat to classical encryption schemes
Quantum-safe encryption schemes
You can find the course here: https://learning.quantum-computing.ibm.com/course/practical-introduction-to-quantum-safe-cryptography.
Fancy a (Quantum) Challenge?
The Quantum Internet Application Challenge is currently live and accepting submissions.
The goal is to submit working code (using the Python-based SquidASM framework) that simulates some kind of novel quantum internet application.
The competition winner can look forward to an internship or research visit to TU Berlin, TU Delft, or University of Parma.
Submissions are due by 23rd Oct 2023.
View competition information: https://quantuminternetalliance.org/quantum-internet-application-challenge-2023/
Something You Know, Something We Know
A recent breach at Retool highlights the painful trade-offs introduced by multi-factor-authentication (MFA).
In theory, MFA is a great thing. Nobody can access my work email without typing in a code from my mobile phone.
But what happens if I lose my phone? How do I get back into all those precious accounts I've protected so carefully?
The typical solution is to download backup codes, and keep them somewhere safe. But people either forget to do this, or find it cumbersome.
And thus, companies like Google are trying to make this easier for people. They offer to backup your MFA system in the cloud so you can't lock yourself out.
Unfortunately, everything in security is a trade-off. A recently breached company, called Retool, is complaining heavily about this Google feature, claiming that it gave attackers the keys to the kingdom.
After phishing an employee to gain access to their Google account, attackers were able to generate their own MFA tokens for a variety of critical systems. This effectively meant multi-factor auth had become single-factor auth.
Hopefully, this story reminds us that security decisions are always a trade-off. And also warns us to check our Google account settings to decide if we are happy with this default behaviour.
Link to the Retool blog: https://retool.com/blog/mfa-isnt-mfa/