I read your article about "One-time pads explained" (OTP) and the problems in exchanging them. I am thinking about...
using RSA to send them with PGP, but there is again a problem.
Considering PGP, if I want to send OTP message to another person via e-mail, PGP will first compress this OTP message. Here is the problem: Since OTP file/message is highly random in nature (obviously it should be), you can't compress it even to 1%. I experimented by creating pseudo random data generated by keystroke hooks, mouse movements, memory digest, tickcount digest, system information, etc. using a block cipher (Blowfish) and hash digest (SHA-1). I checked the file I generated for randomness by ENT. It gave good results. I decided to encrypt 2.49 MB of pseudo random data by PGP and used a 512-bit RSA key. I found the PGP message size came out to be 3.39 MB -- even when a 512-bit key is used. If I had chosen RSA 4096-bit key and then calculated the result, it is of no use to send few KB of OTP messages via e-mail the whole day.
Considering the perfect security offered by OTP, where the key size of true random data may equal or exceed the message size, can the modern symmetric algorithms of 128-bit and 4096-bit asymmetric algorithms resist cryptanalysis by government agencies? I don't think the government agencies will find any difficulty in breaking a 128-bit encryption.
A few years ago, I gave a talk called, "The seduction of the one-time pad." In it, I discuss how the pursuit of perfect security with one-time pads leads people to make suboptimal security decisions. People spend a lot of effort chasing the one-time pad, and then end up with security that is only good enough. Starting with security that is good enough and sticking to it is almost always the best thing to do.
I'm afraid you've succumbed to that seduction. Don't feel badly about it, most of us do at one time or another. But let me discuss what you did.
You are right that random data is not compressible. This is pretty much the definition of random data. Since compression algorithms like Zip work by finding repeats of data and then putting in shorthands they aren't going to find them in random data. Anything they do find should have just occurred randomly and is not going to offset the extra data that has to be put in for the compression structures. So compressed random data is most likely going to be larger than the base data itself.
Now then, let's look at how to transfer pads to your partners. Since the pads have perfect security, the true security of the system is actually the security of the courier. Let's imagine that you have an actual person delivering them. The security of the system is essentially the chance that the adversary can copy the pads without the courier noticing. That's the way to attack that system. (We'll ignore the storage security issues, as well as the issues of how well your random data was generated.)
If your courier is PGP, then the security of the transfer is the security of your PGP envelope. If that has a 512-bit RSA key, and underneath that a 128-bit cipher, then the weak point of the system is the 512-bit RSA key, which has about the same strength as a 56-bit symmetric key. So, when you encrypt that pad, you have lowered its security to that of a 56-bit key. It would be simpler and just as secure to just use a 56-bit key.
Dig Deeper on Password management and policy
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.