Hmm I can’t remember what error it was that made me commit that comment. I do recall though I didn’t explore much with it so it seems very well I am wrong on that account.
@Aloka Can you tell us what CPU architectures the RDTSC command is available on? And what about ARM64?
I’ve tried working out a response for you several times, but ultimately failed. Please contact the admin if this persists, thank you!
@NullSpook Are you trying specifically to get it run on Android or a PC-based Linux installation?
If Android, is the API issue you mentioned at the Java/Kotlin layer? Or at the NDK/native-C/C++ level? A custom ROM with modifications to AOSP might help, but would then severely limit you to what phones it could be run on - basically just yours and others who want to root their phone with NullSpookOS 
In another life I did a bit of work customizing Davlik and the Android kernel. It was fun but the development iteration times were sloooow waiting for the whole of AOSP to build.
Previously, I was trying to implement a timing jitter-based RNG on Linux in general. The goal is for the library to be usable on PC, Android, iOS, etc. But as I mentioned before, on Linux, all timing APIs use RDTSC underneath (or PMCCNTR/CNTVCT_EL0 on ARM). Yes, this includes timing APIs in Java/Kotlin layer on Android.
On Android, I’ve solved this problem by using sensor’s clock, which I shared in the beginning of this thread. (I believe this trick can be used in iOS as well)
On PC, however, I still haven’t found a solution without requiring root privileges.
What are you using it for? Is this possible on iOS? Keep me in the loop of your development, there are several applications we are working on that would benefit from the development of this, and I’d love to help contribute if I can.
It can be used as a backup for a QRNG for MMI projects if the user does not have access to a QRNG or a local RNG is needed.
My MMI and “quantum AI” projects usually use my remote QRNG service that I made public. I try to keep my QRNG service running 24/7, but I can’t guarantee 100% uptime. So I want to provide a hardware RNG alternative that runs locally as a fallback.
I don’t currently have an iOS device, so I haven’t been able to test this method on iOS. If you’re familiar with iOS development and want to give it a try, you can implement the same algorithm there. The idea is simple. Continuously measure the time gap between consecutive sensor readings. These time gaps contain small variations or jitters, which can be turned into random bits.
Turns out on more recent versions of Windows, QueryPerformanceCounter is almost always backed by TSC.
| Windows Version(s) | QueryPerformanceCounter Hardware |
|---|---|
| Windows 2000, XP | TSC |
| Windows Vista, Server 2008 | HPET or ACPI PM timer |
| Windows 7, Server 2008 R2 | TSC. Falls back to HPET or ACPI PM timer if TSC is unreliable |
| Windows 8, 8.1, Server 2012, Server 2012 R2 | TSC |
We can force QueryPerformanceCounter to use HPET by calling bcdedit /set useplatformclock true so that we can measure its jitter using RDTSC. But it needs administrator privileges and a reboot.
I think I found a way for browsers. In JavaScript, we can get a callback every time the screen refreshes (VSync event). It is backed by the monitor’s hardware clock. We can measure its jitter using performance.now() which is usually backed by TSC on modern systems. I’ll run some tests and will get back with the results
Started a new thread here
Min-entropy estimated with usnistgov/SP800-90B_EntropyAssessment using 1000000 samples truncated to 8-bit LSBs.
The result indicates that the 8 least significant bits of the raw unprocessed samples contain very high entropy.
Here’s Linux /dev/urandom XOR’ed with ComScire PQ4000KU for a benchmark
Each sample’s 8 least significant bits are processed using a 64-bit LFSR. A total of 25 MB of data was tested using NIST STS and QNGmeter. Here’s the result
The file passed NIST SP 800-22 tests and QNGmeter, indicating that it exhibits high-quality randomness
Hmm, you might be onto something here. Check this out…
The Web Audio API exposes access to the audio subsystem’s hardware clock. This clock is exposed on the AudioContext object through its .currentTime property, …
