[dgv]

Hello all,

I am going to retire soon and will shut off the web site used to distribute the package “truerng-4.0”.
If anyone ever needs it, just post a request on this thread and I will send it directly.

Best random regards,

Denis/

[dgv]

Hi Tobias,

On Linux, you may simply use “head -c 10 /dev/TrueRNG” to obtain 10 bytes from your device.
This is the simpler way.
Of course, you may adapt the device path to your particular context, and the number of bytes needed.
Keep in mind that the device produces random *bytes*, not number. So it is your responsibility to transform the random bytes to whatever number range you need.

Good luck,

Denis/

[dgv]

Hello redneonglow,

You’re touching here a delicate issue: make your OpenSSL installation be
aware of a custom engine.

The bad side is that openssl 1.0 has a different setting than version 1.1

The good side is that your openssl installation is telling you what it expects.
The first line of the error msg says it is looking for
/usr/lib64/engines/libtruerng.so

So try to define a soft-link “libtruerng.so” in /usr/lib64/engines
pointing to /usr/local/lib/libtruerng.so

Denis/

[dgv]

Oh ohhh… the missing link in the prev post is

https://sites.google.com/site/hawksoftwarepackages/truerng

Denis/

[dgv]

Hello random colleagues,

I have written (some time ago) an “engine” interface for OpenSSL, interfacing with a TrueRNG device. Now I took the time to wrap this up into the library, and I make it available to anyone who wants to use *directly* a TrueRNG device via OpenSSL (or similar packages such as LibreSSL or BoringSSL). One can have a look at the OpenSSL engine handling the Intel RDRAND; the engine I wrote is similar. It is quite easy to use in any application pgm.

The package is available at

I have tested on a Linux box with a TrueRNGpro and a TrueRNG V3 device. I have compiled successfully on an OpenBSD system. I have tried OpenSSL versions 1.0 and 1.1 and LibreSSL.

These tests are far from complete and I welcome any comment or feedback, in particular on Solaris, FreeBSD and NetBSD.

cheers,

Denis/

[dgv]

Hello,

The system call getrandom(2) is invoked within the implementation of php’s “random_int”.

Solution 1: if you have the source code of your PHP package
find the getrandom(2) call in the PHP source code, replace the 3rd argument (which should be “0”) by
GRND_RANDOM. Recompile and reinstall.

Solution 2: read directly the TrueRNG device
You may write your own function “truerng_int” which reads the device.
Ask your favorite search engine for keywords “php call c function” or “php call c lib”;
you should find documentation on how to do this.
Look at the posting “Library and pgm” in this forum for a library offering C/C++ interfaces.

Solution 3: do nothing 🙂
As a matter of fact, there is one single random pool in the kernel. The devices /dev/random and /dev/urandom
differ on their behavior for accessing this pool. With your device plugged-in, the pool should
be nearly filled most of the time, so using /dev/urandom is not a problem. See the man page urandom(4).

cheers,

Denis/

[dgv]

I confirm that usb_claim_interface is part of libusb.

What makes things fuzzy is that cenicero explicitly refers to /dev/TrueRNG, which is typically created by udev(7) on Linux.
It is then probable that libudev is installed on the system. Check with “pkg-config –cflags –libs libudev”.
If present, then using libusb is questionable; use libudev instead, or open directly /dev/TrueRNG for reading.
BTW, the configure script from the above library installation process chooses the best available method for opening/reading.

brgds,
Denis/

[dgv]

Correction on prev msg:

the library “truerng-3.0” is available at
https://sites.google.com/site/hawksoftwarepackages/truerng

Best regards,

Denis/

[dgv]

Hello,

You may open & read a TrueRNGv3 device via the

Please refer to the msg “truerng library and program” posted on this forum.

We use usb_claim_interface in file truerng_open.c

Hope this helps,

Denis/

[dgv]

Ooops…

URL is
https://sites.google.com/site/hawksoftwarepackages/truerng

[dgv]

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/

[dgv]

Hello random ppls,

The package truerng-3.0 is now available at https://sites.google.com/site/hawksoftwarepackages/truerng

It now takes into account the USB bus:dev number to select a specific device. It can also provide a listing of all connected devices.
Testing and feedback are welcome.

cheers,

Denis/

[dgv]

Hello all,

The package truerng-2.1 is now available at https://sites.google.com/site/hawksoftwarepackages/truerng

It fixes several bugs raised by Mihai in earlier postings:
1/ the library is now C++ compatible
2/ “char *” replaced by “const char *” in function prototypes where needed.
3/ supporting V3 model, fully tested.
4/ generation of the shared library is now disabled by default.

With regards to the V3 model, I discovered with great surprise that it does not have a built-in unique serial number. This raises the question on how to uniquely identify a specific device if several V3 are plugged-in. A promising approach is to use the USB “busnum:devnum”, and I have put this on my TODO list for a forthcoming version 3.0 of the package.

I have tested the package with 2 TrueRNG devices plugged-in: one TrueRNGpro and one V3 dongle. This showed that the udev rules provided by UBLD do not permit to handle correctly several devices; the /dev/TrueRNG soft link being unique.
Therefore, I propose to modify the file 99-TrueRNG.rules with:
SYMLINK+="TrueRNG TrueRNG.%n"
and 99-TrueRNGpro.rules with:
SYMLINK+="TrueRNG TrueRNGpro.%n"

This permits /dev/TrueRNG to be always created, pointing to any TrueRNG device, thus being used by rng-tools. Another unique soft link is also created, permitting access to a specific device. Here is a listing of my own system:

$ ls -ld /dev/TrueRNG* /dev/ttyACM*
lrwxrwxrwx 1 root root         7 Mar  7 20:57 /dev/TrueRNG -> ttyACM1
lrwxrwxrwx 1 root root         7 Mar  7 20:57 /dev/TrueRNG.1 -> ttyACM1
lrwxrwxrwx 1 root root         7 Mar  7 11:33 /dev/TrueRNGpro.0 -> ttyACM0
crw-rw---- 1 root dialout 166, 0 Mar  7 11:33 /dev/ttyACM0
crw-rw---- 1 root dialout 166, 1 Mar  7 20:57 /dev/ttyACM1

Best regards,

Denis/

[dgv]

Hello Mihai,

Thanks for your feedback.

The “assertion failed” problem is concerning; the only way I see to fix this is to have a V3 device to play with.
If the friendly staff at UBLD are reading this, I declare myself volunteer to adapt this package to the V3 device <wink> <wink>.

Also, I have put the C++ compatibility in my TODO list.

With regards to the difference of throughput
— I did not write “True”put 🙂 — the explanation is not simple. In order to really understand the reason, you should understand the code of the Linux /dev/random driver.
In a nutshell, Linux adds entropy into the pool *when needed*. It has its own whitening, and does not assume the entropy pool is fast, verbose, and really “random”; i.e. it does not assume there is a TRNG available.
In order to solve this issue, one may write a kernel-resident driver for TrueRNG devices, in the same spirit than the specific OpenBSD driver for the AleaII device (www.Araneus.fi).

Best regards,

Denis/

[dgv]

Hello Mihai,

Short answer (long answer below):

0/ I assume you have built the package with libudev. If not, please look at the configure output transcript and
replace below “-ludev” with the flags found by “configure”.

1/ in your file “main.cpp”, replace
#include “truerng.h”
by

// tell the C++ compiler we are using C code:
extern "C" {
#include "truerng.h"
}

2.a/ link with static library (libtruerng.so in the directory):
g++ -Wno-write-strings -o main main.cpp ./libtruerng.a -ludev

2.b/ link with static library (libtruerng.so removed from the directory):
g++ -Wno-write-strings -o main main.cpp -L. -ltruerng -ludev

2.c/ link with shared library:
g++ -Wno-write-strings -Wl,-rpath=pwd-o main main.cpp -Lpwd-ltruerng -ludev

Explainations (long answer): It seems to me that you have several issues, which I will discuss separately.

A/ You write your program in C++
The library is written in C, not in C++. So the fundamental problem is to call an external function written in a foreign language.
The basic principle is to tell the C++ main pgm that the library is in C.
This is why you should apply step 1/ above.

B/ warning: deprecated conversion from string constant to ‘char*’
This is because the prototypes are declared with “char *” and the compiler wants “const char *”.
I admit I should have done that 🙁
The easy solution is to add an option telling the compiler to shut up because you know what you’re doing.
Use -Wno-write-strings when compiling.

C/ linking with dynamic versus static library
You should put the “-ltruerng” option *after* “main”; because the linker goes from left to right for unresolved symbols.
I recommend to link with the static lib, which is easier for testing. So either you build the package
with “./configure … –disable-shared”, or you “rm libtruerng.so*”, or you explicitly use the static library filepath.

D/ the output of your main program
When you call “./main”, you should see 10 “scrambled” characters, since the main pgm prints directly the random characters.
You may prefer to pipe the output into “od(1)” in order to have a human-readable output:
./main | od -x

E/ I warmly recommend using a Makefile. This permit encapsulating flags, and easy modification.
Indeed, a Makefile is an integral part of your testing procedure. Here is a proposal:

PROG =		main
CXXFLAGS =	-Wno-write-strings
LOADLIBES =	./libtruerng.a
LDLIBS =	-ludev

.PHONY:		all check clean

all: $(PROG)

check: all
	./$(PROG) | od -x

clean:
	$(RM) $(PROG).o $(PROG) $(PROG).core core

Best regards,

Denis/

[Author]

Posts