QRNG hardware sources

Good afternoon. I was aware of the Psyleiron QRNG hardware, but their website isn’t up to date and it looks they ceased their operations, or at least they stopped selling/producing new hardware. What alternatives do I have? I’m looking for a portable QRNG to be used with a Raspberry Pi

There’s a decent list of hardware-based RNGs here (some of which are QRNGs): GitHub - atoponce/awesome-hwrng: A curated table of hardware random number generators

Or this: Random Number Generator

Or API-based: https://quantumnumbers.anu.edu.au/

Scott provided me with multiple MED devices a couple of years ago and I’ve made them available via a public API. We call it the MEDFarm.
Details here:

You said you can provide data from multiple devices at once. I am having an issue getting data simultaneously from two MED100K generators at the same time on the same computer. Have you solved this?

Yes.
The MED Farm is a Python API web server (based on work done by several members of the original Randonautica crew, namely Newton, Tobias, Andi and myself) that uses the C++ MeterFeeder driver I developed based on the FTDI code you shared with me a year (or maybe two by now… I can’t recall) with me.
MeterFeeder allows for multiple MED USB devices to be connected to the same machine at once.

To be completely honest though, the MED Farm API server doesn’t have any kind of queing/locking mechanisms in place so there is a certain assumption that there won’t be a heavy/constant request for entropy from the same device at the same time. In it’s current implementation it’ll be a kind-of first-come-first-served basis.

I currently have 6 MEDs connected to the API server machine (sitting under my TV in the living room).
QWR4E004,QWR4B001,QWR4A013,QWR4A003,QWR4E002,QWR4B008

It’s no problem connecting two or more generators to one computer at the same time. What I meant by my question is, can data be taken literally at the same time from two different generators at their full generation rate.

Yes it can.

Technically speaking, if you were to have for example a multi-threaded application with each thread responsible for getting data from a single device (and for simplicity sake, ignoring multicore CPUs and the inner electronic workings of USB (that I don’t know anything about)), the threads would be sequentially processed but fast enough to say “the data can be taken at the same time from multiple generators at their full generation rate”. It’s analogous to having a USB keyboard and mouse connected, using them at the same time as perhaps copying something to a USB storage drive.

The MEDs’ bandwidth are in the magnitude of Kbps whereas standard USB 2.0 or 3.0 are Mbps so with the amount of devices we’re talking bandwidth shouldn’t be an issue.

In my attempt at developing my comparison tool (in Unity) I think I had up to eight devices graphing their data in real-time at one point.

Can you please elaborate a it more on the issue you’re having?

The comparison program that David is working on has two generators connected. Apparently it takes a certain amount of time to turn one off and the other one on to take data from each. The problem at the moment is I don’t know exactly what the issue is. I will have to ask and get back to you.

Understood.
Will be be up to joining this forum?

And do you know if he’s used MeterFeeder or his own implementation?

I noticed Dan’s Python code directly communicates with the MED via the Python FTDI module which is good. Saves the overhead and complexity of calling C++ code from Python.

He is using some modified code from MeterFeeder. Could you look at it to see if he is doing something incorrectly?
/**

  • MeterFeeder Library
  • by fp2.dev
    */

#include “driver.h”

#include
#include

#define MAX_ERROR_REASONS 16
#define MAX_ERROR_REASON_LENGTH 256
#define MAX_SERIAL_NUMBER_LENGTH 32
#define MAX_SERIAL_NUMBERS 2
#define MAX_TRIAL_BYTES 4096
#define TRIAL_BYTES 2501

extern char errorReasons[MAX_ERROR_REASONS][MAX_ERROR_REASON_LENGTH];
extern char serialNumbers[MAX_SERIAL_NUMBERS][MAX_SERIAL_NUMBER_LENGTH];
extern int rngBytes[MAX_SERIAL_NUMBERS][MAX_TRIAL_BYTES];
extern int rngNumBytes[MAX_SERIAL_NUMBERS];
extern int numRngs,numErrors,trialBytes;

int meterfeeder (void);

int meterfeeder() {
using namespace MeterFeeder;
Driver* driver = new Driver();
string errorReason = “”;
numErrors=0;
if (!driver->Initialize(&errorReason))
{
strcpy(errorReasons[0],errorReason.c_str());
numErrors++;
return -1;
}
// Else, read entropy from all the connected devices
vector* generators = driver->GetListGenerators();
if (generators->size() == 0)
{
strcpy(errorReasons[0],“No generators”);rs.numErrors=1;return -1;

}

for (size_t i = 0; i < generators->size(); i++) {
	Generator *generator = &generators->at(i);
	int len = trialBytes; 
	UCHAR* bytes = (UCHAR*)malloc(len * sizeof(UCHAR));
	driver->GetBytes(generator->GetHandle(), len, bytes, &errorReason);
	if (errorReason.length() != 0) 
	{
	    strcpy(errorReasons[i],errorReason.c_str());
	    numErrors++;
		errorReason = ""; // reset error for next device
		continue;
	}
	strcpy(serialNumbers[i],generator->GetSerialNumber().c_str());
	for (int j = 0; j < len; j++) rngBytes[i][j]=(int)*(bytes+j);		    
	delete bytes;
	rngNumBytes[i]=len;
}
numRngs=generators->size(); 
driver->Shutdown();	
return(0); 

}

Hi Scott,
I think I need some more info before I can debug this.
Feel free to connect me and Dan directly via e-mail if he’d prefer to chat there.

In the meantime I’d like to know:

  1. Where are the extern ints/chars being defined? Can I get that source code too?
  2. What OS (Linux/Mac/Windows) is he developing on?
  3. Can he share his compile/build commands with me please?
  4. What’s the amount of time he’s experiencing between getting data from each device?