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.

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

What's wrong with /dev/hwrng?

khrm. who says ccd noise is random?

(it is partly but not completely)

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

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?

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.

A quick test with ent on a 1MiB sample suggests it is:
Well, as its name suggests, od outputs octal values by default so that's to be expected ;-)

Note that that report talks about a completely different hardware random number generator.

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.

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.
Good point! But what about the disproportionate number of 0's and 1's, while 2-7 was evenly distributed?