Though 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 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.)
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.
A bank? No. Some random person out there in an oppressive government? Infinitely more likely.
Crypto is a bit of a special case in programming in that's it's ridiculously easy to do wrong, and failures could have catastrophic consequences on people's real lives. If you want to play with it yourself, more power to ya, but for the love of all things good in the world don't put it out there without sufficient disclaimer that it's a hobby, untested project.
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.
The point is that the desire to use a OTP typically hinges on it being "uncrackable".
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.
Speaking as a total novice, I've always found OTPs attractive.
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)
Here is the thing, the cryptography is really not the weak part of a communication system. You really don't gain anything by using a one-time pad over something like AES-256 in any practical sense. You're only making the part of your system stronger that is already more than strong enough (From a thermodynamics point of view you couldn't even brute force AES-256 if you had a supernova as an energy source [1]). Difficult parts of a secure communication system are authentication, key-exchange, etc.
Example how to compromise your system: I send your friend a message with some random data and pretend to be you. Now he doesn't know what's going on and you two are out of sync and cannot securely re-sync your keys without meeting up again.
> You can bruteforce AES-256 if you were using a quantum computer.
Not true. AES does not suffer from the same weaknesses as many public key schemes. A quantum computer could speed up an attack on AES, but does not fundamentally break it.
> Or if there's a new advance in algebraic cryptanalysis.
Sure. But my point was that there are much weaker points than the encryption in a communication system.
If you use a computer program to generate random numbers for a "one-time pad", you're not really using a "one-time pad"; you're using an ad hoc stream cipher keyed by your RNG.
(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.
Lovely, I'm currently taking Stanford's Criptography course on Coursera and it's both entertaining and enlightening.
I highly recommend it.
https://class.coursera.org/crypto-015/
16 comments
[ 2.9 ms ] story [ 55.4 ms ] threadQuick 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.)
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.
Crypto is a bit of a special case in programming in that's it's ridiculously easy to do wrong, and failures could have catastrophic consequences on people's real lives. If you want to play with it yourself, more power to ya, but for the love of all things good in the world don't put it out there without sufficient disclaimer that it's a hobby, untested project.
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.
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)
Example how to compromise your system: I send your friend a message with some random data and pretend to be you. Now he doesn't know what's going on and you two are out of sync and cannot securely re-sync your keys without meeting up again.
[1] https://www.schneier.com/blog/archives/2009/09/the_doghouse_...
Or if there's a new advance in algebraic cryptanalysis.
Not true. AES does not suffer from the same weaknesses as many public key schemes. A quantum computer could speed up an attack on AES, but does not fundamentally break it.
> Or if there's a new advance in algebraic cryptanalysis.
Sure. But my point was that there are much weaker points than the encryption in a communication system.
I did have a better argument here. It was point 2.
Unauthenticated encryption is dangerous:
https://paragonie.com/blog/2015/05/using-encryption-and-auth...
(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.