You still need sufficient shared information as a starting point to authenticate the other party, so that doesn't really avoid the need for a secure side channel. In practice we often trust that the baseline of certificates that come with a new device or built into a browser are sufficient for this purpose, but there is still an attack surface there and our existing CA infrastructure and processes are not perfect.
Using side channel to share single 512-bit key that is used to generate other keys keys is enough.
If you share one master key for long time, having (effectively) 128-bit secret shared state is too small.
Right. And the first RCE+escalation 0-day will enable someone to wipe out your accounts.
What might make more sense is if they gave you a usb drive that was good for a thousand transactions or whatever. Then you could get it replaced in person after the pad was used it.
I didn’t read the article (paywall), but unless they are talking about quantum computers, the computation required to break the key and encrypt the data has a exponential difference. If we all started using keys that were, say, 2^32 bits long, we would be fine for the forseeable future.
Think about it. How much actual secure data do you and your bank need to transfer back and forth? Certainly not web UI elements or site chrome. For each use of your online account, there's probably 3 or 4k max actual data that you need to be secure. Your bank could mail you a 1GB random noise file, perhaps a backup, and you two could communicate for the rest of your life without any fear of anybody understanding what you're saying.
I understand that there's an entire e-commerce ease-of-use scenario where secure communications becomes mission-critical. And I'm certainly not suggesting to replace all secured comms. My only point is that there are parts of this problem that are very tough and there are parts of this problem that we have made more difficult than it has to be simply in an effort to standardize and abstract everything.