lundi 5 octobre 2015

Is Jericho Comms TRNG reliable?

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



Aucun commentaire:

Enregistrer un commentaire