0

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 pseudo-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.
    • ROMANIA_engineer
    • 54,432
    • 29
    • 203
    • 199
    Riccardo Leschiutta
    • 457
    • 4
    • 8
    • He's not clear precisely how he converts the RGB values to input bits to his hash function. As described, he seems to imply that all bits of the chosen RGB values are used; it seems to be that using only the low-order bits would be better, but I'd defer to someone with higher math skills than me. For what purpose do you think you need an RNG like this? – Lee Daniel Crocker Oct 05 '15 at 18:07
    • Thank you for the answer! So using the low-order bits will be a better choice rather than use all RGB bit values? I think he opted for this solution to obtain a large quantity of output bits. Maybe this choice will make weak the entire process? I'm going to implement a OneTime Pad, and true randomness is required. – Riccardo Leschiutta Oct 06 '15 at 07:03
    • I've another question :P I've read about other possibile solutions. In particular I've found [LavaRand](https://en.wikipedia.org/wiki/Lavarand) that gets entropy random bits from a picture and uses it as a seed for a CSPRNG. Well, it is considered a TRNG. But why? Why it's not a CSPRNG? What differs between it and a OS CSPRNG (like [SecureRandom](http://resources.infosecinstitute.com/random-number-generation-java/)) – Riccardo Leschiutta Oct 06 '15 at 07:11
    • If speed isn't an issue I'd recommend random.org. – Lee Daniel Crocker Oct 06 '15 at 14:05
    • Speed is not an issue but security has the priority. If I trust an external website for the keys generation (using or not a PRNG with the given random bits) and an attacker is listening the communication this can be a security issue, I think. And also, who guarantees me that site is not controlled by the NSA? :P – Riccardo Leschiutta Oct 06 '15 at 14:41

    0 Answers0