It's super easy to filter for that though. Just change the problem slightly. If they give the rote answer you know what you need to know. It does require that you know the answer though. :)
I have my war stories too. It was fun but frustrating. Definitely not as productive as today.
Early 2000s internet was kind of like that too. The web was huge relative to what we had to work with and there wasn't the kind of products/services available then so asking leetcode stuff had a logic to it.
Admittedly, that's not where we are now for most programmers so it makes sense that the interview process should adapt.
Even if I enjoy leetcoding and I do, there are tons of things I would rather do before that, and that are far more useful, such as building and working on side projects.
So to me leetcoding is a waste of time and less fun than actually building something, having other people use what you have built. And there is infinite things to build there and learn.
I get that. I only do medium and easy problems for a reason. Hard problems are hard and I want to solve it over morning coffee. :)
Then again, I'm sure all of my leisure activities are a waste of time on someone's metric.
I probably learn more from the comments than the problems though. People post lots of interesting idioms and it's interesting to me to see how others codify various standard algorithms. Especially across languages.
You would think things like spread spectrum clocking and low passing power would thwart this attack but really it just means you need to take a larger average and computers are really fast.
Yes, agreed you'd need a larger average. The thing I'm trying to get at is whether or not this is a practical attack, as in: feasible in the real world, without being able to control the code running on the device. Because if you can do this to any random ESP32 without being able to manipulate the code and it coughs up the keys in a few days, weeks or even months that's an entirely different level of threat than being able to do this the way the article did it.
And I'm having a hard time figuring out how big that difference is, it may well be 'impractical today, childsplay tomorrow'. And ESP32 devices are in a lot of different places. Access to the hardware should be assumed (because you're not going to be able to monitor the 3.3V line with this level of accuracy otherwise), I'd assume any caps after the monitoring point would be removed and the only capacitance left would sit on the supply side before the current transformer. If that's your setup and you have no knowledge of what's running on the chip is it doable or not?
The article suggests that any key can be recovered in a couple of seconds but I don't think that's the case at all.
In general: One needs to get code on the device for this attack to work.
But, in many demonstrated cases, one doesn't need to get privileged code on the device, which is an important distinction. And in other cases this type of monitoring was done without direct access to the machine, for example by examining the intensity of LEDs with a camera. Admittedly that's within eyeshot, but it's not direct access either.
For this ESP32 attack in particular, it's not clear how it would work without full control of the device.
