3

I'm looking for a method to generate true random bits/numbers on smartphones.
Create a custom TRNG seems to be tricky and a lot of people suggest to trust in already existing ones, widely tested and approved. But I've found Jericho Comms, that uses a custom TRNG from the pictures as input.
How secure, strong and reliable is this? Could it be a valid method to generate truly random numbers/bits?

I know that smartphone cameras are not perfect for this purpose because of the JPEG compression and low quality, but omitting this, how correct is the algorithm proposed?

I paste the documentation:

This process describes the full algorithm:

  • Load the user's photograph into memory and store it in a sequential array of RGB values.
  • Get the red, green and blue (RGB) integer values for each pixel. This will return a number between 0 and 255 for each colour.
  • Remove sequentially repeating black (0, 0, 0) pixels, white (255, 255, 255) pixels and pixel colours that are exactly the same. This removes sections of the photograph with underexposed pixels, overexposed pixels and those that have have little entropy. Generally it is very unusual to have adjacent pixels that are exactly the same colour unless there is a hardware failure, or the section of the photo is under/overexposed. Usually in a good quality photograph there are at least very slight colour variations in adjact pixels. This step removes these low entropy areas.
  • Estimate 1 bit of input entropy per set of RGB values (1 bit per 24 bit pixel). This is a very conservative estimate. Users can increase this in the TRNG settings to 3 bits per pixel which would account for the entropy in the least significant bit of each colour.
  • Gather 512 RGB values to get an estimated entropy input of 512 bits.
  • Convert the 512 RGB values to their hexadecimal representation and input them into a cryptographic hash with a 512 bit output. The user can choose which hash to use and the program allows either Skein or Keccak [c=2d]. Both are very strong finalist algorithms from the NIST hash function competition. Store this hash output of 512 bits as the temporary seed into the next hash.
  • Start a loop:
    - Check there is enough new input entropy for the new hash, or break out of the loop.
    - Get the temporary seed from earlier.
    - Get a new set of 512 RGB values (512 bits) as the new input entropy.
    - Concatenate the seed and input entropy together and hash them using: Hash( seed || input entropy ).
    - Append the first 256 bits of the hash output to the output random data.
    - Update the temporary seed to be the last 256 bits of the hash output.
    - Return to start of the loop.


    It is important to note that the program does not use this collected entropy to seed a psuedo-random number generator to give an unlimited amount of random data. The program aims to be a true random number generator so only quality randomness is wanted and each uniformly random bit must be used solely to encrypt one bit of the plaintext. It's assumed that most psuedo-random number generators or even CSPRNGs that stretch out the entropy could produce a subtle bias in the output and allow the NSA or other governments to decrypt part or all of a message. With this program the aim is to avoid stretching the available entropy over more bits.

    • Do you think that you'll do better than your platform's secure random generator? That is what most people use, I believe. – Neil Smithline Oct 1 '15 at 18:14
    • The problem is that I need a TRNG because I'm trying to create a One Time Pad implementation on my thesis. By definition if I use a PRNG I can't create a OTP, but a stream chiper. So I need a way to create true random numbers :/ – Riccardo Leschiutta Oct 6 '15 at 11:44
    • 1
      @RiccardoLeschiutta Even given uniform random input (a camera output is not that), this technique does not generate randomness with the information theoretic security required to apply a one-time pad with perfect confidentiality. This is due to its use of a cryptographic hash function which is not a true random oracle. – forest May 31 at 0:32
    4

    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 tedxt 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.

    • Comments are not for extended discussion; this conversation has been moved to chat. – Rory Alsop Jan 23 '16 at 12:55
    • 8
      NDF1 - As my message states, on Stack Exchange, comments are not for extended discussion. If you think an answer is atrocious, you can down vote. Richie responded to your comments with an update to his answer. It is absolutely within a moderator's authority to move or delete comments. – Rory Alsop Feb 22 '16 at 10:13
    • 5
      @NDF1 also your tone is entirely inappropriate for any civilized discourse, especially on this site. If you are well and truly bothered by this policy, you are welcome to request a full refund of your Stack Exchange subscription. – AviD Feb 22 '16 at 10:35

    Your Answer

    By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

    Not the answer you're looking for? Browse other questions tagged or ask your own question.