Forum Replies Created
-
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/
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/
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 -ludev2.b/ link with static library (libtruerng.so removed from the directory):
g++ -Wno-write-strings -o main main.cpp -L. -ltruerng -ludev2.c/ link with shared library:
g++ -Wno-write-strings -Wl,-rpath=pwd-o main main.cpp -Lpwd-ltruerng -ludevExplainations (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 -xE/ 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 coreBest regards,
Denis/
