This isn't how cryptography engineers think about cryptography. It isn't like a PHP program, where there's inevitably going to be some bug found somewhere, and you do what you can to find as many as you can and react responsibly when more are found later; cryptography engineers use formal methods (among other things) to foreclose on vulnerabilities. The vulnerabilities documented in this paper are "own goals", not cryptographic inevitabilities.

For instance, the weird authentication scheme that gives rise to the RSA key recovery attack --- that problem is what PAKEs are for.

>This isn't how cryptography engineers think about cryptography.

That is my point exactly, it should be how they think about it. Attacks to the cryptography math itself are only a single vector, the software implementation of it is going to have holes not to mention those beyond it from the hardware at the chip level to the firmware that runs it there are vulnerabilities well outside the math itself.

These are cryptography researchers, talking about cryptography vulnerabilities. The premise, both of the paper and to the comment upthread, is: we should have fewer cryptography vulnerabilities, and could accomplish that by not having people come up with random authentication and key escrow protocols.

I'd argue the opposite actually. Device owners pay a much higher cost in maintaining multiple, incompatible, devices that each require their own procedure to upgrade, means of notification, etc.

In addition a lot of security when things are fragmented tends to become "security through obscurity". Something that is a small player in a market can still have all sorts of issues that a state-funded actor can find via analysis and exploit. It's also much less likely to have a public actor find and disclose the issue due to the small install base.