Perhaps something like content based addressing, or using something like certificate transparency to protect site contents.
The problem with https everywhere is - for all its good aspects - it adds a layer of fragility to the web. It seems like we're leaving the day where a website can simply be, untouched, for decades. Now if you don't update your TLS certificates every few months, the thing goes poof.
It would be nice if there was a good way to publish content to the web without having to tend it constantly.
The only way you could do that is on a hosted platform where they do maintenance for you. There's no way a server would last online for decades without being patched, it would have been hosed countless times over by now.
Installing certs is just as regular as installing patches, do it every 6 months if you like, but certainly not every 10+ years!!
One-time pad requires a pre-shared key of the enomorous length to be effective in the World Wide Web. An impossible plan can be vacuously better and simpler at the same time, guaranteed.
The issue with one time pads isn't their security. That's fine.
The issue is key management. Both parties need the same key and it has to be at least as large as the data you want to send. Each set of parties needs a different key.
If you had a method to securely transmit such keys then you could just transmit your data over it instead.
This is why one time pads are only used by countries to communicate with staff overseas. You can send the pads by diplomatic courier for use in communication later. There is no equivalent mechanism for your web activity and every site on earth.
Yes there are. The two parties need to agree on a common source. It can be a file somewhere on the web (an image) or a something that doesn't exist yet.
How are the two parties supposed to agree when they've never talked to each other before?
If I connect to https://www.SomeWebsiteIveNeverVisited.com/, how is the web server supposed to tell me where to get the key? Or if I, the client, am choosing where to get the key, how do I securely tell the server where to get it?
Passwords work because they're being sent over TLS which we've decided is "good enough".
How is a one-time pad going to fix the issues in TLS?
Honestly, it feels like you're treating "one-time pad" as a buzzword without understanding what it actually is. It's just an encryption technique. It doesn't fix the PKI problem. And your one-time pad key needs to be sent over a secure channel. How do you suppose that happens?
You admit that you're not into crypto, yet above you tried to propose a solution to the problems with PKI, as if the people that ARE into crypto hadn't thought of it.
You show your values and you prove nothing with that sentence.
Experts are often wrong. They exist because because we don't know. When we know something we don't need experts anymore. We just know and apply our knowledge.
Keep in mind the context of this whole conversation. You suggested one-time pads as a solution to PKI and the problems of OpenSSL's large code base being added to projects that need encryption. I don't know how to put this nicely, but it just shows you really don't know what you're talking about.
Yes, sometimes experts get it wrong. Yes, non-experts can sometimes find solutions that the so-called experts couldn't find. I'm not arguing against those claims.
But suggesting one-time pads as a solution to PKI is like seeing someone on the side of the road with a flat tire and suggesting they refill their gas tank.
The problem with https everywhere is - for all its good aspects - it adds a layer of fragility to the web. It seems like we're leaving the day where a website can simply be, untouched, for decades. Now if you don't update your TLS certificates every few months, the thing goes poof.
It would be nice if there was a good way to publish content to the web without having to tend it constantly.