The Manual One-Time Pad
users.telenet.be
The Manual One-Time Pad
1–10 of 17 posts
Re: The Manual One-Time Pad
#2Quick public service announcement about cryptography.
It's true that, from an information theory perspective, OTPs are unbreakable encryption.
However, unless you have a long history of cryptanalysis under your belt, don't even think about implementing one in software. This is a common mistake people make when they're first learning about cryptography.
Pitfalls:
1. You need to get two computers to have the same large chunk of random data without anyone knowing it. This becomes a horrendous key management problem.
2. Even if you don't know the one-time pad, if you flip bits in transit, the recipient will happily decrypt them. You can forge messages at will. OTP is unauthenticated encryption.
If you think your application needs one-time pads, use elliptic curve diffie hellman key agreement and stream ciphers instead (and remember to authenticate you ciphertext).
Better yet, hook into a library like libsodium to do this for you and don't play with fire. (I know the sort of people who love one-time pads are unlikely to ever listen to this particular advice, but they can't say I didn't warn them.)
Re: The Manual One-Time Pad
#3Though the article says "One-time pad is not a practical encryption system. However, if properly used, it will be absolutely secure and unbreakable", I've had to talk developers out of wanting to implement them in their protocols before. Quick public service announcement about cryptography. It's true that, from an information theory perspective, OTPs are unbreakable encryption. However, unless you have a long history…
Imagine if a bank were to accidently mistake your OTP implementation as a viable product. Oh, the humanity.
Re: The Manual One-Time Pad
#4Though the article says "One-time pad is not a practical encryption system. However, if properly used, it will be absolutely secure and unbreakable", I've had to talk developers out of wanting to implement them in their protocols before. Quick public service announcement about cryptography. It's true that, from an information theory perspective, OTPs are unbreakable encryption. However, unless you have a long history…
Re: The Manual One-Time Pad
#5Though the article says "One-time pad is not a practical encryption system. However, if properly used, it will be absolutely secure and unbreakable", I've had to talk developers out of wanting to implement them in their protocols before. Quick public service announcement about cryptography. It's true that, from an information theory perspective, OTPs are unbreakable encryption. However, unless you have a long history…
And if you're generating your one time pads using a (hopefully cryptographically-secure) pseudorandom number generator, then congratulations! You are literally reinventing a stream cipher except with enormous, non-reusable keys.
and enormous keys too! you might need to store them on some sort of notebook or large paper thingie!
Re: The Manual One-Time Pad
#6Though the article says "One-time pad is not a practical encryption system. However, if properly used, it will be absolutely secure and unbreakable", I've had to talk developers out of wanting to implement them in their protocols before. Quick public service announcement about cryptography. It's true that, from an information theory perspective, OTPs are unbreakable encryption. However, unless you have a long history…
I agree, people shouldn't really try to enjoy their hobbies. They should just do what everybody tells them. Imagine if a bank were to accidently mistake your OTP implementation as a viable product. Oh, the humanity.
No, what you need to do, is to learn whatever you enjoy, as much as you want in any direction, but recognize your limited knowledge in the field and act accordingly.
Re: The Manual One-Time Pad
#7(Conventional stream ciphers are themselves the DRBG cores of RNGs.)
It's not that stream ciphers are bad --- but ad-hoc cryptography almost always is. Just pick a well-implemented stream cipher, one that was designed to be a stream cipher, and use that instead. One-time pads are almost useless in practice.
Re: The Manual One-Time Pad
#8Earlier quoted context omitted.
And if you're generating your one time pads using a (hopefully cryptographically-secure) pseudorandom number generator, then congratulations! You are literally reinventing a stream cipher except with enormous, non-reusable keys.
non-reusable keys! what a critique on one time pads! and enormous keys too! you might need to store them on some sort of notebook or large paper thingie!
By using a PRNG (even if it is a cryptographic stream cipher) to generate your pad, you've just re-introduced the same "crackability" (by way of the PRNG), and your system is strictly worse (same security, worse logistics) than an existing system.
Re: The Manual One-Time Pad
#9Though the article says "One-time pad is not a practical encryption system. However, if properly used, it will be absolutely secure and unbreakable", I've had to talk developers out of wanting to implement them in their protocols before. Quick public service announcement about cryptography. It's true that, from an information theory perspective, OTPs are unbreakable encryption. However, unless you have a long history…
Wish you had made a better argument here, for perhaps I'm missing it. Yep, key management is a problem. That's all I got, and I know there had to be more.
Do you know of any longer treatments of this subject? Sure would love to read them.
I mean, I'm thinking if I want to share data with a friend, I get a hardware true RNG, cut a couple of 1TB SSDs full of random noise, and hand him a copy. With that amount of data, I'm thinking he and I are good to go for the rest of our lives. (Of course, commercial applications have other constraints)