Hacker News new | past | comments | ask | show | jobs | submit login

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.



Only the length of the message.


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.

That's what happens with passwords.


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".


Those problems exist with current systems. There is a phase where the two parties must recognize themselves and agree they are legit.


Yeah and you need a new one for every message.


No. You can have a single secret covering many messages.


And totally throw out the "one-time" part of "one-time pad".


No. The secret can be longer than the sum of all messages.


This sounds less like a one-time-pad and more like a random string broken off into multiple individual one-time-pads.


No. It's just an offset inside the key. Once a message is sent, the offset is increased of the size of the message.

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.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: