Hacker News Reader

Comment by Animats | Hacker News Reader

Those are not sufficient conditions for a one-time pad. The entire pad, not just some "seed" has to be random. The pad cannot ever be reused even with a different plaintext. Breaking a one-time pad that's been used twice is not very hard. It's equivalent to recovering two texts which have been XORed together, which is not hard for English.

One time pad systems are used regularly for high-security embassy-to-State Department communications. Since there are also secure couriers between those locations, there's a way to distribute key material. With today's storage densities, carrying key material around is easy.

View on HN

> Those are not sufficient conditions for a one-time pad. The entire pad, not just some "seed" has to be random.

Well that seems a bit pedantic, but yes, you're right. The difficulty I was focusing on however is the randomness itself, not how far it has to be extended. Ostensibly once you've incorporated a non-deterministic seed (which is necessarily external) into your process, you can extend it to the pad itself. The pad itself will just be a stream of that data, like a non-deterministic stream cipher. I get the impression you're aware of this already though, so I won't belabor it.

> One time pad systems are used regularly for high-security embassy-to-State Department communications. Since there are also secure couriers between those locations, there's a way to distribute key material. With today's storage densities, carrying key material around is easy.

Fair enough, I'll concede they have practical uses in situations where there are couriers and extremely high security requirements. That's about all they're practical for, though :)

I'm not sure I follow this, but if you're "extending" randomness from an externally-provided "seed" of random data, what you're doing is encrypting with a stream cipher, not a one-time pad.

I might be just misunderstanding you though.

Yeah that's a comparison I drew down-thread as well (w/r/t a stream cipher). "Seed" was a poor choice of terminology on my part there - the point I was trying to convey is that you'll need a non-deterministic source, which is necessarily outside of software. I used the term "seed" as a shorthand for that (as if it were a stream cipher), but strictly speaking as you say that's not correct, as you'll be taking the random data directly as a key.

So no, you're not misunderstanding - I just communicated poorly!

I don't understand how this is practical. If you have a highly secure mechanism for distributing the ultimate secret - one-time-pads - why not just distribute the messages in this way?

Is it just the fact that it would take two trips for the courier? Or that someone would need to intercept both communications (pad, ciphertext)?

A big benefit is that you can time-shift the distribution of the secret - you can distribute the one-time pad when it's convenient (e.g. when your submarine is at a home port) and be able to send secure messages over insecure channels at any future time.

Yes, this is essentially half the basis for cryptography, of which the one-time pad is one particularly rigid form. If Alice and Bob wish to communicate, they can do so by first verifying each other in person, or with a trusted courier, and from then on can communicate remotely. Alternatively, they can use public-key cryptography to communicate remotely and securely over an insecure channel without requiring face to face contact or a trusted courier.

An important note: public key cryptography allows secure communication over insecure channels, where an adversary only has the ability to listen in, but not over untrusted channels, where an adversary can actively intercept messages and edit them.

The internet is an untrusted medium, since packet switching requires packets to travel through routers that can edit them at will. (The fabled man in the middle attack) This is the whole point of the certificate issuer public-key infrastructure, where issuer public keys are included in your OS's installation files, a secure communication channel. (If you can't trust your OS, you of course can't trust any communication made with it to be secure anyway)

That's a good note - more succinctly, the key exchange can provide confidentiality, but not authentication.

It's not practical for most cases, but the few very very high-security ones. The pads are distributed beforehand, stored securely and used when a message encrypted to them comes in. So it's just that the message can have OTP security while not taking the time of a courier trip and can be just sent on other somewhat insecure channel.

Reply on news.ycombinator.com