back to article Meet OneRNG: a fully-open entropy generator for a paranoid age

One of the many bits of technology that attracts paranoia in a post-Snowden era is random number generation, and a New Zealand developer hopes to help solve that with an all-open entropy generator. As often happens in Middle Earth New Zealand these days, Paul Campbell of Moonbase Otago is invoking Tolkien by naming the project …

  1. Voland's right hand Silver badge

    Similar to Via CPUs

    This as a source of entropy looks similar to the hardware RNG on Via CPUs (similar quantum noise source), just fully "DIY".

  2. Chairo

    Obligatory xkcd reference

    http://xkcd.com/221/

  3. Anonymous Coward
    Anonymous Coward

    Engineering looks good. I can't speak to the cryptographic procedural issues. Nice.

  4. A Non e-mouse Silver badge

    Infinite Loop?

    To add to the randomness...the radio receiver frequency also bounces around randomly

    So what's the source for the randomness for the random frequency hopping? Another OpenRNG?

    1. MoonbaseOtago

      Re: Infinite Loop?

      we steal it from the received random stream - given that an external interferer can't reliably predict our sampling clock it's very hard to predict what we're really receiving

    2. Charles 9

      Re: Infinite Loop?

      The radio chip probably takes a cue or two from the avalanche diode, which is known to be random but IINM isn't as quick.

  5. frank ly
    Coat

    OneRNG

    To rule them all. It would be New Zealand wouldn't it?

    Coat: No explanation needed.

  6. Anonymous Coward
    Anonymous Coward

    How it will work in absence of a radio signal?

    Thinking of basements or other similar locations where radio waves can't get in. Will its performance degrade, shut itself off or give a stream of more predictable bytes?

    1. Robert Grant

      Re: How it will work in absence of a radio signal?

      Or alternatively, what if you blasted it with a custom radio signal? Could you ever do that accurately enough to prescribe the next number?

      1. phuzz Silver badge

        Re: How it will work in absence of a radio signal?

        Well, it only uses the least significant bit*, so it would be difficult to correctly predict/force that, and you'd also have to find a way to predict the frequency hopping, so to effectively control the output you'd pretty much need the whole device under your control, or at least access to the room it's in.

        * so the slightest change in the received radio signal should make a large difference to the output.

      2. MoonbaseOtago

        Re: How it will work in absence of a radio signal?

        so to answer the two above questions - with no signal we will just get noise which is a good thing, with a signal present we'll get the LSB of the signal which will likely be external noise anyway - we understand that some people will be understandably paranoid about using external RF noise so we disable this noise source by default - you have to go out of your way to choose to use it

    2. Irongut

      Re: How it will work in absence of a radio signal?

      "a radio receiver, which Campbell explained to Vulture South picks up noise"

      He doesn't mean Nicky Minaj, he means RF noise which will exist in your basement whether you can pick up Radio One or not.

  7. Charles 9

    I haven't seen the actual design yet, but I'd be curious to see if they've account for every paranoid scenario, including discretely switched out parts or a device reprogrammed (via the dedicated port) to subvert the system yet return all the right signals during checking stages.

    1. Destroy All Monsters Silver badge

      "Remember: UBIKRAND's entropy is smooth and easy. Avoid prolonged use."

      That's Philip K. Dick levels of paranoia. You can't check for that.

      1. Charles 9

        Re: "Remember: UBIKRAND's entropy is smooth and easy. Avoid prolonged use."

        Perhaps not that paranoid, but perhaps the signature checks can be set up so the memory can be read by another chip and a signature checked from that while the chip that does the checking can be a simple mask ROM whose internal can be verified in, say, an x-ray. The diodes can perhaps be replaceable by the user, among other things that would make subverting the device and keeping it subverted too difficult under all practical circumstances.

    2. JimCheetham

      Verification ...

      Hi, I'm the non-hardware part of OneRNG ...

      You can see all the components on the board, and with good light can pretty much verify the routing of all the traces, top and bottom (you'd have to take off the tinfoil helmet first - there's a shield over the main components, but it pops on and off easily). The only serious contender for supply-chain tampering is the single complex component, the CC2531 CPU. If the firmware is replaced, the replacement would fail signature validation.

      The only practical hardware attack here would be to come up with a device that looks like a CC2531, but with significantly larger internal storage so it could hold our full 256K image and its own code. As usual with trust, there's only so far down that you can go before hitting a practical limit. In the case of OneRNG, at this stage we have to assume that this ubiquitous low-cost device that is used in such a huge range of equipment (ZigBee etc), and is sourced from the low-cost end of the supply chain, is an unlikely target for subversion. Also, Paul has a fair bit of recent experience with this chip from other projects, and that helps :-)

      We do tip the hat towards concern for the onboard AES module; we don't use it in the data handling at all, and instead do lightweight whitening with CRC16. Therefore at the moment we're not a perfect RNG directly, but we are a great source of entropy to mix in as an input to /dev/random.

      Once the system is in place with our firmware, it can only be reprogrammed through a dedicated port on the board, and not via USB at all. A dab of glue will help reassure you about future use of that port.

      At the end of the day, we need to be running code somewhere on the device, which means using a stock CPU from somewhere ... and it is difficult to visually inspect a CPU in a non-destructive way. Even if you built your own unit (we will be publishing all the details, this is Open Hardware and Open Software) you would have to take that chip on trust - probably you could mitigate the risk by buying a second-hand unit that used the chip, and reuse it from there, but that's not a practical manufacturing choice for us at this stage. Possibly we'd be able to choose a 'simpler' CPU at some stage, but I don't see that we would get any specific security value from that. We might get cost savings or something, but unless we find some form of CPU that can be inspected it won't address that trust issue.

      If that isn't paranoid enough, please let me know!

  8. Anonymous Coward
    Anonymous Coward

    Why radio?

    The design apparently gets better "noise" from the radio receiver than the diode (actually a reverse biased base-emitter junction) but it wasn't obvious to me why you couldn't just use multiple diodes and combine the results.

    1. Anonymous Coward
      Anonymous Coward

      Re: Why radio?

      I think the reason is that while the radio receiver can receive more noise, it's more difficult to vouch for the quality of the noise compared to the diode. If you were to take each one, for example, and run them through chi-square analysis, the odds are greater the radio noise will show bias which will show as a drift off 50% likelihood. That's probably why the device also includes a whitener, which reduces the throughput but makes it more consistently random.

      1. MoonbaseOtago

        Re: Why radio?

        I think that this is a fair comment, as I mentioned above we don't enable the RF source by default - you can choose to enable one or the other or both, with the whitener turned on it smears the two streams into each other

        In our case the platform was based on one we were already using for an IOT project, it came with the RF 'for free' which is why we added it.

        Our whitener is pretty trivial, our hardware (a TI CC2531) has AES which we could use for this purpose but if we can't trust other people's chips embedded crypto we can't trust this crypto either. We are using an embedded CRC16 unit for whitening but we can write code to verify the crc16 hardware. Our main reason for using the whitener is to convince the linux rngd daemon that our stream is good enough to pass on - if you want you can disable the whitener and get access to the raw bit streams and process it yourself

  9. Olius

    N00b question...

    Can anyone explain to a crypto n00b why it is important that every number from /dev/random has to come from a "proper" random source, and why it would be bad to (partially/fully) fill a pool with pseudo-randomness but then use a few "real" random number to stir it with? If the pseudo-random generator produced a good "spread" and the "real" randoms stirred the pool then break all relationships between the pseudo-numbers in the sequence by reordering the sequence, is that still "less" random than a full set of "real" randoms and is it easier to break?

    1. Charles 9

      Re: N00b question...

      The philosophy behind it is that /dev/random is meant to output high-quality random data that would be used for high-security applications like key generation (places where you really really need the output to be unpredictable). It was thought that only high-security applications would need high-quality random data. For most other purposes, Linux also provides /dev/urandom, which isn't as high-qualty because it uses an alternative algorithm to ensure it doesn't block (/dev/random blocks when it runs out of entropy). The reasoning is that an agent with vast resources, such as a state, might be able to predict a pseudorandom patten just long enough to pick up key bits of information that can be used to further subvert the encryption.

      I think the problem right now is that we're seeing an increasing need for high-security random data (take a secure server, for example, that needs to generate tons of crypto keys on the spot) to the point that /dev/urandom is not considered good enough. And that's where these hardware RNGs come in. The thought behind an open design is that any copy of the device you have can be checked against the plans for possible subversion by a resourceful adversary such as a state.

  10. GrumpenKraut

    "retains the least significant bit"

    Not great do discard all high bits. Use them somehow, e.g, by using the Hamming weight of the measurements, and/or feeding them through shift registers.

    1. Anonymous Coward
      Anonymous Coward

      Re: "retains the least significant bit"

      Probably you could just stuff the full RF signal through a SHA-2 hash and select a suitable subset of the output bits. Anyone wanting to manipulate the output would then have to find hash collisions at a rate of about 64kB/s. If they could do that, they'd be elsewhere mining Bitcoins, not bothering you.

      1. GrumpenKraut

        Re: "retains the least significant bit"

        SHA* (in hardware) is significantly more expensive than a shift register.

        Remember, the device to be built is aimed at cheap.

  11. MoonbaseOtago

    Notes ...

    Paul here - the designer .... some answers to questions above:

    "So what's the source for the randomness for the random frequency hopping? Another OpenRNG?" - existing random data in the onboard entropy pool

    "How it will work in absence of a radio signal?" we're not looking for a signal but the random noise that's in the environment - the receiver AGC (automatic gain control) will run up the input noise to as loud as possible to get some useful noise

    "Or alternatively, what if you blasted it with a custom radio signal? Could you ever do that accurately enough to prescribe the next number?" we don't think so - any received signal is going to contain environmental noise and because the transmitter can't predict the clock edges we're using for sampling it's particularly hard - you can run the board in a mode where it mixes the two internal noise sources - and by default the RF source is turned off - we understand that using an RF source is potentially something that some people will gag at because they can imagine potential problems, you have to choose to enable it

    " haven't seen the actual design yet, but I'd be curious to see if they've account for every paranoid scenario, including discretely switched out parts or a device reprogrammed (via the dedicated port) to subvert the system yet return all the right signals during checking stages." so we will be providing full schematics, board layout and photos of boards - rather than having a plastic case we have an RF shield (to keep the noise in and interfering signals out) - the lid of the shield (its "tin foil hat") is removable so you can verify that what's inside is what should be inside

    "The design apparently gets better "noise" from the radio receiver than the diode (actually a reverse biased base-emitter junction) but it wasn't obvious to me why you couldn't just use multiple diodes and combine the results" we could but it would push the price up a bit - in effect you so actually get this in most cases - if you don't pull data from the board at its full rate (around 64k bytes/sec) then any extra entropy spills into the on-board entropy pool rapidly raising the entropy from 7.8 to 8 bits/byte quite fast

    "Not great do discard all high bits. Use them somehow, e.g, by using the Hamming weight of the measurements, and/or feeding them through shift registers." that would be nice but the hardware we're using doesn't provide all the DAC data, it does provide the LSB data for those who want to create a random number generator

    Finally - a reminder, our goal here is to make entropy, not industrial grade random numbers for crypto, we do a great job of the first and a vaguely OK job of the second but really we expect you to use our entropy as a seed for an existing RNG that you trust (like the one in the linux kernel's /dev/random)

    Feel free to ask any other questions

    1. MoonbaseOtago

      Re: Notes ...

      oops - I thought this response got swallowed - apologies for the duplicate responses

  12. MoonbaseOtago

    Mooltipass

    BTW since we're talking about open source crypto hardware I'd like encourage people to support moolti-pass an open source password keeper

    https://www.indiegogo.com/projects/mooltipass-open-source-offline-password-keeper

    1. Charles 9

      Re: Mooltipass

      Isn't KeePass GPL2+?

  13. Jamie Jones Silver badge

    "An external entropy generator also provides more entropy, in terms of bytes per second, than the kernel gets simply from /dev/random. “Dev/random provides a few bytes per second,” he told Vulture South. “We provide about 64k bytes per second”."

    This does sound like a great source of extra entropy, but there are non-blocking pseudogenerators considered secure as long as they are correctly seeded, so with proper operating systems, it's not simply a case of 'slow but good' / 'fast but suspect'.

    Yarrow (the predecessor to Fortuna - https://www.schneier.com/fortuna.html ) gives 60MB a second on my modest server:

    5:32 (3) "~" jamie@catflap% dd if=/dev/random bs=1m count=100 of=/tmp/fart

    100+0 records in

    100+0 records out

    104857600 bytes transferred in 1.723317 secs (60846374 bytes/sec)

    1. Anonymous Coward
      Anonymous Coward

      But if the CPU's already loaded with other things, then you need a source that's CPU-independent.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like