Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OneRNG – Open Hardware Random Number Generator

onerng.info

Post reply on HN
Print view View original

41–50 of 89 posts

Re: OneRNG – Open Hardware Random Number Generator

#41

Post by Taniwha »

dspillett wrote: post #39
Taniwha wrote: post #23

Note: I'm Paul the designer Some background - this board is in late beta testing, we're going to kickstart it and release it (with papers scheduled at a couple of conferences) - it's hitting Hacker News a little early - but keep us in mind when we do finally release to the public - at the moment we haven't published the design - we'll be putting up both the firmware an hardware designs on GitHub when we think it's re…

> we're going to kickstart it and release it Do you have any timescales for that yet, or are such decisions still heavily dependant on feedback from testing?

testing is good, no known roadblocks, we planning on a Decemberish time frame, we think we have a final firmware load at this point.

We have a small pick-and-place machine/etc setup we'll do a small in-house run for those who want to pay a premium for early delivery and then possibly a slower run depending on demand.

Re: OneRNG – Open Hardware Random Number Generator

#42

Post by Taniwha »

notthetup wrote: post #36
Taniwha wrote: post #33

Earlier quoted context omitted.

as part of our kickstarter we'll be offering programmers as an added reward - you can build the image from source and program your device - and we hope you do and share the results with the world You can't program it over the USB (although we could) we consider that that would be a security problem - and given recent security issues with programmable USB devices ....

One of the kickstarter rewards could be the ICSP programmer HW (i'm guessing that's what you're using) so who ever wants to program it could do it.

we use a home-grown programmer - it's cheap but the bed-of-nails cable costs as much as the board - we wont be making any money on them

Re: OneRNG – Open Hardware Random Number Generator

#43

Post by notthetup »

If the avalanche diode is the main/primary source of entropy why do we need the CC2531? The super paranoid part of me is worried about the 802.15.4 radio being used as a vector to taint the RNG.

Shouldn't an HW RNG NOT have any secondary communication method built in?

I am guessing you guys added that because that's the platform you're working with for your IOT project, but it just seems a little overkill to me. The diode data acquisition and the USB comms could be easily done using any Cortex-M0 type micro.

Re: OneRNG – Open Hardware Random Number Generator

#44

Post by DanBC »

deutronium wrote: post #20

I'm curious why they chose to use an avalanche diode which doesn't generate quantum-random numbers, unlike a reverse-biased transistor. As far as I'm aware, this means you could effect the numbers, by varying temperature.

https://news.ycombinator.com/item?id=7728216

> This article seems to be talking about using quantum effects for random number generation.

> The devices you point to use the semiconductor avalanche effect (http://en.wikipedia.org/wiki/Avalanche_breakdown) which is a thermal effect.

> > Most noise is quantum noise (including the one quoted, even though electron avalanche is a classic phenomenon, in semiconductors it's going to have quantum effects)

> > But in the end it doesn't matter, any unpredictable, non manipulable source of randomness is fine. Other sources of noise in electrical circuits (apart from quantum noise origins) are interference (like the 60Hz hum, radio interference, and even background radiation)

Re: OneRNG – Open Hardware Random Number Generator

#45

Post by deutronium »

Taniwha wrote: post #27
deutronium wrote: post #20

I'm curious why they chose to use an avalanche diode which doesn't generate quantum-random numbers, unlike a reverse-biased transistor. As far as I'm aware, this means you could effect the numbers, by varying temperature.

actually it is a reverse biased transistor

Aha cool, is the schematic online?

Re: OneRNG – Open Hardware Random Number Generator

#46

Post by Taniwha »

notthetup wrote: post #43

If the avalanche diode is the main/primary source of entropy why do we need the CC2531? The super paranoid part of me is worried about the 802.15.4 radio being used as a vector to taint the RNG. Shouldn't an HW RNG NOT have any secondary communication method built in? I am guessing you guys added that because that's the platform you're working with for your IOT project, but it just seems a little overkill to me. The…

I think that's a fair point, I agonized over it for quite a while - the cc2531 was the USB device/ and stack I was building with at the time.

This is the main reason why by default the device disables the RF source, you have to go out of your way to enable it by editing an /etc .conf file - however it actually does make a slightly better random stream

Re: OneRNG – Open Hardware Random Number Generator

#47

Post by [deleted] »

notthetup wrote: post #43

If the avalanche diode is the main/primary source of entropy why do we need the CC2531? The super paranoid part of me is worried about the 802.15.4 radio being used as a vector to taint the RNG. Shouldn't an HW RNG NOT have any secondary communication method built in? I am guessing you guys added that because that's the platform you're working with for your IOT project, but it just seems a little overkill to me. The…

[deleted]

Re: OneRNG – Open Hardware Random Number Generator

#48

Post by yen223 »

DanBC wrote: post #40
yen223 wrote: post #22

Earlier quoted context omitted.

Huh, interesting. What's the rationale behind the 2nd condition?

You have to design devices such that they don't fail when subject to interference. Put a mobile phone near a radio, send a text. You hear some burbling. Imagine that burbling is picked up by an insulin pump - you don't wan the pump to increase or decrease the dose based on that burble. See also analogue mobile phones which used to affect some gas station pump billing readouts. (CertInly some CB radios used to, whih c…

I think I misread that. It's supposed to mean "this device must be able to accept any interference received"?

Re: OneRNG – Open Hardware Random Number Generator

#49

Post by Taniwha »

deutronium wrote: post #45
Taniwha wrote: post #27

Earlier quoted context omitted.

actually it is a reverse biased transistor

Aha cool, is the schematic online?

not yet, the actual RNG circuit is pretty standard - we'll put up the eagle files, along with the software sources, before we open the kickstarter

Re: OneRNG – Open Hardware Random Number Generator

#50

Post by toong »

Taniwha wrote: post #38
michaelt wrote: post #31

Earlier quoted context omitted.

padding the image to the size of the ROM (256k, the runtime image is ~10k)with random data making it incompressible - signing the image (including the random bit) so that the image can't be altered You could pad it with data that looks random, but is secretly compressible. For example, the output of a prng with a known seed. Why not pad it with something that's already compressed, but which has information content, l…

well you have to consider me (the designer, the guy putting the original code in the device that you want to verify and make sure that it's not someone else's code) as trustworthy. After all I'm the one who's trying to protect the integrity of my product, I'm not going to give you a compressible bitstream if I can possible help it - and I'm going to publish the bitstream I am using so you can check

I think the parents point is that you generated the random-bitstream somehow, starting from a specific seed. If you know the seed, you could regenerates the random bitstream with a lot less bytes (=secretly compressible).

So now you have some extra room left on the ROM to embed your malicious firmware and still be able to dump the original full 256k.

If you start with a known image/photo (not yours, some public domain), that after encryption/compression is exactly the amount of padding you need (or cut-off), you have your padding-bitstream that is a lot harder to regenerate from a seed.

Edit: clarification

Post reply on HN