Two papers came out last week that suggest classical asymmetric cryptography might indeed be broken by quantum computers in just a few years.

That means we need to ship post-quantum crypto now, with the tools we have: ML-KEM and ML-DSA. I didn't think PQ auth was so urgent until recently.

https://words.filippo.io/crqc-timeline/

A Cryptography Engineer’s Perspective on Quantum Computing Timelines

The risk that cryptographically-relevant quantum computers materialize within the next few years is now high enough to be dispositive, unfortunately.

@filippo
> In symmetric encryption, we don’t need to do anything, thankfully

Ok. So the IoT garden must rewind to the Kerberos or physical provisioning. I can't imagine lattices on small silicon yet.

Thank you, Filippo.

@ohir @filippo I’m involved in modernizing crypto for protocol that needs to work at 9600 baud. These key sizes are going to be a terrible problem… and that’s just the bandwidth side, them there”s RAM and CPU on small embedded devices.
@mikaeleiman @ohir yup, it's not great, but it is what it is. (RAM is kinda fine if you optimize for it, and CPU is actually faster than classical. But yes, size sucks.)
@filippo @mikaeleiman @ohir Small devices which are part of a bigger system, but which are unable to take care of themselves should be behind a gateway/proxy anyway.
@KoosPol @filippo there’s no gateway to hide behind in this case unfortunately, it’s all small devices (and no Internet involved). And we’d like to be able to firmware update existing devices to the new stuff, replacing with new hardware would be very expensive.
@mikaeleiman @filippo Then you have an system architecture problem. You can't have important devices in operation without proper safeguards. And if one of the safeguards is crypto, while these devices can't deliver, then you need to tuck them behind a gateway. And if you can't then the devices aren't important enough. You can't have the cake and eat it.

@KoosPol @filippo That's why I'm looking forward to someone coming up with a quantum resistant variant of key exchange with smaller keys that's workable for smallish embedded MCUs :]

Currently it's looking like there's no way forward for our users that's not expensive, disruptive and time consuming.

@KoosPol @filippo @mikaeleiman
> should be behind a gateway/proxy anyway

IoT devices are not expected to have any external protection. This is a consumer market. We can not expect home owner to provide secure environment before they change old dumb LED-bulb for a new one equipped with BLE, motion sensors and microphones. Whether they use "smart" features of this bulb or not.

Then we have many mandated by law devices that must be put in the car for safety and for national security reasons. A prime example are the direct TPMS sensors. E.g. a hackable TPMS in the tire will not deny our abilities to accurately monitor the good actors movements, but it may afflict our ability to track movements of the bad actors were they able to tamper with emitted by the tire IDs to mimic a secure-facility employee's car.

@mikaeleiman
> there”s RAM and CPU on small embedded devices.

This. You can think of attesting just KDC with ML signature, likely, on some bigger silicon, but not on a half of coming cheap STM lines for example.

Time to study rfc4120 and siblings :(

@filippo

I'd like to ask whether migrating Ed25519 to Ed448 makes any sense? At least temporarily. Setting aside all that owful implementation disadvantages of Ed448.

@ohir @mikaeleiman nope, the distance between now and Ed25519 is way larger than between Ed25519 and Ed448.