RNG [RPi]

Something to play with?

http://pastehtml.com/view/crkxyohmp.rtxt

I don’t get it

Hardware based random number generator, apparently based upon some sort of thermal monitoring so not based upon a ‘predictable’ algorithm like rand() (C) or RND (BASIC), etc.

The problem with algorithmic random numbers is that given enough effort, they can be predictable.
BASIC’s is extremely predictable once you know the algorithm, and beginning with the same seed will always return the same sequence of numbers.

>10 x% = RND(-123)
>20 FOR x% = 1 TO 5
>30   PRINT RND(255);
>40 NEXT
>50 PRINT
>
>RUN
        99         251           8         151         122
>RUN
        99         251           8         151         122
>RUN
        99         251           8         151         122
>

With a hardware random number generator, it is a little more difficult because you cannot see the algorithm; however once that is cracked, the entire chip is useless for random numbers.

A better way is a “true” random number source that uses some sort of external event (such as the time between ticks of a geiger counter) to provide the randomness. This method, built into the Pi, is simpler but should yield good truly random numbers.

[this sort of stuff is more important in cyptography than in computer-controlled-characters in a game ;-) ]

Interesting. NetSurf just showed an empty page hence my comment. Should’ve checked of course.

Rick, where did that come from?

I can add support to CryptRandom but with security things I’m aware that context is important. There might be a page in the datasheet that says ‘write 37 to register FOO otherwise the RNG is no good’: if I only have an excerpt from the datasheet I might miss that. And it’s very difficult to prove that an RNG is doing the right thing.

Context is hard to do with the Broadcom datasheet. :-/

Came from here: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=29&t=19334&start=275
About halfway down the page.

OK, that’s probably enough. I can plumb it into CryptRandom’s random number pool so all it needs is entropy rather than pure randomness.

Thinking about this, I could write a HAL entry for it but CryptRandom is the RISC OS random number API, so it might as well poke the hardware directly (after all, it already reads A4 battery state and suchlike). Is there any way to sensibly read whether you’re on a BCM2835 or some other chip, so that I can only enable it when the hardware is present? OS_ReadSysInfo 8 is unhelpful and I don’t see any other useful call.

Is there any way to sensibly read whether you’re on a BCM2835 or some other chip, so that I can only enable it when the hardware is present? OS_ReadSysInfo 8 is unhelpful and I don’t see any other useful call.

Yes, but it is something RISC OS probably ought to add to the OS_ReadSysInfo API!

After checking you are on a HAL build of RISC OS (ReadSysInfo 8), call OS_Hardware 4 for HALDeviceComms_GPIO.

Halfword at +2 (header ID field; halfword) is the processor type (0=OMAP3, 1=OMAP4, 2=BCM2835). If you need it, board type is at +64 (word) and board revision is at +68 (word). They are unfortunately not unique so a board type of ‘0’ could be a RaspberryPi or a Beagle. It’s the CPU type halfword that tells them apart.