I bought an HWRND last week. What do you think, how secure is the encryption with that and the OTP? (http://www.moonbaseotago.com/onerng/theory.html).
$\begingroup$
$\endgroup$
11
-
$\begingroup$ Added with OTP? How are you going to transfer that? $\endgroup$ – kelalaka Nov 17 '20 at 18:49
-
$\begingroup$ I want to read a random stream from the device and encrypt a file with this and the OTP. Every byte from file will XOR with every byte from the stream. $\endgroup$ – TheDummy Nov 17 '20 at 18:52
-
1$\begingroup$ Then how are going to store the OTP key? Do you really know how the One Time Pad is working? $\endgroup$ – kelalaka Nov 17 '20 at 18:54
-
$\begingroup$ In my opinion a byte will XOR with a other byte. I can store the random bytes in a separate file. If I want to decrypt the file, Do the same with my random file and the cipher file. $\endgroup$ – TheDummy Nov 17 '20 at 18:58
-
2$\begingroup$ I think the issue kelalaka is taking here is the fact that while you can use that RNG for OTP (-like) encryption this doesn't solve the issue that now you have an encrypted file and a key as large as that file and you now have the same problem as originally: You have sensitive data that you want to protect, but this time it's the OTP key instead of the plaintext. $\endgroup$ – SEJPM♦ Nov 17 '20 at 19:17
|
Show 6 more comments
$\begingroup$
$\endgroup$
I suggest not very. And unfortunately that's a combination of user error (sorry) and poor analysis from the OneRNG project.
The use case for OneRNG is this:-
The device has been analysed solely as an entropy source, and not a fully fledged TRNG. So it is intended to be used to 'top up' Linux's entropy pool via the rngd daemon. Directly from the site:-
Remember we are not trying to make, nor claim to produce, crytptographically perfect random numbers, our goal is to produce entropy for seeding system RNGs such as the one in the linux kernel's /dev/random.
So that kinda works in theory, but:-
At what rate does OneRNG top up? There is no pertinent cryptographic analysis of the entropy stream from the device operating in cmd1 0 0 1 Raw avalanche noise mode. We can't tell if avalanche has been achieved as there is no probability mass function of the raw samples. We do know that this mode has failed ent, and ent displays the wrong type of entropy by default (not $H_{\infty}$) anyway. Not catastrophic, but $H_{\infty}$ is needed, not Shannon's version of it.
Just using CRC-16 as a whitener over raw samples creates a pseudo random number generator with an indeterminate internal entropy rate. NIST's 800-90b restart test would be appropriate here as the cyclic redundancy check starts off from predetermined initialisation values.
If you want to use a true OTP for complete secrecy like your life depended on it, this is not an appropriate device as it's not a TRNG.
Personal bug bear:- If you're going to sell TRNGs, get an oscilloscope.
