maemo.org - Talk

maemo.org - Talk (https://talk.maemo.org/index.php)
-   Brainstorm (https://talk.maemo.org/forumdisplay.php?f=47)
-   -   Use CCD noise to make the random number generator uncrackable (https://talk.maemo.org/showthread.php?t=58119)

samualwalters 2010-07-09 16:00

Use CCD noise to make the random number generator uncrackable
 
Random number generators are generally crackable, and some versions of the Debian openssl implementation (used in maemo) is known to be weak (ref http://talk.maemo.org/showthread.php?t=20077)

The solution is to use noise from the CCD as a random number generator. The n800 CCD is quite noisey (when the camera is not ejected, the black screen shows copious random noise).

It's also more convenient than asking the user to doodle and press random buttons.

cashclientel 2010-07-09 16:15

Re: Use CCD noise to make the random number generator uncrackable
 
or you could use some component of the cell reception?

If you want to use the camera you've got to engage it, etc, which could be a pain. certainly the front camera would be best as you don't have to open the lens.

Or can use the battery power remaining * time

or loads of things - it has loads of sensors (motion, bluetooth, ir, gps...)

lma 2010-07-09 17:57

Re: Use CCD noise to make the random number generator uncrackable
 
What's wrong with /dev/hwrng?

ossipena 2010-07-09 18:05

Re: Use CCD noise to make the random number generator uncrackable
 
khrm. who says ccd noise is random?

(it is partly but not completely)

samualwalters 2010-07-09 19:20

Re: Use CCD noise to make the random number generator uncrackable
 
Quote:

Originally Posted by lma (Post 746308)
What's wrong with /dev/hwrng?

It's apparently not very random. I just grabbed a sample by running this on the device:

dd if=/dev/hwrng of=dump

In visually examining the hex, I noticed a heck of a lot of 16's. To see if I was hallucinating, I ran this on the file:

for x in {0..9}; do od ./dump | grep -c ${x}6; done
11926
11238
7535
7351
7562
7352
6880
7419
0
0

Doesn't look like a very even distribution to me. Not a single 86 or 96 appeared in the sample.

I also noticed this bug report on it:

https://dev.laptop.org/ticket/8089

samualwalters 2010-07-09 19:25

Re: Use CCD noise to make the random number generator uncrackable
 
Quote:

Originally Posted by ossipena (Post 746317)
khrm. who says ccd noise is random?

(it is partly but not completely)

It's not proven either way, but generally considered cryptographically sound. See http://en.wikipedia.org/wiki/LavaRnd

Wired did an article on this ~5-8 years ago, iirc.

What would you consider to be a more random source available on the nit?

CrashandDie 2010-07-09 22:31

Re: Use CCD noise to make the random number generator uncrackable
 
Except that CCD noise isn't random at all, and very much retraceable.

This is especially true for high usage of a CCD sensor. If you have an old camera, and notice "hotspots" (red, green or whatever), then you will understand it quite a bit.

What happens is that when the sensor is being used quite a bit, it heats up, and the photosensitive cells react to this heat. Most dSLRs and prosumer P&S cameras include a "noise cancelling" feature for long exposure (any exposure of more than 1/250 of a second), where the shutter is closed, and the sensor is "snapping a picture" of blackness.

The hotspots will show up, and then you can run an algorithm to remove the hotspots from the black-box picture in the actual picture.

Based on this (quite common knowledge amongst photographers), I would say that this method isn't much more secure than using the CPU's temperature as a seed to initiate the random number generator. That, or the nanotime, or whatever is available on the platform.

lma 2010-07-10 00:22

Re: Use CCD noise to make the random number generator uncrackable
 
Quote:

Originally Posted by samualwalters (Post 746398)
It's apparently not very random.

A quick test with ent on a 1MiB sample suggests it is:
Code:

$ ent hwrngdump
Entropy = 7.999823 bits per byte.

Optimum compression would reduce the size
of this 1048576 byte file by 0 percent.

Chi square distribution for 1048576 samples is 256.82, and randomly
would exceed this value 50.00 percent of the times.

Arithmetic mean value of data bytes is 127.4373 (127.5 = random).
Monte Carlo value for Pi is 3.143978668 (error 0.08 percent).
Serial correlation coefficient is 0.000647 (totally uncorrelated = 0.0).

Quote:

for x in {0..9}; do od ./dump | grep -c ${x}6; done
...
Doesn't look like a very even distribution to me. Not a single 86 or 96 appeared in the sample.
Well, as its name suggests, od outputs octal values by default so that's to be expected ;-)

Quote:

I also noticed this bug report on it:

https://dev.laptop.org/ticket/8089
Note that that report talks about a completely different hardware random number generator.

juise- 2010-07-10 00:52

Re: Use CCD noise to make the random number generator uncrackable
 
Quote:

Originally Posted by CrashandDie (Post 746629)
Except that CCD noise isn't random at all, and very much retraceable.

There's a random part, and a non-random part to CCD noise. Making use of the non-random part is a good idea, but one first needs to figure out which parts of the noise are caused by the true randomness.

The non-random part consists of biases of single transistors and such. The random part consists of real physical random things (e.g. the exact amount of photons that happened to hit this cell during the observation). The trick is to find which part is random and which is not.

Counter-thesis: If the noise was completely non-random, it could be exactly determined, and thus completely removed from the result image.

samualwalters 2010-07-10 08:06

Re: Use CCD noise to make the random number generator uncrackable
 
Quote:

Originally Posted by lma (Post 746734)
A quick test with ent on a 1MiB sample suggests it is:
Code:

$ ent hwrngdump
Entropy = 7.999823 bits per byte.

Optimum compression would reduce the size
of this 1048576 byte file by 0 percent.


I take that to indicate the compression algorithm in ent is not taking advantage of all forms of repetition. Having a disproportionately high number of very short patterns (of 06 and 16), for example, isn't necessarily enough to get significant compression.
Quote:

Originally Posted by lma (Post 746734)
Well, as its name suggests, od outputs octal values by default so that's to be expected ;-)

Good point! But what about the disproportionate number of 0's and 1's, while 2-7 was evenly distributed?


All times are GMT. The time now is 03:53.

vBulletin® Version 3.8.8