I find this idea quite interesting.
Actually, just saying that we have TRNG is not enough today.
We also need to see if that entropy is finally reaching to key generation correctly.
Even a small mistake in firmware can ruin our entire security.
Well, you said that 32 audio frame are being selected based on amplitude. Is this frame selection deterministic?
If the rule for selecting frames from same audio is predictable then how do you actually verify how much min-entropy is available?
I might have given the wrong meaning when i said based on amplitude.
When launched the program will monitor the audio channel before it begins sampling frames for use.
Each frame gets passed off to a function which checks for minimum amplitude before it is even considered.
If the program operated by loading an audio file in, I could understand deterministic choice being an issue - however listening to an active audio channel, the chances of obtaining an identical recording would be slim to none.
However 'just in case', i added another routine to pluck 16 bytes from '/dev/urandom' and see if the first 4 bytes were lower than 0x1000 (you could call this a random PoW of sorts). If this condition is met and the amplitude rule is met - then the frame is used.
You may know that SHA-256 in Cryptography does not create entropy. Rather it compresses & conditions the existing entropy. If the entropy in input is low, it will not automatically increase even if hashed.
Understood.. i'm simply using it as a means to compress a frame (2048 bytes) to 32 bytes (the frame result), then 32 frames (32*32=1024) down to a single 32 byte result.
