As an appendix for my bachelor thesis, I proposed a solution for a TRNG that uses JPEG images as entropy source.
It's open source and available on GitHub.
My question is: can this be really considered as a TRNG?
Obviously I tried to create a TRNG (and not a PRNG or a CSPRNG), but you know... the devil is in the detail.
Here some info, so you can help me enstablish if it can be considered as a TRNG or just a bottle of snake oil :)
How it works
- It uses two different input images (with the same resolution). These images are considered independent because captured in two different moments.
- It uses the Mixing technique, so the output will be unpredictable if at least one of two images is unpredictable.
- Only some of the total amount of pixels are considered. The CSPRNG SecureRandom sets for each considered pixel how many consecutive pixels have to be discarded. In this manner the correlation between consecutive pixels is avoided. This also guarantees that if the generator is run twice two different outputs will be generated.
- Only the BLUE channel is considered. So the correlation between different channels is avoided.
- The noise that can be found inside an image is located in the least significant bits (LSB). For this reason only the LSB of each input byte is used. You can choose to consider the second least significant bit too.
Bruce Schneier guidelines
In Applied Cryptography, Bruce Schneier lists some guidelines to check if a generator could be considered as (CS)PRNG or TRNG:
- For our purposes, a sequence generator is pseudo-random if it has this property:
It looks random. This means that it passes all the statistical tests of randomness that we can find.
- For a sequence to be cryptographically secure pseudo-random, it must also have this property:
It is unpredictable. It must be computationally infeasible to predict what the next random bit will be, given complete knowledge of the algorithm or hardware generating the sequence and all of the previous bits in the stream.
- Philosophy aside, from our point of view a sequence generator is real random if it has this
additional third property:
It cannot be reliably reproduced. If you run the sequence generator twice with the exact same input (at least as exact as humanly possible), you will get two completely unrelated random sequences.
And the solution I proposed:
- I executed some tests, and seem promising. Maybe other tests are required (?)
- It doesn't use hash functions. Each output bit is dependent on a specific pixel only. So, if an attacker knows the previously created bits, he cannot foresee the future ones.
- It uses a CSPRNG just to choose the pixels to consider. So, executing the generator twice, each time two different outputs will be generated.
SecureRandom(a seeded CSPRNG) as input for a TRNG...there's something fundamentally wrong just there. $\endgroup$