You can actually do an awful lot of stuff with an ESP32, which often comes as a surprise to people who think you need a full Linux system just to turn a light on and off. For example Goodwe solar inverters/controllers are controlled by ESP32s and do a great job while Enphase controllers use Linux SBCs and are flaky, bug-riddled garbage.
Does it matter whether the Ethernet interface on an ESP32 is 100 or 1000Mbps? Would it even matter if it was 10Mbps? What could you possibly do with an ESP32 that would require gigabit Ethernet? It seems like advertising the fact that there's a four-line highway running to your fishing shack.
Or Lobster Thermidor aux crevettes with a Mornay sauce served in a Provençale manner with shallots and aubergines garnished with truffle pâté, brandy and a fried egg on top and slop
I felt a bit uncomfortable seeing carrots with their tops lopped off in a totally mechanical manner on a conveyor belt, or beetroots boiledalive before their corpses were pushed through razor-sharp blades to slice them up, or corn ripped off their husks, or tomatoes... tomatoes... oh man, I feel nauseous, I think I'm going to throw up.
You joke, but plants are alive and have feelings, just like everything else that is alive. They have the ability to communicate using ultrasound and they can pick up your brainwaves and respond to them.
There's a plant that can change the shape it grows its leaf to match what other plant is around them - that includes copying artificial plants. So it has to be possible for a plant to "see".
Another piece of overblown academic panic-mongering. It's been known since forever that you never use RSA that way, which is why every single standard that specifies RSA use also specifies padding mechanisms designed to avoid this, but nowhere in the title or abstract, which is about all that 99% of non-cryptographers will read, does it ever mention this. In fact it's written to imply the exact opposite.
This is not "we broke RSA", it's "we managed to find an implementation you've probably never heard of before that's so broken that an attack that nothing should be vulnerable to is actually feasible". This is a blog post, not a news story. I found a much bigger vuln than this in Android RSA auth some years ago, I'm talking beginner-level crypto misuse, told Google about it, and it was quietly fixed. I didn't publish a paper about it or get it in the news because it was a non-story.
Except that in this case every single piece of crypto code or downstream app out there that has the name "RSA" associated with it, which is all of them, has to reassure every one of its users who have seen the news headline that no, it's overblown hype, you're not vulnerable, nothing to do since there's no vulnerability present in your use of RSA.
The worst possible outcome would be if this thing actually gets a CVE assigned to it. How do you fix a "vulnerability" that doesn't exist?
Actually it's just thoughts from someone who has to deal with the fallout from this stuff. Which will include spending at least a week researching and writing up a sufficiently nontechnical analysis for mgt explaining why its completely irrelevant, all wasted time I should be spending dealing with actual real security issues.
But is that the fault of Heninger et al? Far from being academic and alarmist attention seekers, they have done the hard yards of dealing with real hardware, albeit a reduced difficulty variant.
I would say so, yes, because as I pointed out in my previous post, nowhere in the title or abstract do they say that this doesn't apply to virtually any use of RSA today. It's an interesting academic result but a giant headache for anyone who has to deal with the fallout, because anyone who reads about it will only see "RSA is broken" and demand action, and the cleanup task will fall on people who are already overloaded dealing with a malware infection and suspected penetration of one of the networks by parties unknown (probably Russia or China again) and an SAR audit all going on at the same time.
I don't think you can impose an obligation on academic authors to assume that dangerously uninformed people will glom on to keywords like 'RSA', not understand any of the content, and somehow this is the author's burden.
Yes, it creates bullshit for experts to deal with. Unfortunately dealing with bullshit is part of the job. The amount of AI hacking doomerism and naive super optimism I have to deal with is revolting, but grounding the paranoia and boosterism is part of the job.
The people I take issue with are the ones who claim expertise, and then say "This new paper says 1024 but RSA is broken, we must move to PQC immediately!" They are so good at blowing their own trumpet they get appointed to boards and are anointed as experts in regulators, and you can't expose them without experiencing institutional anger.
From a security perspective perhaps it's not that interesting-- although signing oracles are all too common access to one is already close enough to a total break even before getting to the padding restriction. (e.g. go ahead and sign post dated certificates too).
But the technique is interesting as an object of study, in a way that finding "beginner-levle crypto misuse" absolutely wouldn't be, so it makes it more relevant as an academic publication. It further clarifies just how fragile these constructs are.
Also from a security perspective I suspect this may be a total break on some blind signature token schemes that use RSA. I've seen some of those avoid using ECC on the basis of the complexity required to avoid one-more-signature attacks that require making a fair number of concurrent blind signatures. (and have a shape a lot like this attack!)
> How do you fix a "vulnerability" that doesn't exist?
Don't make a signing oracle (esp one that doesn't even do the padding itself) available!
The thing is that they don't have to be that big at all, you could probably specify enough of PKI and TLS and SSH to cover most uses cases in, I dunno, 30-40 pages. However the standards bodies that produced them, termed "working groups", are more like standing committees that will (a) standardize any random idea that any member brings along and (b) are worse than the energizer bunny, they just keep going and going and going and going. Even ones that have been forcibly shut down like PKIX just keep going in other forms (LAMPS). You can't stop these standards mills, they'll just keep grinding out more stuff that no-one ever asked for, for all of eternity.
It sure sounds like it should be like this, but when you actually try you end up with not this. TLS is huge! Yes, but SSL 2.0 was smaller, and buggy as hell, so it had to evolve, and after 30+ years it became the monster that it is today.
Of course, SSL 2.0 did reference x.509, so hey, SSL 2.0 should have invented its own PKI. Except that Netscape might have come up with something terrible that worked in 1993 in labs but didn't scale to the web, or just full of security problems, or...
What you say sounds nice and right right up until you actually look at the details of what actually happened in real life, and how things actually evolve when they have little standards involvement.
Well, no-one held a gun to their head but there was a general "enough, already", aided by the fact that several of the main characters were retiring which helped wind it up. And then they just kept going as before under a new name and with an influx of new people who were unaware of how the original mess was made and why.
So if a WG is wound up and then continues under another name with mostly the same people doing the same things the original WG did it's not really wound up, is it? It's just changing the sign over the door with business continuing as usual.
First, anyone can participate. The only cost is the value of your time.
Second, yes, there are the usual suspects -- the ones who've decided to spend a lot of their time on whatever the area of tech we're talking about.
Third, working groups have charters that delineate what RFCs they will publish. Sometimes the work runs out. Sometimes the people run out of energy. Sometimes the tech is 'done', at least for a while. Then the WGs shut down.
Fourth, sometimes new work gets brought to the IETF in an area where the relevant WG has concluded, so then a new WG _may_ get spun up to take on that work.
I say this a lot, but: there was a conspiracy theory that NSA had infiltrated the IETF during the original IPSEC standardization effort and injected the "TLS BEAST" CBC IV chaining vulnerability, which is funny because we actually know exactly how that happened (professional academic cryptographers took out a petition to get the bug fixed and were shouted down by standards body gadflies who literally rejected the premise that there was such a thing as a professional academic cryptographer). This is really easy to see once you've done an engagement on DSIG security! Standards bodies are more than capable of fucking things up entirely on their own. If anything, NSA would risk making protocols stronger by intervening in their natural processes.
"Never attribute to malice what is adequately explained by stupidity". Or, in this case, design-by-committee by a bunch of people who haven't written ten lines of code in as many years. There have been several other cases where absolute no-brainer fixes, like one or two lines of code changed, to long-standing security problems, were filibustered, or blocked by WG chairs, for no explainable reason, and they can't all have been paid by the NSA to do that.
Yes, absolutely. And it's self-selection for mediocrity, people who are useless at any other task and prepared to argue endlessly over pointless technicalities that no-one apart from other professional meeting-goers care about are perfect for dumping onto standards committees.
Another KYC success story. Presumably the banks involved were too busy investigating Granny Smith for wiring $100 to her grandkids to have time to check on billion-dollar money-launderers.
+1 to the above. And while a works-under-every-failure-case bootloader isn't quite that trivial, it's still absolutely nothing compared to telling the hardware guys that you want twice as much flash as the SoC they're using can manage.
> Testing an OTA update can survive a power interruption during the downloading is such a basic test. It doesn't need an article that long.
Tell that to the developers of containerloads of IoS (Internet of Shit) devices that can barely manage an OTA update under perfect conditions without bricking themselves.
While you're at it, also let a well-known company that I'll leave unnamed know for their Windows Update service.
reply