3 ms·
> 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'r
by dsacco 9y ago
> 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 :)
- tptacek 9y agoI'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.
- dsacco 9y agoYeah 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!