The triple-DES keyspace is 168 bits, vs 56 bits, so 2^112 times longer to do a complete scan of the keyspace. If you have a known plaintext and can do a meet-in-the-middle attack, it's approximately "only" 2^56 times longer. I'm not aware of words for the length of time this would take other than "past the heat death of the sun".
Yes. This is completely true if we assume there are no large quantum computers with practical error correction - we probably won't have one in the foreseeable future. But beware that a sufficiently large quantum computer will be able to run Glover's algorithm and reducing the brute-force attempts required from N to sqrt(N), making all 128-bit ciphers be 64-bit and turning 3DES back to DES. And I won't be surprised if it happens within my lifetime. But the solution for symmetric encryption is simple, just use 256-bit ciphers, fast and effective, and many are already in use today. Public-key encryption is the real trouble, many candidates, much higher cost, somewhat untested constructions.
I don't think the post-quantum block collision scenario is very plausible, and, at any rate, it's effectively an online attack (sweet32 follows the attack model Thai Duong and Juliano Rizzo came up with, where you're relying on malicious Javascript to trigger it). If we get to plausible quantum attacks of any sort, algorithms will get swapped out to regain security margin.
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)."
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!
This blog post isn’t particularly good more like rehashed rambling.
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.
Back in the 80's I worked for IBM and invented a counter-mode based stream cipher. I did it to speed up overall network throughput in the presence of bursty traffic. The lawyers wanted it patented, so I agreed to meet with them and in their office, while working on the wording and patent claims they wanted me to add a bunch of features.
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.
You can run any block cipher in CTR, there are 3DES CTR implementations out there, same goes for 3DES CFB/OFB modes.
The only one that got wide adoption I think is CBC since ECB was always known to be well a problem.
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.
Yes, counter mode wasn’t novel at the time. The actual idea was related to encryption of network traffic. Back then, networks ran faster than encryption (processors didn’t have encryption hardware support). Since many networks have bursts of transmission the idea was to encrypt a counter with buffering of the results. This buffered stream of crypto values would then be XOR’d with the data when it arrived. The xor of course can run at full network speed since the encryption was done while during an idle time of the network.
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.
It's indeed a potential concern, basically the quantum edition of the Sweet32 attack. History will repeat itself (Although I wonder how much pre-quantum AES-256 traffic will really be vulnerable in practice. I think an interactive attack will be very unlikely, the concern is mostly pre-existing ciphertext. I guess most OpenPGP traffic will probably be secure? And even HTTPS will be okayish as long as you don't send too much data in a single connection? It would be an interesting study...) Fortunately, start using ChaCha20 or XChaCha20 is easy, unlike inventing and deploying a new public-key cryptosystem. So symmetric ciphers are still an "easy" problem.
Historic traffic isn’t going to be much of an issue at all, as for AES-GCM specifically then nonce reuse will still likely be an issue well before a QSweet32 attack will be.
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.
The factual content of this blog is fine but the delivery is horrible. Why would someone randomly intersperse drawings of their character in the middle of an article about AEAD constructions?
For symmetric encryption, as your parent explained, yes, simply double the key length and you're fine. (In practice you might get away with less than double because it seems unlikely such quantum computers, even if eventually constructed, would be similarly cheap to conventional computers)
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.
