May 12, 2018
The purpose of this posting is to test and compare the quality of the random numbers generated by a SwiftRNG Pro device and those generated by PRNG (pseudorandom number generator) implementations available on Linux operating systems. In Linux-like operating systems,
/dev/urandom is a special file that serves as a PRNG.
For our tests we used a
/dev/urandom file available on a computer running CentOS 7 and a SwiftRNG Pro device plugged into one of the USB ports available on the same computer. The tests were performed by sampling 120 GB of random data from SwiftRNG Pro device with no ‘conditioning’ and from
/dev/urandom. The sampled random data blocks were used to feed the ‘rngtest’ test suite for statistical analysis. We also tested SwiftRNG Pro and
/dev/urandom random streams using the ‘dieharder’ test suite.
Testing with ‘rngtest’
The following charts represent comparison test results produced by ‘rngtest’. We are interested in the total number of FIPS 140-2 test failures and number of failures for each FIPS 140-2 specific test.
The total number of FIPS 140-2 failures was slightly higher for
/dev/urandom compared to FIPS 140-2 failures for SwiftRNG Pro. SwiftRNG Pro produced less failures for FIPS 140-2 ‘Runs’, ‘Long Run’ and ‘Continuous Run’ tests while
/dev/urandom produced less failures for FIPS 140-2 ‘Monobit’ and ‘Poker’ tests.
Testing with ‘dieharder’
The following are test results generated by ‘dieharder’ when testing random byte stream produced by SwiftRNG Pro device with no ‘conditioning’:
swrng -dd -fn STDOUT | dieharder -g 200 -a #=============================================================================# # dieharder version 3.31.1 Copyright 2003 Robert G. Brown # #=============================================================================# rng_name |rands/second| Seed | stdin_input_raw| 5.52e+06 | 204447751| #=============================================================================# test_name |ntup| tsamples |psamples| p-value |Assessment #=============================================================================# diehard_birthdays| 0| 100| 100|0.23189457| PASSED diehard_operm5| 0| 1000000| 100|0.75095612| PASSED diehard_rank_32x32| 0| 40000| 100|0.96073461| PASSED diehard_rank_6x8| 0| 100000| 100|0.93232326| PASSED diehard_bitstream| 0| 2097152| 100|0.32747213| PASSED diehard_opso| 0| 2097152| 100|0.74231200| PASSED diehard_oqso| 0| 2097152| 100|0.09245298| PASSED diehard_dna| 0| 2097152| 100|0.30959114| PASSED diehard_count_1s_str| 0| 256000| 100|0.86246827| PASSED diehard_count_1s_byt| 0| 256000| 100|0.33426616| PASSED diehard_parking_lot| 0| 12000| 100|0.33358085| PASSED diehard_2dsphere| 2| 8000| 100|0.45323736| PASSED diehard_3dsphere| 3| 4000| 100|0.68247073| PASSED diehard_squeeze| 0| 100000| 100|0.04045060| PASSED diehard_sums| 0| 100| 100|0.15998991| PASSED diehard_runs| 0| 100000| 100|0.20507955| PASSED diehard_runs| 0| 100000| 100|0.81059682| PASSED diehard_craps| 0| 200000| 100|0.04558382| PASSED diehard_craps| 0| 200000| 100|0.45402435| PASSED marsaglia_tsang_gcd| 0| 10000000| 100|0.62754383| PASSED marsaglia_tsang_gcd| 0| 10000000| 100|0.53365537| PASSED sts_monobit| 1| 100000| 100|0.07245620| PASSED sts_runs| 2| 100000| 100|0.49969326| PASSED sts_serial| 1| 100000| 100|0.50668731| PASSED sts_serial| 2| 100000| 100|0.87844642| PASSED sts_serial| 3| 100000| 100|0.99987535| WEAK sts_serial| 3| 100000| 100|0.96930487| PASSED sts_serial| 4| 100000| 100|0.50879386| PASSED sts_serial| 4| 100000| 100|0.22925809| PASSED sts_serial| 5| 100000| 100|0.41114562| PASSED sts_serial| 5| 100000| 100|0.85418243| PASSED sts_serial| 6| 100000| 100|0.52907030| PASSED sts_serial| 6| 100000| 100|0.79775328| PASSED sts_serial| 7| 100000| 100|0.25207091| PASSED sts_serial| 7| 100000| 100|0.45934295| PASSED sts_serial| 8| 100000| 100|0.44472162| PASSED sts_serial| 8| 100000| 100|0.54690406| PASSED sts_serial| 9| 100000| 100|0.75462311| PASSED sts_serial| 9| 100000| 100|0.59246043| PASSED sts_serial| 10| 100000| 100|0.65093398| PASSED sts_serial| 10| 100000| 100|0.36015871| PASSED sts_serial| 11| 100000| 100|0.83071639| PASSED sts_serial| 11| 100000| 100|0.99480125| PASSED sts_serial| 12| 100000| 100|0.88728666| PASSED sts_serial| 12| 100000| 100|0.84685621| PASSED sts_serial| 13| 100000| 100|0.44996132| PASSED sts_serial| 13| 100000| 100|0.84783628| PASSED sts_serial| 14| 100000| 100|0.54973990| PASSED sts_serial| 14| 100000| 100|0.98901587| PASSED sts_serial| 15| 100000| 100|0.92734287| PASSED sts_serial| 15| 100000| 100|0.74516197| PASSED sts_serial| 16| 100000| 100|0.65420669| PASSED sts_serial| 16| 100000| 100|0.91095922| PASSED rgb_bitdist| 1| 100000| 100|0.28196469| PASSED rgb_bitdist| 2| 100000| 100|0.20311887| PASSED rgb_bitdist| 3| 100000| 100|0.83371006| PASSED rgb_bitdist| 4| 100000| 100|0.97918552| PASSED rgb_bitdist| 5| 100000| 100|0.33633146| PASSED rgb_bitdist| 6| 100000| 100|0.45049719| PASSED rgb_bitdist| 7| 100000| 100|0.84676874| PASSED rgb_bitdist| 8| 100000| 100|0.18405803| PASSED rgb_bitdist| 9| 100000| 100|0.17870007| PASSED rgb_bitdist| 10| 100000| 100|0.34093733| PASSED rgb_bitdist| 11| 100000| 100|0.98757745| PASSED rgb_bitdist| 12| 100000| 100|0.33608530| PASSED rgb_minimum_distance| 2| 10000| 1000|0.40714300| PASSED rgb_minimum_distance| 3| 10000| 1000|0.01359258| PASSED rgb_minimum_distance| 4| 10000| 1000|0.40526430| PASSED rgb_minimum_distance| 5| 10000| 1000|0.00015977| WEAK rgb_permutations| 2| 100000| 100|0.42947333| PASSED rgb_permutations| 3| 100000| 100|0.70231583| PASSED rgb_permutations| 4| 100000| 100|0.14559228| PASSED rgb_permutations| 5| 100000| 100|0.39820769| PASSED rgb_lagged_sum| 0| 1000000| 100|0.95478426| PASSED rgb_lagged_sum| 1| 1000000| 100|0.48808137| PASSED rgb_lagged_sum| 2| 1000000| 100|0.75232711| PASSED rgb_lagged_sum| 3| 1000000| 100|0.30510638| PASSED rgb_lagged_sum| 4| 1000000| 100|0.32466480| PASSED rgb_lagged_sum| 5| 1000000| 100|0.34657161| PASSED rgb_lagged_sum| 6| 1000000| 100|0.79797715| PASSED rgb_lagged_sum| 7| 1000000| 100|0.69093277| PASSED rgb_lagged_sum| 8| 1000000| 100|0.62220023| PASSED rgb_lagged_sum| 9| 1000000| 100|0.75880907| PASSED rgb_lagged_sum| 10| 1000000| 100|0.60912315| PASSED rgb_lagged_sum| 11| 1000000| 100|0.68534716| PASSED rgb_lagged_sum| 12| 1000000| 100|0.56160475| PASSED rgb_lagged_sum| 13| 1000000| 100|0.50051735| PASSED rgb_lagged_sum| 14| 1000000| 100|0.03065363| PASSED rgb_lagged_sum| 15| 1000000| 100|0.46737147| PASSED rgb_lagged_sum| 16| 1000000| 100|0.96676303| PASSED rgb_lagged_sum| 17| 1000000| 100|0.63337053| PASSED rgb_lagged_sum| 18| 1000000| 100|0.62142304| PASSED rgb_lagged_sum| 19| 1000000| 100|0.04809293| PASSED rgb_lagged_sum| 20| 1000000| 100|0.71276787| PASSED rgb_lagged_sum| 21| 1000000| 100|0.78284283| PASSED rgb_lagged_sum| 22| 1000000| 100|0.39360698| PASSED rgb_lagged_sum| 23| 1000000| 100|0.06632147| PASSED rgb_lagged_sum| 24| 1000000| 100|0.79035290| PASSED rgb_lagged_sum| 25| 1000000| 100|0.22745596| PASSED rgb_lagged_sum| 26| 1000000| 100|0.98940777| PASSED rgb_lagged_sum| 27| 1000000| 100|0.59552952| PASSED rgb_lagged_sum| 28| 1000000| 100|0.76529954| PASSED rgb_lagged_sum| 29| 1000000| 100|0.96033546| PASSED rgb_lagged_sum| 30| 1000000| 100|0.34793801| PASSED rgb_lagged_sum| 31| 1000000| 100|0.56710980| PASSED rgb_lagged_sum| 32| 1000000| 100|0.87580841| PASSED rgb_kstest_test| 0| 10000| 1000|0.59457755| PASSED dab_bytedistrib| 0| 51200000| 1|0.26956602| PASSED dab_dct| 256| 50000| 1|0.43445042| PASSED Preparing to run test 207. ntuple = 0 dab_filltree| 32| 15000000| 1|0.95997359| PASSED dab_filltree| 32| 15000000| 1|0.69594477| PASSED Preparing to run test 208. ntuple = 0 dab_filltree2| 0| 5000000| 1|0.69858902| PASSED dab_filltree2| 1| 5000000| 1|0.76921713| PASSED Preparing to run test 209. ntuple = 0 dab_monobit2| 12| 65000000| 1|0.85449699| PASSED
The following are test results generated by ‘dieharder’ when testing random byte stream produced by
dd if=/dev/urandom bs=12000000 | dieharder -g 200 -a #=============================================================================# # dieharder version 3.31.1 Copyright 2003 Robert G. Brown # #=============================================================================# rng_name |rands/second| Seed | stdin_input_raw| 3.06e+07 |2868936241| #=============================================================================# test_name |ntup| tsamples |psamples| p-value |Assessment #=============================================================================# diehard_birthdays| 0| 100| 100|0.95387771| PASSED diehard_operm5| 0| 1000000| 100|0.92560719| PASSED diehard_rank_32x32| 0| 40000| 100|0.98066045| PASSED diehard_rank_6x8| 0| 100000| 100|0.20597070| PASSED diehard_bitstream| 0| 2097152| 100|0.91045462| PASSED diehard_opso| 0| 2097152| 100|0.63316244| PASSED diehard_oqso| 0| 2097152| 100|0.93774044| PASSED diehard_dna| 0| 2097152| 100|0.41448575| PASSED diehard_count_1s_str| 0| 256000| 100|0.57649363| PASSED diehard_count_1s_byt| 0| 256000| 100|0.10827822| PASSED diehard_parking_lot| 0| 12000| 100|0.79252967| PASSED diehard_2dsphere| 2| 8000| 100|0.04975508| PASSED diehard_3dsphere| 3| 4000| 100|0.99585638| WEAK diehard_squeeze| 0| 100000| 100|0.24753753| PASSED diehard_sums| 0| 100| 100|0.05653317| PASSED diehard_runs| 0| 100000| 100|0.11453525| PASSED diehard_runs| 0| 100000| 100|0.19585625| PASSED diehard_craps| 0| 200000| 100|0.45638793| PASSED diehard_craps| 0| 200000| 100|0.31591645| PASSED marsaglia_tsang_gcd| 0| 10000000| 100|0.06850479| PASSED marsaglia_tsang_gcd| 0| 10000000| 100|0.81649089| PASSED sts_monobit| 1| 100000| 100|0.99831362| WEAK sts_runs| 2| 100000| 100|0.47933569| PASSED sts_serial| 1| 100000| 100|0.15918179| PASSED sts_serial| 2| 100000| 100|0.01980393| PASSED sts_serial| 3| 100000| 100|0.26391074| PASSED sts_serial| 3| 100000| 100|0.93825883| PASSED sts_serial| 4| 100000| 100|0.48042579| PASSED sts_serial| 4| 100000| 100|0.94648402| PASSED sts_serial| 5| 100000| 100|0.88404757| PASSED sts_serial| 5| 100000| 100|0.63829590| PASSED sts_serial| 6| 100000| 100|0.87264060| PASSED sts_serial| 6| 100000| 100|0.99025369| PASSED sts_serial| 7| 100000| 100|0.52913922| PASSED sts_serial| 7| 100000| 100|0.20699735| PASSED sts_serial| 8| 100000| 100|0.51858724| PASSED sts_serial| 8| 100000| 100|0.93935828| PASSED sts_serial| 9| 100000| 100|0.89045694| PASSED sts_serial| 9| 100000| 100|0.97967948| PASSED sts_serial| 10| 100000| 100|0.82805945| PASSED sts_serial| 10| 100000| 100|0.94576847| PASSED sts_serial| 11| 100000| 100|0.87463478| PASSED sts_serial| 11| 100000| 100|0.41233150| PASSED sts_serial| 12| 100000| 100|0.82320320| PASSED sts_serial| 12| 100000| 100|0.64700388| PASSED sts_serial| 13| 100000| 100|0.91421216| PASSED sts_serial| 13| 100000| 100|0.71090170| PASSED sts_serial| 14| 100000| 100|0.30674023| PASSED sts_serial| 14| 100000| 100|0.67525020| PASSED sts_serial| 15| 100000| 100|0.63952330| PASSED sts_serial| 15| 100000| 100|0.55714580| PASSED sts_serial| 16| 100000| 100|0.73460968| PASSED sts_serial| 16| 100000| 100|0.69422309| PASSED rgb_bitdist| 1| 100000| 100|0.22341428| PASSED rgb_bitdist| 2| 100000| 100|0.08136192| PASSED rgb_bitdist| 3| 100000| 100|0.55014870| PASSED rgb_bitdist| 4| 100000| 100|0.14073467| PASSED rgb_bitdist| 5| 100000| 100|0.51289672| PASSED rgb_bitdist| 6| 100000| 100|0.57743763| PASSED rgb_bitdist| 7| 100000| 100|0.84468115| PASSED rgb_bitdist| 8| 100000| 100|0.91538369| PASSED rgb_bitdist| 9| 100000| 100|0.63104431| PASSED rgb_bitdist| 10| 100000| 100|0.79467241| PASSED rgb_bitdist| 11| 100000| 100|0.87835683| PASSED rgb_bitdist| 12| 100000| 100|0.31145148| PASSED rgb_minimum_distance| 2| 10000| 1000|0.24538060| PASSED rgb_minimum_distance| 3| 10000| 1000|0.06060245| PASSED rgb_minimum_distance| 4| 10000| 1000|0.52854808| PASSED rgb_minimum_distance| 5| 10000| 1000|0.24081642| PASSED rgb_permutations| 2| 100000| 100|0.79575115| PASSED rgb_permutations| 3| 100000| 100|0.97655238| PASSED rgb_permutations| 4| 100000| 100|0.72826877| PASSED rgb_permutations| 5| 100000| 100|0.47653591| PASSED rgb_lagged_sum| 0| 1000000| 100|0.88292658| PASSED rgb_lagged_sum| 1| 1000000| 100|0.83634521| PASSED rgb_lagged_sum| 2| 1000000| 100|0.05969674| PASSED rgb_lagged_sum| 3| 1000000| 100|0.49726026| PASSED rgb_lagged_sum| 4| 1000000| 100|0.99815217| WEAK rgb_lagged_sum| 5| 1000000| 100|0.60472621| PASSED rgb_lagged_sum| 6| 1000000| 100|0.57097784| PASSED rgb_lagged_sum| 7| 1000000| 100|0.80903695| PASSED rgb_lagged_sum| 8| 1000000| 100|0.14512311| PASSED rgb_lagged_sum| 9| 1000000| 100|0.91611538| PASSED rgb_lagged_sum| 10| 1000000| 100|0.92420750| PASSED rgb_lagged_sum| 11| 1000000| 100|0.60042568| PASSED rgb_lagged_sum| 12| 1000000| 100|0.13617953| PASSED rgb_lagged_sum| 13| 1000000| 100|0.24046263| PASSED rgb_lagged_sum| 14| 1000000| 100|0.92188587| PASSED rgb_lagged_sum| 15| 1000000| 100|0.28283582| PASSED rgb_lagged_sum| 16| 1000000| 100|0.93668554| PASSED rgb_lagged_sum| 17| 1000000| 100|0.84602342| PASSED rgb_lagged_sum| 18| 1000000| 100|0.47539708| PASSED rgb_lagged_sum| 19| 1000000| 100|0.91932322| PASSED rgb_lagged_sum| 20| 1000000| 100|0.22697424| PASSED rgb_lagged_sum| 21| 1000000| 100|0.86299916| PASSED rgb_lagged_sum| 22| 1000000| 100|0.44319686| PASSED rgb_lagged_sum| 23| 1000000| 100|0.49607458| PASSED rgb_lagged_sum| 24| 1000000| 100|0.64071058| PASSED rgb_lagged_sum| 25| 1000000| 100|0.67651856| PASSED rgb_lagged_sum| 26| 1000000| 100|0.05264378| PASSED rgb_lagged_sum| 27| 1000000| 100|0.52894581| PASSED rgb_lagged_sum| 28| 1000000| 100|0.23036343| PASSED rgb_lagged_sum| 29| 1000000| 100|0.08698878| PASSED rgb_lagged_sum| 30| 1000000| 100|0.91367390| PASSED rgb_lagged_sum| 31| 1000000| 100|0.50385001| PASSED rgb_lagged_sum| 32| 1000000| 100|0.39512022| PASSED rgb_kstest_test| 0| 10000| 1000|0.05304759| PASSED dab_bytedistrib| 0| 51200000| 1|0.07108892| PASSED dab_dct| 256| 50000| 1|0.06583399| PASSED Preparing to run test 207. ntuple = 0 dab_filltree| 32| 15000000| 1|0.77425875| PASSED dab_filltree| 32| 15000000| 1|0.10287529| PASSED Preparing to run test 208. ntuple = 0 dab_filltree2| 0| 5000000| 1|0.64344940| PASSED dab_filltree2| 1| 5000000| 1|0.13915721| PASSED Preparing to run test 209. ntuple = 0 dab_monobit2| 12| 65000000| 1|0.55077431| PASSED
The total number of ‘dieharder’ ‘weak’ assessments was higher for
April 21, 2018
Earlier this year we launched our new product—SwiftRNG Pro—a hardware random number generator that can produce high quality random bytes at 200 megabits per second. If you are looking for a faster generation speed then you have two options: you can either buy expensive hardware that generates random bytes at higher rates, or you can try out the SwiftRNG software API clustering feature.
In this post we will show how to use five SwiftRNG Pro devices to turn your computer into a high quality hardware random number generation machine that can produce random bytes at a speed of 1 Gbps. The SwiftRNG API provides device cluster scalability and fail-over capabilities. With this, it is possible to use multiple SwiftRNG devices to additively increase the random number generation speed. This API feature seamlessly integrates multiple devices and uses them concurrently as a single stream of random data (Fig. 1).
When working on your 1 Gbps HWRNG machine, your computer should meet the following requirements:
- A fast CPU with at least 4 cores. (We used a six core I7-8700 CPU at 3.2 GHz.)
- A mainboard that supports at least 5 USB HS ports (USB3 type is recommended for best results). We used ‘Gigabyte Ultra Durable Motherboard Z370 HD3P LGA 1151’
- Cent OS 7.
- 5 SwiftRNG Pro devices: each device should be plugged directly into a USB port available. Do not use USB hubs.
- SwiftRNG software utilities are built and available for CentOS from a command line.
To test your SwiftRNG Pro device cluster performance, download 60 GB of random bytes from the SwiftRNG cluster by entering the following in the command line:
swrng-cl -dd -fn STDOUT -cs 5 | dd bs=12000000 count=5000 iflag=fullblock of=/dev/null
The output may look like this (in the output below, 139 MB/s indicates that the download speed was around 1 Gbps):
5000+0 records in 5000+0 records out 60000000000 bytes (60 GB) copied, 431.234 s, 139 MB/s
To test the randomness quality of your SwiftRNG Pro device cluster, run the following in the command line:
swrng-cl -dd -fn STDOUT -cs 5 | dd bs=12000000 count=5000 iflag=fullblock | ent
The output may look like this:
5000+0 records in 5000+0 records out 60000000000 bytes (60 GB) copied, 1441.62 s, 41.6 MB/s Entropy = 8.000000 bits per byte. Optimum compression would reduce the size of this 60000000000 byte file by 0 percent. Chi square distribution for 60000000000 samples is 251.46, and randomly would exceed this value 55.09 percent of the times. Arithmetic mean value of data bytes is 127.4996 (127.5 = random). Monte Carlo value for Pi is 3.141587391 (error 0.00 percent). Serial correlation coefficient is 0.000002 (totally uncorrelated = 0.0).
April 20, 2018
SwiftRNG device integration using the API on Linux, macOS and Windows
SwiftRNG Software API is the simplest way to integrate your C/C++ application source code with a SwiftRNG device for achieving maximum download speed and performance. When using this model (Fig. 1), additional internal device features become accessible such as: running on-demand device diagnostics, accessing the raw random byte stream, downloading frequency tables for each noise source or setting power profiles. When using this integration solution, only one application (consumer) will be accessing SwiftRNG device at a time.
SwiftRNG device integration using SwiftRNG.dll on Windows
The supplied SwiftRNG.dll can be used to integrate SwiftRNG devices with applications that are developed to run on 32-bit or 64-bit Windows platforms (Fig. 2). The software kit contains source code examples that demonstrate how to use the DLL with C/C++ applications. You will also find source code examples on how to utilize the SwiftRNG.dll with languages such as C#, VB and Excel VB by visiting our documentation sections. The DLL will allow accessing the SwiftRNG random byte stream by multiple applications concurrently.
SwiftRNG device integration using Entropy Server on Windows
Entropy Server application is available for Windows and is used as an alternative way for distributing random bytes generated by a SwiftRNG device (Fig. 3). The SwiftRNG.dll can be used to access the server concurrently with maximum performance. Applications written in languages such as C/C++, C# and Java alternatively can access the Entropy Server directly, using a windows pipe without the use of the SwiftRNG dll.
SwiftRNG device integration using ‘swrandom’ kernel device module on Linux
The SwiftRNG Software Kit contains a Linux kernel module ‘swrandom’ that can be used to distribute random byte stream generated by a SwiftRNG device to any application that is capable to read from a file. The random byte stream generated can be concurrently accessible by consumer applications using device /dev/swrandom (Fig. 4). We recommend using this integration model on platforms such as Ubuntu, CentOS, RH in production environment.
SwiftRNG device integration for feeding the entropy pool on Linux
SwiftRNG Software kit provides a ‘swrng’ utility that can be used to feed the entropy linux pool ‘/dev/random’ with high quality random numbers generated by a SwiftRNG device (Fig. 5).
Using multiple SwiftRNG devices in a cluster with Linux and macOS
SwiftRNG API provides device cluster scalability and fail-over capabilities. With this, it is possible to use multiple SwiftRNG devices to additively increase the random number generation speed. This API feature seamlessly integrates multiple devices and uses them concurrently as a single stream of random data (Fig. 6). The feature is available when used with C/C++ applications and it is supported by SwiftRNG software utilities.
Using multiple SwiftRNG devices in a cluster utilizing Unix pipe on Linux and macOS
SwiftRNG software kit provides a utility for using a cluster of multiple SwiftRNG devices to additively increase the random number generation speed. The random bytes are distributed by a Unix pipe and can be concurrently accessed from any application with file access capabilities (Fig. 7).
April 1, 2018
In this blog post, we attempt to answer the following question:
Can ambient temperature and EMF affect the outcome of SwiftRNG output results?
If you pull up technical datasheets of any commercially available Zener diode, you will find, among other technical characteristics, a “Temperature Coefficients” chart. This chart shows the correlation between the nominal Zener voltage and the temperature. We are interested only in Zener diodes with nominal voltages above 5–6 volts, which predominantly use the avalanche breakdown effect. In these Zener diodes, the temperature coefficient is positive. This means that the breakdown voltage will increase once the temperature increases.
In the chart below, we can see that when using Zener diode with nominal voltage of 15 V, the temperature coefficient is approximately 10 mV per degree Celsius. That also means that when the temperature increases by 100 °C (212 °F), the breakdown voltage will increase by 1 V. It is very unlikely that the temperature of the Zener diode used in SwiftRNG will ever increase by 100 °C. If the breakdown voltage increases by 1 V then it won’t deteriorate or make the random noise source less random or decrease the quality of the random output.
To help testing the influence of electromagnetic fields (EMF) on SwiftRNG output quality, we used an AM-10 meter. The acoustimeter AM-10 is a broadband meter that measures the EMF in the range of 200 MHz to 8 GHz. This covers the frequencies used by most modern communication systems in our modern everyday environment.
We conducted three experiments to find out how the ambient temperature and EMF can influence the random outcome of Zener-based random noise sources in SwiftRNGs. The same SwiftRNG device was used for all experiments.
The first experiment was conducted when the ambient temperature was -8 °C (18 °F), the ambient average EMF was less than 1 µW/m², and the peak EMF was less than 0.02 V/m measured with the AM-10 Meter. The only way we could find a place with such low EMF level was by driving to the nearest park, away from streets, offices, and pedestrians that may use cell phones and Bluetooth devices. The chart below shows the uniform frequency distribution of 16,000 sampled random bytes (in the value range of 0 to 255) from a single Zener-based noise source. In addition, we collected 120 MB of raw data output from the SwiftRNG. No evidence of data quality degradation was found when testing this output with the ENT test for randomness.
The second experiment was conducted when the ambient temperature was 24 °C (75 °F), the ambient average EMF was less than 1 µW/m² and the peak EMF was less than 0.02 V/m measured with AM-10 Meter. The chart below shows the uniform frequency distribution of 16,000 sampled random bytes (in the value range of 0 to 255) from a single Zener-based noise source. In addition, we collected 120 MB of raw data output from the SwiftRNG and could not detect any evidence of data quality degradation when testing with the ENT test.
The third experiment was conducted for extreme conditions when the ambient temperature was 28 °C (82 °F), the ambient average EMF was less than 200 µW/m² and the peak EMF was less than 4 V/m measured with AM-10 Meter. Such EMF level can be found in the office in near proximity of WiFi routers or other radio communication devices. The chart below shows the uniform frequency distribution of 16,000 sampled random bytes (in the value range of 0 to 255) from a single Zener-based noise source. In addition, we collected 120MB of raw data output from the SwiftRNG and could not detect any evidence of data quality degradation when testing with the ENT test.
Based on our testing conducted with the ENT test for randomness, we did not find any evidence that ambient temperature and EMF can influence the outcome of SwiftRNG random output quality.
February 18, 2018
In the first installment of our SwiftRNG In Depth series, we will explore how each SwiftRNG device generates true random numbers from Zener diodes. The diagram below is a schematic representation of a SwiftRNG device in the top-half, and a host computer in the bottom-half. We will be going over the different parts of this diagram below.
Step 1: Noise production
Each SwiftRNG contains two reverse-biased Zener diodes, which are shown in the top-left of the diagram. These Zener doides generate noise from the avalanche breakdown effect. The Zener diode is a semiconductor component. In other devices, Zener diodes are often used in DC circuits as voltage regulators or to provide voltage references.
The frequency range of the electrical noise generated by a Zener diode depends on the component manufacturer, breakdown voltage and physical dimensions. Depending on the diode, avalanche breakdown is observed at above 6-8 volts, and the electrical noise generated in such components is strong enough to be measured, and has the characteristics of randomness. This makes Zener diodes a candidate for a good noise source in hardware random number generators.
Avalanche diodes such as Zener diodes generate large quantities of radio frequency noise and are widely used for RF measurements. After extensively testing noise sources based on Zener diodes, we have found no evidence of any quality deterioration over time.
The following is a spectrum analyzer waterfall that was created by sampling the noise generated from a Zener diode used in SwiftRNG. The chart shows the magnitude of the noise signal versus frequency within the frequency range of 10 MHz to 54 MHz. It shows a smooth distribution of the frequencies of the noise.
Step 2: Noise amplification
Each of the two Zener diodes is connected to an amplifier (labeled AMP in the diagram), which amplifies the electrical noise. At this point, the noise data is still in analog form.
The following plot was generated by an oscilloscope that measured the amplified random electrical analog signal generated by a Zener diode.
Step 3: Conversion to digital form
The result of noise amplification from each amplifier is then sent to an analog-to-digital converter (labeled as ADC in the diagram). The ADC converts the analog signal into a digital stream of random bytes. Each Zener diode, amplifier, and converter together form an independent noise source, and each SwiftRNG device contains two of these independent noise sources.
Step 4: Digitized value validation
Digitized random values from each noise source is then sent to a continuous self-diagnostics component (labeled as CSD in the diagram), which validates the random values. The component performes frequency analysis, and checks for deteriorations or malfunctions in the noise source. The result of this analysis is reported in the overall generator status code.
Step 5: Byte stream merge
The independent byte streams produced are then merged into one stream using logical XOR and shifting operations. This is shown in the component named ‘Merge’ in the diagram.
Step 6: USB transmission
The resulting bytes are transmitted to the host system using SwiftRNG software API through USB interface. A monitoring logic built into the software API of the SwiftRNG checks the quality of the final random bytes produced. This is done by continuously running Repetition Count tests and Adaptive Proportion tests, as specified by NIST Special Publication (SP) 800-90B.
Step 7: Post-processing
In the final step, the random bytes are fed to a conditional component by applying SHA256, SHA512 or XorShift64 post processing method. This data conditioning step is optional for SwiftRNG Pro.
The final bytes produced can be accessed with the supplied SwiftRNG software kit on Windows, Linux and macOS.
January 1, 2018
2017 has been a wild ride, hasn’t it? It sure has been a big year in the digital world. More websites adopted HTTPS in 2017 than any other year, and people are more aware than ever of the security and privacy challenges faced by citizens and businesses alike. At the same time, it was the year the open internet faced the biggest obstacle with the repeal of Net Neutrality, and broadband privacy faced a major setback.
Here at TectroLabs, we released the SwiftRNG LE just over a year, making our unique true random number generating technology available to many more people at a lower price point. We have also released an updated version of our SwiftRNG model in 2017, bringing improved reliability and additional API features.
Since then, we have been working around the clock on a new generator that expands our family of SwiftRNG generators. To mark the new year 2018, we are so excited to announce our new device today: the SwiftRNG Pro. It has all of the awesome features of our SwiftRNG, but at 200 megabits per second, it has double the random number generation speed of the SwiftRNG, making it the world’s fastest USB-based random number generator. And with new device diagnostics capabilities, it is easier than ever to deal with possible issues.
September 10, 2017
We are announcing today a new revision of our SwiftRNG device. This revision, version 1.2, meets NIST SP 800-90B (second draft) requirements and includes the following improvements:
- Updated hardware and firmware components for bringing functional reliability and quality of resulting random data stream to a new level.
- Updated the device API and Software Kit with new commands for retrieving frequency tables of noise sources and for retrieving raw original byte stream data for each noise source. This transparency of raw entropy stream enables independent security testing and validation.
Available today, version 1.2 of SwiftRNG can be purchased here.
Edited September 10, 2017
June 4, 2017
We are happy to announce that SwiftRNG and SwiftRNG LE are now both available for purchase through Amazon.com! The SwiftRNG can be found here, and SwiftRNG LE is available here. Purchases through Amazon are eligible for fast Prime shipping.
April 8, 2017
We are announcing today an important update of the SwiftRNG Software Kit. Beginning with version 3.3, the SwiftRNG API contains device cluster scalability and fail-over capabilities. With this, it is possible to use multiple SwiftRNG devices to additively increase the random number generation speed. By doing so, the reliability of the cluster is increased. This new API feature seamlessly integrates multiple devices and uses them concurrently as a single stream of random data. The API will monitor the health of the cluster and will resize the cluster on-the-fly, allowing device swapping in real-time. This makes it possible to remove and add SwiftRNG devices in the middle of random number generation.
April 7, 2017
This week we released version 3.3 of the SwiftRNG software kit. This update adds device cluster scalability and fail-over capabilities to the SwiftRNG software API. With this, it is possible to use two or more SwiftRNG devices to additively increase the random number generation speed. By doing so, the reliability of the cluster is increased. This new API feature seamlessly integrates multiple devices and uses them concurrently as a single stream of random data. The API will monitor the health of the cluster and will resize the cluster on-the-fly, allowing device swapping in real-time. This makes it possible to remove and add SwiftRNG devices in the middle of random number generation.
December 30, 2016
We are announcing today a new revision of our SwiftRNG device. This revision, version 1.1, contains the following improvements:
- Improved power consumption – SwiftRNG 1.1 uses up to 200 mA, down from 250 mA.
- Reduced operating temperature.
- Maximum ambient temperature is now 80 degrees Fahrenheit (26 degrees Celsius).
- Low power mode when idling — SwiftRNG 1.1 consumes less power when not in active use.
- Device cluster scalability and fail-over capabilities through the SwiftRNG software API on Linux and macOS.
Available today, version 1.1 of SwiftRNG can be purchased here.
If you are experiencing any problems with your SwiftRNG 1.0 and are under warranty, please contact us. We are able to replace your original device with a SwiftRNG revision 1.1 at no extra cost in most cases.
Edited June 4, 2017
December 29, 2016
We are happy to announce a lite edition of the of our SwiftRNG device: SwiftRNG LE. At an affordable price of $199 USD, SwiftRNG LE generates random numbers at 20 megabites per second, and consumes no more than 110 mA.
Like the standard edition, SwiftRNG LE has a length of just 7.9 cm and a weight of 21 grams. It can be used with just about any system, ranging from large-scale servers to the Raspberry Pi 2. And with a module provided by TectroLabs, setting it up is easy. Random numbers generated by SwiftRNG LE pass all statistical tests for randomness, including Diehard, DIeharder, NIST, and ENT.
SwiftRNG LE comes with software that makes it compatible with 64 and 32 bit Linux distributions, Windows, and macOS. It plugs into any computer with a USB port, and is appropriate for a wide range of uses, including research, simulations, and generating secure session and encryption keys.
October 29, 2016
TectroLabs, LLC, announced today the issuance to it by the United States Patent and Trademark Office of a patent that covers hardware random number generation technology.
US Patent 9,477,443 is for a method and apparatus of entropy source with multiple hardware random noise sources and continuous self-diagnostic logic.
The patent covers the technology in SwiftRNG, TL200, and TL100 hardware devices by TectroLabs that are used for generating true random numbers. SwiftRNG is a USB stick-sized device that generates random numbers at a rate of 100 megabits per second, faster than any other device of the same size.
Demand for hardware random number generators is growing rapidly as more companies seek to secure their applications and online presence. True hardware random number generators such as the SwiftRNG offer better security than pseudorandom software-based random number generators because they provide streams of random numbers that are unpredictable.
February 28, 2016
With the new SwiftRNG Software Kit 2.1, we bring Windows support to your SwiftRNG! The new kit includes an updated
swrng, that is fully compatible with Windows 8.1 and 10. With this new utility, Windows automatically installs the appropriate Windows certified driver without manual intervention when you plug in your SwiftRNG.
The kit was also recently updated with support for OS X. Download it today here!
February 14, 2016
We are happy to announce the availability of the SwiftRNG Software Kit 2.0, which includes a new software utility named
swrng, which makes it possible to use SwiftRNG with OS X.
Download it today here!
January 13, 2016
Today, we are unveiling SwiftRNG, the world’s fastest small-form random number generator. SwiftRNG is a USB stick sized device that generates random numbers at a rate of 100 megabits per second, faster than any other device of the same size.
With a length of just 7.9 cm and at 21 grams, SwiftRNG can be used with just about any system, ranging from large-scale servers to the Raspberry Pi 2. And with a module provided by TectroLabs, setting it up is easy. Random numbers generated by SwiftRNG pass all statistical tests for randomness, including Diehard, DIeharder, NIST, and ENT.
SwiftRNG comes with software that makes it compatible with 64 and 32 bit Linux distributions, including Ubuntu and CentOS. Support for Windows and OS X will be added in April 2016. It plugs into any computer with a USB port, and is appropriate for a wide range of uses, including research, simulations, and generating secure session and encryption keys. With software such as Virtio RNG, a single SwiftRNG is capable of generating random numbers to multiple guest instances in a cloud environment. With a speed of 100 megabits per second, it can be used to distribute one megabit per second to one hundred instances simultaneously.
January 3, 2016
Today, we’ve launched a new version of the TectroLabs site, built from the ground up with Jekyll. We hope the refresh will result in quicker page loads and an improved overall user experience. Along with the refresh, we’ve put up the latest version of our documentation online here, so it’s easily accessible from wherever you are. Please let us know what you think!
November 27, 2015
The Software & Documentation Kits for the TL200 and TL100 have been updated with new FTDI USB drivers for Linux and an FTDI setup executable for installing the certified drivers on Windows 10. They also contain various updates to the documentation.
The new kits may be downloaded from the downloads page.
September 26, 2015
If you are considering purchasing a TL200 we’d like to announce that all TL200 random number generators now come with a two-year warranty. This applies to new TL200 devices, and existing TL200 warranties are now extended from one year to two years as well. Warranty details may be found here.
May 24, 2015
TL100 and TL200 devices can now be used as entropy sources by using an RNG daemon. The daemon is available with the ‘rng-tools’ package on Linux, downloadable here.
Once the ‘tlrandom’ kernel module is successfully loaded, the entropy generated by the device can be used to feed the RNG daemon using the following command:
sudo rngd -r /dev/tlrandom
May 18, 2015
We are pleased to announce ‘tlrandom’, a new kernel module for Linux platforms. It can be used for interacting with the TL100 or TL200 devices. This module can be loaded by the kernel, upon which random bytes from the TL200 will be available for download from
You will be able to use ‘dd’ to download the random bytes using a command like this:
dd if=/dev/tlrandom of=download.bin bs=100 count=120000
The module has the ability to automatically detect when a TL100 or TL200 device is plugged in or unplugged from any USB port. Any application running in the user space should be able to open
/dev/tlrandom and read random bytes generated by TL devices concurrently.
The new TL200 and TL100 Software & Documentation kits with ‘tlrandom’ are available to download here.
May 16, 2015
The TL200 and TL100 Software & Documentation kits have been updated with numerous fixes and additions. For Linux, an issue that could result in driver conflicts between a TL100 or TL200 device and kernel modules ‘ftdi_sio’ and ‘usbserial’ has been resolved.
For OS X, an issue that results in driver conflicts between the TL100 or TL200 device and kernel extension ‘AppleUSBFTDI’ has been resolved. This means that it is no longer necessary to disable OS X’s new D2XX driver to use the TL100 or TL200.
The update is available to download here.
March 19, 2015
We’ve updated our website and added support forums with sections for discussing and asking questions about the TL200 and other TectroLabs hardware and software. The TectroLabs staff will be monitoring the forums and quickly answering questions. As usual, you can still contact us directly with any questions you may have. Check out the forums now!
January 13, 2015
We have tested 280 GB of random bytes produced by a TL200 with ent, a command line utility that measures entropy. The statistical report is as follows:
Entropy = 8.000000 bits per byte. Optimum compression would reduce the size of this 289304498176 byte file by 0 percent. Chi square distribution for 289304498176 samples is 268.69, and randomly would exceed this value 50.00 percent of the times. Arithmetic mean value of data bytes is 127.5002 (127.5 = random). Monte Carlo value for Pi is 3.141577725 (error 0.00 percent). Serial correlation coefficient is 0.000001 (totally uncorrelated = 0.0).
More statistical reports of the TL200, including NIST, Diehard, and Dieharder, can be downloaded from our page about the TL200.
January 13, 2015
We are pleased to announce Entropy Feeder (ef), a Linux command line utility that makes it even easier to feed random bytes produced by a TL200 to the Linux entropy pool. This utility is now a part of the TL200 Software & Documentation Kit, and can be downloaded here by TL200 users. Once downloaded, the command can be run by simply typing the following in a terminal:
When running the ef utility, the availability of random stream can be tested with this command:
sudo dd if=/dev/random of=/dev/null bs=1 count=1000000
The output of this command may look like this:
1000000+0 records in 1000000+0 records out 1000000 bytes (1.0 MB) copied, 8.41315 s, 119 kB/s
Download Entropy Feeder right now here.
November 27, 2014
We’ve added a new feature to the TL200 that allows you to generate a random sequence of non-repeatable numbers. This random sequence is based on the true random numbers generated by the TL200, and is simple to generate using the GetRND utility. For example, we could use the following command to get a sequence of numbers 1 through 35 in a random order:
sudo ./getrnd -grs 1 35
This could result in the following output:
-- Beginning of random sequence -- 30 26 32 34 14 24 35 9 3 1 25 7 33 21 10 5 20 19 15 17 11 13 23 16 8 18 22 27 4 12 6 28 31 29 2 -- Ending of random sequence --
You can also limit the amount of numbers generated to less than the range. For example, you can choose to generate only the first five numbers of a random sequence of numbers from 1 through 10,000,000:
sudo ./getrnd -grs 1 10000000 5
This could result in the following output:
-- Beginning of random sequence -- 3830571 7697152 31227 8399071 3968532 -- Ending of random sequence --
September 28, 2014
At TectroLabs, we strive to empower organizations and individuals to better meet their security needs with efficient and effective hardware and software solutions. Today, we are very pleased to announce the TL200, a big leap forward in our goal. The TL200 is a true hardware number generator that plugs directly into a USB port and generates numbers at a speed of 2.0 megabits per second. It is 40% faster and 60% lighter than the TL100 and contains new features such as selectable power profiles for different energy needs.
The TL200 has the same foundation as the TL100 and is fully compatible with the TL100, ensuring that applications built around the TL100 will be compatible with the TL200.
The TL200 can be purchased at our online shop for $349. It can be shipped to the United States, United Kingdom, Germany, Spain, Italy and Sweden, and we plan on expanding to more destinations in the future.
July 4, 2014
Statistical tests are the best way to measure the quality of generated random numbers, but they’re not the only way. In fact, graphical outputs of random numbers allow people to visually inspect random numbers without relying on statistical outputs. Here, we compare the visual representations of numbers generated using a faulty random number generator, and true random numbers generated by a TL100.
In the following two images, try to see if you can spot any patterns in each image. Each pixel in the images represents one bit of random data, filled from left to right, line by line, from top to bottom.
Picture 1: This first image shows a bitmap graphical representation of numbers generated by a low-quality number generator. Notice that it is easy to observe long continuous horizontal black and white lines, which means that the generated bits are highly biased. Click on the image to view it in full size.
Picture 2: This second image shows a bitmap graphical representation of true random numbers generated by a TL100. In this image, visible patterns are difficult to spot, and it can be argued that there aren’t any. Click on the image to view it in full size.
As you can see, there is a clear difference between the two. Whereas the first image from the faulty hardware number generator has noticeable long lines from left to right, the second image from TL100 numbers shows black and white pixels mixed evenly, without any clear pattern.
June 23, 2014
A TL100 or TL200 can be used to continuously feed the entropy pool of a computer running on a Linux operating system using the GetRND software utility. To do so, first plug in the device into your Linux computer and run the GetRND software utility. (Details on how to do this can be found in the Read Me file of the Software and Documentation Kit). Once you have successfully done so, simply run the following command from the command line:
sudo ./getrnd -dd -fep
The device will now continuously feed the entropy pool with true random bytes.
June 22, 2014
A TL100 or TL200 can be used to download a specified or unlimited amount of random bytes and save it to a file on your disk using the GetRND software utility.
Note: The commands in this tutorial work for Linux and OS X operating systems. For Windows, replace ‘sudo ./getrnd’ with ‘getrnd.exe’ in all of the commands here.
Let us attempt to download 12 MB of to the file rnd.bin. To do so, first plug in the device into your computer and run the GetRND software utility. (Details on how to do this can be found in the Read Me file of the Software and Documentation Kit). Once you have successfully done so, simply run the following command from the command line:
sudo ./getrnd -dd -fn rnd.bin -nb 12000000
This command will create a file named rnd.bin if it doesn’t already exist, and download 12 MB of true random numbers to it. The command line may ask you to input your password. After that, wait a few seconds, and you should eventually see a message like this:
Processing request ... Completed in 51 seconds, speed: 229 KBytes/sec, blocks re-sent: 0
You may also choose to download random numbers continuously to a file. To download an unlimited amount of true random numbers to the file rnd.bin, run the following command from the command line:
sudo ./getrnd -dd -fn rnd.bin
This will continuously download true random numbers to rnd.bin, until you type Ctrl+C to abort.
March 20, 2014
In general, random number generation involves the use of a program or device referred to as a random number generator to generate a set of numbers that lack any discernible pattern and therefore are referred to as “random.” Just how random, and therefore how unpredictable, these random numbers are however, varies greatly from generator to generator.
Uses of random numbers
Humans have relied on randomness for thousands of years. Perhaps the most well known example in history is of Athenian democracy. In the fifth century BC, the legislative bodies of the government of Athens in Ancient Greece were made up of average citizens. Because of the strong support for direct democracy, Athenian citizens were selected at random to make up these bodies. Random selection was also used to select jurors for trials.
In modern times, juries are still selected at random, but the use of random number generation has also spread to countless other fields. In science, random numbers are used to create simulated data for economic models, climate change models, hurricane models, and even epidemiologist models. From simple models predicting the result of a number of coin tosses, to complex models simulating neutron transportation in nuclear fission, random numbers often play an important role.
Of course, random number generation is monumentally important in data security and encryption. Random number generators are used to create encryption keys, salts, and keyfiles for keeping data safely encrypted. If encryption keys are generated using a nonrandom approach, they can be predictable and easily determined, allowing just about anyone with the right expertise to decrypt and access your data.
Random number generation is also needed for lottery management systems and other random drawings. In some cases, unbiased random number generation is required by law, such as in random drug testing.
Reliability of random number generators
In 1969, the United States Selective Services System held a lottery to determine the order at which men would be called to military service in the Vietnam War based on birthdays. Each date from January 1 to December 31 was placed in a capsule, and the capsules were then mixed in a box, placed in a jar, and selected at random in a televised event. The order the dates were selected would be the order of drafting. However, it became apparent after the lottery that many more of the dates from November and December had lower rank numbers than other dates, and indeed, statistical analysis later showed that the results could not have been the result of an actually random process.
This example is relevant to answering the following questions: is a random number generator always as reliable as it seems, and if not, which ones can we trust to produce genuinely random numbers?
Pseudo versus true random number generation
Unfortunately, the previous example shows that random number generators are not always as accurate as they seem. In hindsight, there were important problems with the selection method in the 1969 draft lottery—notably, the capsules may not have been properly mixed in the box before being placed in the jar, leading to an unknown bias in selecting November and December dates.
Similarly, many random number generators used today are not actually random. These generators rely solely on computer algorithms to generate sequences of numbers that appear random and are called pseudorandom number generators (PRNGs). They produce sets of numbers from mathematical formulas that look random, but are actually periodic. If the starting point of a sequence is known, the exact same set of numbers can be generated over and over again. PRNGs are highly efficient, meaning they are able to produce large quantities of numbers quickly, but are by nature periodic and deterministic. Others can recreate the same set of numbers with the right starting information. This makes PRNGs unsuitable generators for many uses, including all types of data security, random sampling, and lotteries.
Other random number generators, known as true random number generators (TRNGs) use physical phenomena to generate sets of numbers. These generators do not rely solely on mathematical formulas. Instead, their source for random numbers can be all sorts of things, such as variations in a user’s mouse movement, atmospheric noise, or even radioactive decay.