It's not like other quantum issues, where you're worried about transcripts collected today being broken 15 years from now.
"This post is about why I dislike AES-GCM’s design, not “why AES-GCM is insecure and should be avoided”. AES-GCM is still miles above what most developers reach for when they want to encrypt (e.g. ECB mode or CBC mode)."
It's more of a collection of pet peeves about AES (in general) and AES-GCM (in particular).
I like to read opinion pieces that are pithy and well presented. I may or may not agree but I will think about the issue. In this case I know very little about the intricacies involved and its good to know that some people do. I've just recently converted about 45 Phase I IPSEC connections to AES128-GCM, AES-XCBC, DH Group 31 and similar Phase II. Most of them were 3DES MD5 G2, without PFS at Phase2 so I think it's an improvement! A big surprise to me was a major drop in CPU usage at the "hub" end. The hardware doesn't have AES-NI yet but it will soon be replaced and your notes have accelerated that change up my stack of stuff to do.
Sadly some of our peers seem to have forgotten to actually read the thesis first before shootin' wildly. I have quite a low Slashdot number and used to hang out there back in the day - nothing is new in the world!
Again, thank you for sharing.
AES-GCM can be tricky to use if you implement it yourself, same goes for all other ciphers it’s perfectly fine when you use a proven implementation of it that ensures that it doesn’t go past its best before date for a given secret key.
I don’t understand why they made such a big deal of cache timing attacks, yes AES and any other cipher/cryptographic system that have time variable operation may be susceptible to timing attacks, and whilst ChaCha doesn’t have time variable operations (tho it doesn’t guarantee that a given cryptographic system implementation won’t introduce them) it’s still quite susceptible to fault injection attacks which are arguably much easier to execute on the CPUs that most phones and small devices run than cache timing attacks.
Overall when your threat model for a personal device includes a compromised application a lot of security assumptions should be thrown out of the window, it’s far more likely to compromise the OS itself than try to compromise the hardware on a phone specifically you’ll run out of battery before you’ll be able to do a successful cache timing attack anyhow.
If the blog was AES-GCM is easy to cock up so remember that nonce is a nonce for a reason and you should be using improvements over AES-GCM like AES-GCM-SIV it would’ve been fine.
How it is it reads like not particularly well constructed I R VERY SMART post.
Especially the quantum issues that primarily affect real time attacks, not offline ones which would allow you to decrypt historic data with ease.
If you have a drive encrypted with AES even “only” 128bit it’s probably going to be safe for a long while even in a post quantum world.
I just wanted to patent the basic idea of using counter-mode to generate a stream cipher from a block cipher. They said that it seemed like such a small idea, couldn't we allow it to generate simultaneous multiple streams, etc. So it was patented, but the patent is a bit of a mess with some half-baked designs for multiple streams. This was absolutely the worst way to design a crypto system: design one yourself while in the patent lawyer's office.
It still covered the basic idea of using a block cipher and a counter to generate a stream cipher, but I think the good stuff was buried in just a few of the claims. That's all ancient history now since the patent would have expired decades ago.
Counter modes were petty well known in the 80's already I'm not sure what the patent could've been applied for but then it's IBM and their lawyers can probably find a way to patent waking up in the morning.
The method takes advantage of network idle time so it doesn’t improve maximum bandwidth but instead reduces the average latency of a network not running at full bandwidth.
As for ChaCha et al, it’s still not that easy to start using it.
Not that many proven standardized implementations exist, hardware acceleration and performance issue are still there, the amount of research on these ciphers is still dwarfed by the amount of research done against AES and since these aren’t industry standards it’s harder to implement them in systems that require wide interoperability and are pretty much a no go in any industry that has its own standards.
Using extended ChaCha is cool for your side project, but try to implement it to say protect card payments in a system that needs to go through a PCI certification for example.
But for asymmetric (public key) encryption the larger key lengths barely help, so you'd need infeasibly enormous keys. e.g. terabyte RSA keys have been "proposed" facetiously for this purpose.
Thus, Post Quantum Encryption research is mostly interested in finding solutions for two asymmetric problems: Key Agreement (a replacement for today's Elliptic Curve Diffie Hellman) and Signatures (a replacement for things like ECDSA) that would survive an attack by a larger quantum computer able to execute Shor's algorithm.