Home Forums TrueRNG Hardware random number generator Use of TrueRNG with OpenSSL

This topic contains 7 replies, has 4 voices, and was last updated by  dgv 7 months ago.

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • #949

    pe0fko
    Member

    I like to use the TrueRNG with OpenSSL and installed the device with the rng-tools on a Ubuntu server. It works and the entropy show a good value (+/-3800) on the VMware server.

    Now the /dev/random must return a good random stream and that looks OK, but how about the /dev/urandom ? The OpenSSL lib and tools are using the /dev/urandom for the internal PRNG to feed the saved seed in .rnd.

    What I understand is that the /dev/urandom device will use the same entropy pool as the random device (Wiki), only it will not block. So using the /dev/urandom device will use the data from the TrueRNG (when the entropy is high) and the generated keys from openssl will have a high entropy?

    Kind regards,
    Fred Krom.

    #951

    ubld.it
    Keymaster

    On some systems, /dev/random and /dev/urandom are the same device. For instance OSX and FreeBSD, which implement (I believe) some smarts as to feeding real entropy when available, and pseudo random numbers when not available (to not block).

    However, on most Linux distributions, random will block when no entropy is available (and it uses real entropy) and urandom will not, however, I don’t believe that urandom uses any real entropy what so ever, it is all pseudo random.

    It is most likely possible to change the default OpenSSL behavior (to use random versus urandom) but I’m pretty sure that currently reads from /dev/urandom have no correlation to the entropy feed in by the TrueRNG.

    So on my own test, I turned off the TrueRNG feeding by rng-tools so my entropy would be pretty low. I started logging the /proc node for entropy available. Then I did a read from urandom. I don’t see a noticeable change in entropy available. Without the TrueRNG feeding I’m bobbling from around 130-180. So then I thought, maybe each read gets seeded by a real random number. So then I created a while loop in bash and did hundreds of small reads while I logged entropy available. Same thing, bobbling. Then I did a single read from /dev/random. available entropy drops to near 0 and stays there until the amount of data I requested is fulfilled.

    So I have no reason to believe urandom is using any real entropy (and sadly not being aided in any way by the TrueRNG).

    #993

    atoponce
    Member

    First, TL;DR- use /dev/urandom. More info here: https://pthree.org/2014/07/21/the-linux-random-number-generator/

    However, on most Linux distributions, random will block when no entropy is available (and it uses real entropy) and urandom will not, however, I don’t believe that urandom uses any real entropy what so ever, it is all pseudo random.

    Not quite. First off, entropy isn’t something you use. Entropy is a measurement, not an object. You don’t “use entropy”, you “estimate entropy”. When you have an entropy estimate value, it’s giving you an approximation of how unpredictable something is, in this case, the state of the computer. As the computer works on algorithms, its state becomes more predictable. As such, the entropy estimate decreases. But it’s important to understand that you’re not “using entropy”. You’re putting your computer into a more predictable state, and the entropy estimate is decreasing.

    Second, both /dev/random and /dev/urandom have entropy estimates. In fact, there are three “entropy pools” with the Linux CSPRNG. They are the “input pool entropy”, the “blocking pool entropy”, and the “non-blocking pool entropy”. The input pool value is what is read at /pool/sys/kernel/random/entropy_avail, and has a maximum value of 4096 bits. The other two pool values are not available via userspace tools, and have a maximum value of 1024 bits.

    Thirdly, both /dev/random and /dev/urandom use the exact same cryptographically secure pseudorandom number generator (CSPRNG). The only difference, is when the input pool entropy estimate is decreased to 0, the blocking pool will stop producing numbers from the CSPRNG, whereas the /dev/urandom device will not.

    What’s important to understand here, though, is BOTH /dev/random and /dev/urandom use a single shared CSPRNG. Further, the output from /dev/urandom is indistinguishable from true random data. It is no less insecure than /dev/random., and /dev/random is no more secure than /dev/urandom. The only thing that can be said about /dev/random is that performs worse than /dev/urandom for outputting pseudorandom numbers for the Linux kernel CSPRNG.

    If you feed a TRNG into the input pool for the CSPRNG, you will only prevent /dev/random from not blocking. However, the CSPRNG mixes data using the SHA-1 cryptographic hash function. So, data coming out of /dev/random and /dev/urandom is nothing more than SHA-1 mixing of the input pool, which includes the TRNG. So even if you add the TrueRNG to the Linux kernel CSPRNG, the output ends up being pseudorandom anyway.

    Finally, most mature cryptographic software uses the non-blocking pool to get its random numbers. This includes OpenSSL and libssl, OpenSSH, Kerberos, and OpenVPN. GnuPG relies on /dev/random to ensure that the state of the computer is kept in an unpredictable state, while getting random numbers to generate an assymmetric key pair. This doesn’t mean that the keys generated by GnuPG are any more “secure” than those generated using /dev/urandom. Some immature cryptographic software relies on /dev/random for its random number source, such as apg(1). All this does is piss off users, due to poor performance, and it doesn’t provide any more secure output than what in supplied by /dev/urandom.

    • This reply was modified 3 years ago by  atoponce. Reason: minor edits
    • This reply was modified 3 years ago by  atoponce. Reason: clarification of the trng
    #1001

    pe0fko
    Member

    Thanks atoponce for your detailed response!

    I did change the config to use the /dev/urandom again for the openssl package. I will rely on the knowledge of your Cryptographers, the developers of CSPRNG and OpenSSL.

    Thanks!
    Fred.

    #1712

    dgv
    Member

    Hello random guys,

    I just received a TrueRNGpro device and I took a week-end to write an OpenSSL engine for it.
    I have wrapped up as a GNU package, with the “./configure –prefix=… -enable…” things — with a GNU-compatible license.
    Done on a Debian Linux, not tried/tested on any other system. Should work with TrueRNG.
    If you are interested, just tell me how to send you the package.

    cheers,

    Denis/

    #1715

    ubld.it
    Keymaster

    Sure Denis, if you have it hosted somewhere just post a link here. Otherwise try emailing it to support@ubld.it and we will link it up. If it’s too big it will have to be dropboxed or something.

    Thanks again.

    #2085

    dgv
    Member

    Hello all,

    This short post to inform that the library package is available at

    Please notice that the package does *not* implement an OpenSSL engine (the engine feature having been abandoned by the latest versions — e.g. LibreSSL), but rather provides functions to inject directly random bytes from a TrueRNG device into the OpenSSL random pool. This mechanism is documented into the EXAMPLES section of the truerng(3) manpage.

    cheers,

    Denis/

    #2086

    dgv
    Member
Viewing 8 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic.