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.
People have the right to criticize whatever they think is a problem. They don't need to be competent. It's just their applied freedom to think. I just mentioned my lack of interest in crypto to prevent what happened but I'm not surprised that it was useless.
IMHO most people defending HTTPs do that by loyalty because they invested so much time on that and not because they understand all the details of the crypto behind.
My message is just: "It's overcomplicated. I quickly found an alternative. I don't buy the meme".
> My message is just: "It's overcomplicated. I quickly found an alternative. I don't buy the meme".
That's exactly my point though. Your proposed alternative does not solve the problem.
We didn't reject your alternative because we think you're incompetent. We didn't reject your alternative because we think HTTPS is fine.
We rejected your alternative because it DOES NOT SOLVE THE PROBLEM. AT ALL. And rather than admit that, you keep defending a point that nobody is arguing against.
Earlier, I asked you a question to try to lead you to understand why your proposal was wrong, and you told me to answer my own questions and called me patronizing.
You continued to defend a point (OpenSSL and PKI have problems) that nobody argued against.
Even now, you keep acting like I'm telling you wrong simply because you admitted you're not into crypto.
And you're calling ME dishonest?
I give up. At this point, I'm quite certain I'm being trolled. Or you think being told you're wrong is a personal attack. In either case, you're not worth my time.
Yes you are. Look at your messages and mines. You're the troll. You use "?" and upper case a lot. I don't. You always try to change subject instead of agreeing on the problem. It's a lack of integrity.
You feel threatened because you invested time in those tools. It's not rational. It's an emotional reaction.
I use question marks because I'm asking questions. By having you consider what the answer would be, it would lead you to understanding why you were wrong, rather than me having to be explicit. It is an attempt, albeit possibly a poor one, to teach you something by getting you to think about it, rather than being told. If you would rather I just tell you why one-time pads don't solve the problems of PKI and the additional code bloat of using OpenSSL, I will gladly do that.
I use upper case because your responses are frustrating me, because you continue to insist that your suggestion is being dismissed simply because you're not into crypto, when I have said over and over that it was dismissed because it is simply not a valid solution to the problem originally brought up.
Your claim that I keep trying to change the subject instead of agreeing on the problem is baffling me. Which problem are you referring to here?
Maybe I'm just entirely misinterpreting your messages, because you're never specific about what you're trying to refute.
> It's an emotional response.
An emotional response to what? Please be clear here. Are you still thinking the rejection of one-time pads as a solution to the problems of OpenSSL and PKI is not based on logic or merit, but somehow based on emotion? If the answer to this is yes, then just come out and say so, because I would gladly explain what is wrong with your proposal.
> IMO you just wanna be loyal to the group you think you belong to (you said "we")
What group do you think I'm trying to be loyal to? The fans of OpenSSL? The people that believe everyone should use HTTPS?
> You don't want to admit your part.
What "part" am I supposed to be admitting?
> You just justify your feelings.
...and?
> If you feel threatened, it's your problem.
I don't feel threatened. Why would I feel threatened? You're the one that is acting persecuted for having a proposal get rejected.
OK Daniel for the flamewar but I have been correct. I only replied. Some people are aggressive. I just said them they are and how they are. They don't like that et it continues endlessly. It's not possible to be a gentleman in those cases.
At the risk of re-igniting the flame war, I want to explain why one-time pads are not the solution, because you kept insisting that I rejected your proposal because I wanted to be loyal to the pro-HTTPS crowd, and not because one-time pads won't actually work.
If you find this patronizing, I apologize. I do not mean to be. But you admit that you're not into crypto, and so I'm assuming you don't understand why your proposal wouldn't work. At the very least, I don't know what you know and don't know.
So, as mentioned, supporting HTTPS on your site adds the problems of OpenSSL's large code base, a history of OpenSSL vulnerabilities (Heartbleed being very well known), and the problems of PKI. These are all well-known, and are deemed an acceptable risk because the risks of NOT using HTTP are much higher.
Now, one-time pads definitely have a lot of benefits. First, they're the only algorithm mathematically proven to be unbreakable when used properly. They are extremely simple to implement, and using them for encryption instead of having to choose between the dozens of algorithms that OpenSSL uses could reduce your encryption library's memory and storage footprint.
Of course, the big caveat here is that they are unbreakable when used properly. This means:
- A pad can never be used more than once -- If a pad is used twice, then an attacker that has sniffed two encrypted messages can derive the pad, and therefore decrypt all message encrypted with that pad. This derivation is quite trivial, especially for text data. (see https://crypto.stackexchange.com/questions/59/taking-advanta...)
- The pad must be at least as large as the payload -- If the pad is too short, you have to repeat the pad, causing the problem mentioned above.
- The transferring of the pad needs to be done over a secure channel -- You have to assume that an attacker is always listening and can see all traffic. Even if the server tells the client "Go get the pad from this URL", then the attacker will get that URL as well. Also, keep in mind that the pad needs to be at least the size of the data being sent, which means that if you have to fetch a pad, you're doubling all bandwidth requirements.
- The random number generator used to creating a pad must be cryptographically secure -- Being able to predict the supposedly random numbers another system is generating is a pretty known attack and has had several proofs of concept. Generating the amount of cryptographically secure numbers to create a one-time pad large enough for transferring very large amounts of data just isn't feasible.
- One-time pads do not solve the problems of PKI -- One-time pads do not offer any method of authentication. They're nothing more than a form of symmetric encryption, and symmetric encryption does not attempt to solve the problem of authentication.
That's basically the gist of it. If you want me to explain anything better (Like what symmetric encryption is, and how it differs from asymmetric), I'd be more than happy to. I'm not a crypto expert by any means, but I like to think I have a strong grasp of the basic concepts and ideas.
How?