How?
How?
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.
Installing certs is just as regular as installing patches, do it every 6 months if you like, but certainly not every 10+ years!!
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.
That's what happens with passwords.
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".
Both parties can deduced that offset from the messages they perform.
Before reaching the end of that key, they can agree on another source for a new key to continue the communication.
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?
If I need encryption for one of my projects, I'll try that.
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.
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.
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".
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.
You're talking about who and not what because the "what" is proven to be unbreakable. You're dishonest.
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.
You feel threatened because you invested time in those tools. It's not rational. It's an emotional reaction.
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?
IMO you just wanna be loyal to the group you think you belong to (you said "we"). I don't do that. I decide for myself only.
You don't admit your part. You just just justify your feelings. If you feel threatened, it's your problem. Not mine.
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.
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.