I did the same. Something that helped me get my head around it was realising that NTT is mostly a performance optimization, a bit like montgomery form in RSA. You can conceptually implement ML-KEM without it, it'll just be slower (it also won't be interoperable because the wire format involves the NTT'd form - I think, it's been a while since I looked at it in detail).
Good stuff to know, just in case the life extension tech explodes and we're all alive by the time cryptographically relevant quantum computers actually hit the scene.
Yes, but it exists because it was deemed better to be cautious and implement PQC despite the uncertainty and different points of view around the time scale to have cryptographically relevant quantum computers (or, from a different point of view, precisely due to the uncertainties). Their comment was in the wrong tone, but the doubts are there. BTW, PQC can be interesting to learn regardless of the discussion around quantum computers.
"will we have a CRQC soon" is the subject of much debate but "will we have a CRQC ever" is pretty uncontroversially a possibility, and so it is worth defending against harvest-now-decrypt-later attacks in the present - which is why X25519MLKEM768 is widely deployed already.
I've implemented ML-KEM by the spec as an exercise recently (https://github.com/AlexanderYastrebov/mlkem) and here are related links that helped me understand the math:
* [Enough Polynomials and Linear Algebra to Implement Kyber](https://words.filippo.io/kyber-math/)
* [Basic Lattice Cryptography. The concepts behind Kyber (ML-KEM) and Dilithium (ML-DSA)](https://eprint.iacr.org/2024/1287.pdf)
* [A Complete Beginner Guide to the Number Theoretic Transform (NTT)](https://eprint.iacr.org/2024/585.pdf)
I did the same. Something that helped me get my head around it was realising that NTT is mostly a performance optimization, a bit like montgomery form in RSA. You can conceptually implement ML-KEM without it, it'll just be slower (it also won't be interoperable because the wire format involves the NTT'd form - I think, it's been a while since I looked at it in detail).
A nice (short!) video on this topic is this one from Chalk Talk: https://youtu.be/QDdOoYdb748?is=vCFGroHUPwZP7Dqm
It's a superficial point but this relatively newer style (La)TeX layout makes me much more keen to read documents for some reason.
What's with the huge border whitespace?
So let’s say this is wildly over my head… what would be some good places to start reading to gain a minimal foundation to engage with this?
Simply put, you'll need algebra, linear algebra, number theory. So a lot of math with various degrees of depth.
Oh this brings me back to my uni days. I suppose that since this is the basis of post-quantum crypto it is a good time to learn this.
Seems to me that these lattices and error-correcting codes are very close to each other, but for some reason they are discussed separately.
I'd wager that there will be some reductions between those problems - maybe I could dig more around that.
Good stuff to know, just in case the life extension tech explodes and we're all alive by the time cryptographically relevant quantum computers actually hit the scene.
If quantum computers start breaking crypto within a few years, don't say you weren't sufficiently warned.
Lattice-based cryptography exists in the present (Both Chrome and Firefox support X25519MLKEM768 hybrid key agreement, by default)
Yes, but it exists because it was deemed better to be cautious and implement PQC despite the uncertainty and different points of view around the time scale to have cryptographically relevant quantum computers (or, from a different point of view, precisely due to the uncertainties). Their comment was in the wrong tone, but the doubts are there. BTW, PQC can be interesting to learn regardless of the discussion around quantum computers.
"will we have a CRQC soon" is the subject of much debate but "will we have a CRQC ever" is pretty uncontroversially a possibility, and so it is worth defending against harvest-now-decrypt-later attacks in the present - which is why X25519MLKEM768 is widely deployed already.
> X25519MLKEM768
https://www.reddit.com/r/VXJunkies/