It's highly misleading context. Leaking tiny amounts of information a tiny fraction of the time can be totally disastrous in the context of cryptography.
One of my favourite recent examples (2020): "LadderLeak: Breaking ECDSA
With Less Than One Bit Of Nonce Leakage" https://eprint.iacr.org/2020/615.pdf
But I think the issue still stands, we keep hearing about timing attacks, spec-ex attacks, partial nonce reveal, etc. and yes you should carefully design around them, but they're pretty much overhyped and there's easier ways to attack systems. The only timing attack that's been seen in the wild is the MAC bypass in XBox 360. The reality is it is too difficult to launch these attacks and the cryptography is rarely attacked unless there's straightforward flaws.
As for the partial nonce, I've seen many attacks on this kind of issue, but I've yet to see this mistake made.
There aren't many in-the-wild timing attacks because constant-time is table stakes for cryptography implementation, and has been for decades.
It's like saying that when driving on a road, the "wheels fall off" risk is overhyped. Wheels falling off may be low on your personal list of concerns, but only because car manufacturers make sure they don't design cars whose wheels fall off. A car with wheels that fall off would be unacceptable.
> There aren't many in-the-wild timing attacks because constant-time is table stakes for cryptography implementation, and has been for decades.
That is one theory and plausible, but another plausible theory is the conditions to setup a timing attack is usually infeasible due to requiring high precision timing, a very large number of samples/measurement, and requiring probes in an ideal situation. AES in software is still a good example of an algorithm where timing attacks are still possible. Take for example djb paper on cache timing [1], it requires 4 million samples before key recovery. The reality is that kind of attack is highly unlikely to occur, and there's been opportunities where non timing safe AES has been used. I'd argue the more pragmatic stance of an attacker is that that timing attacks aren't really practical unless attacking a protection mechanism of a piece of hardware like the Xbox 360, at least for network services it is really low on the list.
As for the ECDSA attack, again impressive feat, but only 773 wallets which isn't real cause for concern. I think the bigger concern is using amateur 3rd party implementations of bitcoin that doesn't do nonce generation properly when signing, it really isn't that hard, but I agree it can be a footgun. The reality is this is still a negligible concern compared to real attacks happening everyday draining crypto wallets due to malware threat.
A computer can do something 4 million times in the blink of an eye - even over a network if you can pipeline your requests (especially if you can get a VPS instance in the same datacentre as your victim). The only reason we have to resort to fiddly attacks like cache timing is because the low-hanging fruit (e.g. data-dependent branching) has already been covered.
If you can point me to somewhere non-timing-safe AES is in active use in an adversary-interactive setting, please let me know so I can take a look!
"Take, for example, the simple case of a linear congruential generator (LCG), which is the typical textbook introduction to PRNG implementations. LCGs are to PRNG what ROT13 is to encryption and “1234” is to secure passwords. Despite that, due to their simplicity and popularity, they are the default choice for many non-critically secure applications" [0]
As a hacker, always try the easiest things first. It's crazy how often they work.
Fancy crypto attack: You have a 0.00001% change of recovering 2 bits of plaintext from a single message
Any of the OWASP top ten: You have a 100% chance of recovering the plaintext of all the messages