This seems to be created by someone who is not a cryptographer, I would not trust this scheme to produce "true" random numbers. Additionally, the entropy source still exists in the form of a photograph, and the process can be repeated by an attacker with access to it. Generally with a TRNG, once entropy is extracted, its gone, there is not a copy of it somewhere, it is read into the DRBG and processed irreversibly.
This is best described as an entropy extractor and DRBG, and a giant block of solid green will have essentially no entropy, but this will still output a series of values that pass the NIST randomness tests. The fact that this passes randomness tests is meaningless, so did Dual-EC.
I would be substantially more comfortable if it accepted camera input only, not pictures, and ran something like this:
PRNG = SHA384( SHA512(Camera Input) || (Camera Metadata, time, gps, etc) || (32B System RNG output) )
And took a photo, feeding the PRNG output into a large entropy pool of a DRBG, then spitting out a value for use after enough photos were taken. For a 384B pool, 8 pictures to fill the pool, then each additional picture gives up to 256-bits of output. Of course this is more valuable on a mobile device where a camera can take pictures arbitrarily, a desktop system does not have the same flexibility.
This turns a camera into a whitener for the system RNG, which can be supplied with much better entropy from cryptographic accelerators built into the SOC, but may still be considered suspect. The whitening eliminates the ability for old outputs to predict new outputs, or the other way around, while still making use of the system entropy provided.
Updates:
There were some very interesting comments added to this post, and I figured I should respond to some of the points raised, as they have merit:
From reading the site it intentionally described it in plain English so the content is understandable for a wider audience. Perhaps this gives the impression that it is not created by a cryptographer.
That is not the reason for my initial comment, I prefer an algorithm/scheme design to be readable in both plain English and a pseudocode for comprehension, and a good job was done in the plain text respect. My comment was based on the design itself.
Moving a photo from a standalone camera to an air-gapped computer then erasing it afterwards does not give any attacker a chance to repeat the process.
Erasing data is not always successful, that is common knowledge. Also an attacker can go directly to the airgapped system to get the data if it is still there. Or they can un-gap it with an implant, even in a faraday cage (acoustic and optical transmitters). A RNG that relies on a faraday cage and airgapped systems for security has a huge usability problem.
It's actually just a randomness extractor using a hash function, essentially a TrueRNG ... The entropy in the photograph is used only once.
No, nothing about this makes it true random. It is deterministic by design. The output is determined from the pixels in the photograph.
Reading the site, the critical steps are: carefully taking a quality photo in the first place, and the extra safeguard of removing sequentially repeating pixel colours which is mentioned in step 3 of the mentioned algorithm. Any low entropy sections in the photograph are removed before randomness extraction begins
You are right, I missed the part about non B/W colors. However even if the R value only varies by 1 bit across alternating pixels, that method will not remove the pixels, and the entropy will still be poor.
Your comparison of this design to a deliberately backdoored algorithm by the NSA is nonsensical. Passing randomness tests is not meaningless in itself. It's essentially a smoke test to rule out completely bad input.
Comparing one algorithm to another that passes the same test is not nonsensical. Many pass the tests while being completely broken. Randomness tests are usually used to test the algorithm and make sure the code is working, not the input. Input should be tested before passing to the RNG, and between each functional block. A failure at input should prevent the output from even being generated.
Your counter proposal lacks a coherent definition to be implementable, appears to be quite slow and throws away an enormous amount of entropy to the point that the scheme is unusable. For a start, what is “Camera Input”? ... What is its data format? How is it loaded into the program? ... You don't mention how the user should take pictures.
I was not designing a counter proposal, it was just a basic example of something that would generate 384-bits of output from a single camera input. Something that I would trust more than that in JC. I did not describe any component in detail, or the motivation behind them, just a high level overview. What followed was also a fairly basic example of what to do with it. Slow? I doubt it. Unusable? Not at all. "Camera input" is the information the camera captures, sent directly to application memory without transfer to disk.
Also it's intriguing that you immediately switched to using NSA designed SHA2 hash functions in your recommendation instead of openly designed alternatives by trustworthy cryptographers ... I wonder what the point of using both SHA384 and SHA512 is other than making it slower. Surely you could do only one hash of all the inputs concatenated together.
The SHA2 family is one of the most studied of all hash functions. No it is not designed openly, but it performs well, has a simple implementation, and has withstood decades of analytical attacks on both the compression function and the full hash, notwithstanding the problems that apply to all MD type hash functions, which are not relevant to this type of use. I also like Blake. Keccak is slow.
The point of using 2 different hash functions with 2 different sizes is simple. The first is to compress the entropy of the photo down to a 512-bit value. The second is to diffuse and compress that value with additional data and additional entropy, while using different initial values, and truncating the function to hide the full state by a cryptographically strong amount (128-bits). You could also use HMAC with a key from system entropy, and truncate, instead of using SHA384. Once again it was just an example, but there is logic behind the construction.
And finally
This answer seems to be created by someone who is not a civilian, I would not trust this schemer to produce “true” random numbers.
The implication that I am an intelligence agency plant makes me feel all warm and fuzzy inside. If I say I am not, will you believe me? Am I also correct in assuming that you are one of the program developers/contributors or related in some way? I don't expect an answer to that. I will say that additional edits would not be appropriate for a back-forth discussion on merits of the scheme in question.
