RNG [RPi]
Rick Murray (539) 13806 posts |
Something to play with? |
patric aristide (434) 418 posts |
I don’t get it |
Rick Murray (539) 13806 posts |
Hardware based random number generator, apparently based upon some sort of thermal monitoring so not based upon a ‘predictable’ algorithm like |
Rick Murray (539) 13806 posts |
The problem with algorithmic random numbers is that given enough effort, they can be predictable.
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 ;-) ] |
patric aristide (434) 418 posts |
Interesting. NetSurf just showed an empty page hence my comment. Should’ve checked of course. |
Theo Markettos (89) 919 posts |
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. |
Rick Murray (539) 13806 posts |
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 |
Theo Markettos (89) 919 posts |
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. |
Rick Murray (539) 13806 posts |
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. |