I came across this little HRNG widget and was really intrigued as I have been looking for a decent but afordable source for truly random bits to use in a one-time pad.

The question is, would a HRNG like this one generate bits with sufficent randomness to provide the perfect secrecy one-time pads are known for? Such a design is of course slightly less random than a quantum RNG using decaying radioactive materials, but is the output random enough to be relied on?

If yes, would XORing the output bits with the plaintext be enough?

  • $\begingroup$ It would be hard to give a reliable answer to your question without seeing the actual electronic schematic for this device. What kind of noise generators are used, how is the noise stream sampled, ect? $\endgroup$ – William Hird Oct 10 '12 at 0:07
  • $\begingroup$ entropykey.co.uk/tech well this is all info I have i'm afraid, and I'm not really too gifted when it comes to the technicalities, but maybe it tells you more than it does me. @WilliamHird $\endgroup$ – youjustreadthis Oct 10 '12 at 0:14
  • 1
    $\begingroup$ I just read your link, it looks a lot like the old Intel RNG ( the new generator uses gate metastability to generate chaos). Given all the post-processing of the raw bits, it looks like it would be hard for an attacker to break it. But remember there are no guarantees of perfect randomness. To prove that a RNG is unpredictable is still an open problem. $\endgroup$ – William Hird Oct 10 '12 at 1:37
  • $\begingroup$ @WilliamHird I just ordered one, so we'll see :) I have no intention of using it for highly sensitive stuff, but I would like to have the ability to generate fairly to very good one time pads. geeky fun. the price is OK as well compared to the £400 alternatives. $\endgroup$ – youjustreadthis Oct 10 '12 at 15:11

sufficient randomness

The Whirlygig RNG -- and some other similar low-cost hardware random number generators a b -- have published schematics.

Yes, such a hardware random-number generator gives more than sufficient randomness to produce one-time pads. It seems quite possible that this Simtec "Entropy Key" works just as well, although it's hard to say without looking at its schematic.

In such systems, typically the raw data samples produced internally are slightly biased, but the system uses a "whitening" algorithm (aka "randomness extractor" aka "decorrelator") that takes large blocks of such slightly-biased bits and produces small blocks of completely uncorrelated bits ("high quality randomness").

The Whirlygig RNG produces over 500 KBytes/s of high quality randomness. While pseudo-random number generators running on commodity desktop machines run many times faster, I find it hard to imagine any application for high-quality random numbers where 500 KBytes/s is "too slow".

With a properly implemented randomness extractor, as long as the HRNG is in a physically secure room, most conceivable "attacks" (through-the-air electromagnetic interference, through-the-power-lines electromagnetic interference, etc.) at worst merely slow down the rate at which high-quality random bits are produced; they don't reduce the quality of whatever bits are produced. (The randomness extractor automatically compensates for any reduced quality of the internal raw data samples, throwing out "suspicious" samples).

message authentication

As Thomas pointed out, a MAC on top of the OTP is a good idea.

As long as we encrypt-then-MAC -- as recommended by the answers to Should we MAC-then-encrypt or encrypt-then-MAC? -- the ciphertext still has perfect secrecy: the ciphertext could potentially decode to any conceivable plaintext, and even with the help of the MAC it's not possible to rule out any conceivable plaintext of the same length.

Quick proof:

Say Eve obtains a block of ciphertext C produced by Alice using the one-time-pad algorithm. If Eve doesn't know the OTP block R that was used to produce it, ciphertext C could have been produced by any conceivable plaintext -- perhaps message P1 combined with R1 == P1 xor C; or perhaps message P2 combined with R2 == P2 xor C; or etc.

Say Eve then obtains the MAC tag that Alice generated from that ciphertext and Alice's MAC secret key using the encrypt-then-MAC system.

With any of these potential messages P1, P2, etc., since the ciphertext C is the same, and the MAC secret key is the same, the MAC algorithm would generate identically the same MAC tag in all cases, and so the MAC tag is useless to Eve for discriminating which particular message Alice is trying to send. Even if Eve somehow obtained the MAC secret key (which would be bad for Alice in other ways), Eve still wouldn't be able to narrow down which plaintext message Alice is trying to send without more information.


would XORing the output bits with the plaintext be enough?

Yes, for the easy part of the OTP -- encryption -- XORing the plaintext bits with the high-quality random bits is all that's needed.

The more difficult parts of implementing OTP still remain: Somehow transporting the high-quality random bits so both Alice and Bob, but no one else, has a copy of the OTP key. Somehow securely erasing each block of the key immediately after it is used for the one and only time each block is used. Etc.

| improve this answer | |
  • 1
    $\begingroup$ Wow that was one of the most thorough answers I've come across on these forums. Thanks for taking the time and for such good input! $\endgroup$ – youjustreadthis Oct 11 '12 at 16:14
  • $\begingroup$ @youjustreadthis If you still receive this, then please consider accepting the answer. $\endgroup$ – Maarten Bodewes Apr 2 '17 at 21:42

If this is a good HRNG (look for security reviews) I suppose yes. But it would be excruciatingly slow (HRNG's are not known to be fast, generally you use them to get 256-512 entropy bits to seed a PRNG and go with that) and you still have the key exchange + reuse OTP problem.

Note this tool apparently integrates itself with the Linux entropy pool, so I'm not sure you can actually access its raw output directly without it getting mixed with the rest. Perhaps there is an API for that. Using the Linux pool also means you will starve the system from entropy as your program eats it all to create a one-time pad... probably not a good idea :)

Remember you still need integrity checking.

| improve this answer | |
  • $\begingroup$ yes it probably wouldn't be fast at all, but nevertheless I think I'll contact them regarding the access to raw output. One benefit of one-time pads though, assuming a large enough key is physically delivered to the intended reciever, say a friend, that friend could then at any point recieve an encrypted message and safely decifer it should need be. Certainly it is not practical for most things but for that sort of use it's perfect (ish, your point about integrity stands). $\endgroup$ – youjustreadthis Oct 9 '12 at 23:15
  • 1
    $\begingroup$ Avalanche noise isn't particularly invulnerable to external EM, either. With a decent antenna and some maths you can skew the generator, or at least disrupt the quality of the random source. If you're looking at NESSIE spec security or similar, an attacker with physical proximity to the device should most definitely be considered a potential threat. $\endgroup$ – Polynomial Oct 10 '12 at 7:35
  • 1
    $\begingroup$ You're wrong about the MAC. Encrypt-then-MAC ensures that the MAC doesn't leak anything about the plaintext. | As a side-note: There are provably secure MACs(search for universal hashing or Wegman-Carter) even for computationally unbound attacks. They obviously still have small finite chance of failing to detect a manipulation, but that chance is independent from the attackers computational power. (Assuming the underlying key-stream is perfectly secure.) $\endgroup$ – CodesInChaos Oct 11 '12 at 10:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.