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...
Imagine if a bank were to accidently mistake your OTP implementation as a viable product. Oh, the humanity.
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.
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.
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.)