I've programmed a simple One-Time Pad "encryptor" that can merge two files into one by using bitwise XOR.

The pseudo-random key files are generated by using the CryptGenRandom() function from Microsoft's CryptoAPI library. Now I am wondering whether or not to code plugins for commercial True Random Number Generators.

My question is: what are the practical problems in deploying OTP with TRNG, other than requiring users to have the special hardware in the first place?

  • 1
    CryptGenRandom is no true RNG. So you get the annoyance of a large pad and the inability to use public key crypto but don't benefit from the information theoretical guarantee of an OTP. Dec 30, 2015 at 13:56
  • @CodesInChaos The function CryptGenRandom() is supposed to be cryptographically secure, according to Wikipedia at least. Am I mistaken to believe that is practically good for OTP?
    – Log
    Dec 30, 2015 at 14:21
  • 1
    If "merely" cryptographically secure is enough, you could use a stream cipher. The whole point of an OTP is that it's secure against computationally unbounded adversaries and can't fall to advancing cryptoanalysis. Dec 30, 2015 at 14:29
  • Is there such a thing as "computationally unbounded adversaries"? Or is that just a euphemism for people with access to a network of supercomputers?
    – Log
    Dec 30, 2015 at 14:33
  • 1
    "Computationally unbounded adversaries" is exactly what it says it is. Information theoretic perfect secrecy is based on the fact that an adversary with unlimited computing power (not just what is practical possible, but truly unlimited computational power) still cannot decipher the message. A one time pad only offers this because it uses a TRGN. A CSPRNG can never offer this level of security. It has been proven mathematically that this is so.
    – Xander
    Dec 31, 2015 at 3:04

1 Answer 1


First, let's get some terminology straight. In order to call something a one-time-pad, the key must be truly random. So with that in mind:

You almost asked two separate questions:

  1. I am using CryptGenRandom() to generate my key. Is this good enough or should I consider using a TRNG?

  2. If I use a TRNG, what practical problems, if any, are there in deploying OTP with TRNG?

For Question 1, as I understand it, the only way anyone has ever successfully cracked (i.e. re-generated the proper seed) for CryptGenRandom() is by gaining access to the original machine where the key was created. And that was using a flaw in Windows 2000 which is 15 year old technology. So, based on that (combined with smart people at MS claiming it's cryptographically secure), I would argue that yes, CryptGenRandom() should be practically good enough to be used for key generation.

That being said, some high bit encryption should be good enough too, and if someone is thinking about using OTP instead of some other method of encryption, they are likely paranoid to the point that good enough isn't going to cut it. In other words, if you're going to implement something that you can truly call OTP, it must be absolutely impossible to crack your implementation without the key, which you cannot accomplish unless you use a TRNG.

As for Question 2, IMHO, there are no practical problems with using a TRNG. The reason is that only 1 trusted party involved in the communication needs to have the TRNG, not everyone. The harder problem is with key distribution, not key generation. The party with the TRNG (USB dongle or some other contraption) could generate a large set of random data, and then distribute the data to all involved parties. Each party when sending a communication would then simply need to specify the offset into the random data where their key begins. When the random data set is used up, a new data set can be generated.

However, the fact that someone involved in each communication has to initially obtain a hardware device in order to create the key may be considered a "problem", depending on how you look at it. This could have an effect on your "sales pitch", so to speak, since you won't appeal to impulse users who want to send a message with unbreakable encryption right now; all new users will have to wait some amount of time to obtain the TRNG device. You could consider using a service such as www.random.org, but if you do that, your ultra-paranoid users may not like the fact that the key is being downloaded over measly SSL!

TLDR; Regardless of whether you use CryptGenRandom() or a TRNG, the hard part is not actually in key generation, but in distributing the keys to each party so they can decrypt the message.

  • If you use CryptyGenRandom(), you do not have a OTP, you have a stream cipher.
    – Xander
    Dec 31, 2015 at 3:06
  • @Xander - technically, if you take your comment as it is without any context, you are correct. However, in the spirit of the OP, that is not relevant. The question isn't about semantics, but practicality. The OP has written some software to perform the OTP algorithm. It takes a key and a message. Now we are discussing PRNG vs TRNG for generating the key. If the PRNG is at least as long as the message, the "stream cipher" may be "good enough" for the "OTP algorithm". Both I and OP (and I presume you) agree- TRNG is the preferred choice for implementing the key used in the "OTP algorithm".
    – TTT
    Dec 31, 2015 at 4:06
  • 2
    There is no such thing as a "OTP algorithm." Either you have a one time pad or you don't. If you use a CSPRNG to generate the keystream, you don't. Misleading the OP with incorrect terminology isn't helpful to him, or future users.
    – Xander
    Dec 31, 2015 at 4:09
  • @Xander - yeah, I concede defeat in this argument. You're right. I've updated my answer. Thx.
    – TTT
    Dec 31, 2015 at 4:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .