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

The Raspberry Pi’s Hardware Random Number Generator

scruss.com

Post reply on HN
Print view View original

61–69 of 69 posts

Re: The Raspberry Pi’s Hardware Random Number Generator

#61

Post by Dylan16807 »

nwh wrote: post #55
Dylan16807 wrote: post #51

Earlier quoted context omitted.

What's a joke? There is nothing ridiculous about using network timing as random, that's how /dev/random already works. There is nothing ridiculous about using random.org, though that should be https.

> There is nothing ridiculous about using random.org, though that should be https. Everything is wrong about this. • You can not trust SSL to protect your source of entropy. • You can not trust an external, unverified source of entropy.

Pretend for a moment that you have isolated hardware with no trusted random sources. And this hardware already depends on large secret binary blobs to run at all. At this point trust is already hard, and random.org is a hell of a lot better than nothing. If you mix network jitter with external randomness sources that's just about the best possible job you can do. Neither half is perfect but they help.

Re: The Raspberry Pi’s Hardware Random Number Generator

#63

Post by nwh »

Dylan16807 wrote: post #61
nwh wrote: post #55

Earlier quoted context omitted.

> There is nothing ridiculous about using random.org, though that should be https. Everything is wrong about this. • You can not trust SSL to protect your source of entropy. • You can not trust an external, unverified source of entropy.

Pretend for a moment that you have isolated hardware with no trusted random sources. And this hardware already depends on large secret binary blobs to run at all. At this point trust is already hard, and random.org is a hell of a lot better than nothing. If you mix network jitter with external randomness sources that's just about the best possible job you can do. Neither half is perfect but they help.

Every linux distro has /dev/random as a good, cryptographically secure source of randomness that is refilled by as many sources as possible. It can and has been audited by many developers to ensure this. The main issue you will have is having multiple identical instances of a linux VM built from a single source, or something like that.

Alternatively, you suggest a sole remote source over a public internet connection. Assuming an eavesdropper, the source could be compromised or the strength of the resulting cipher be reduced. Assuming a malicious entity with network control, you're pretty much screwed.

If you don't trust your hardware, you can't be working with encryption.

Re: The Raspberry Pi’s Hardware Random Number Generator

#64

Post by Dylan16807 »

nwh wrote: post #63
Dylan16807 wrote: post #61

Earlier quoted context omitted.

Pretend for a moment that you have isolated hardware with no trusted random sources. And this hardware already depends on large secret binary blobs to run at all. At this point trust is already hard, and random.org is a hell of a lot better than nothing. If you mix network jitter with external randomness sources that's just about the best possible job you can do. Neither half is perfect but they help.

Every linux distro has /dev/random as a good, cryptographically secure source of randomness that is refilled by as many sources as possible. It can and has been audited by many developers to ensure this. The main issue you will have is having multiple identical instances of a linux VM built from a single source, or something like that. Alternatively, you suggest a sole remote source over a public internet connection.…

Software can only do so much without good hardware sources. A small embedded box, barred from networking, has roughly zero entropy available. But if you combine microsecond network timings, only vulnerable to local attack, with third party random data that is safe from mitm, you get resonably good random numbers. Don't use it to generate a root certificate, but it'll work for general purposes.

Re: The Raspberry Pi’s Hardware Random Number Generator

#65

Post by marshray »

Dylan16807 wrote: post #64
nwh wrote: post #63

Earlier quoted context omitted.

Every linux distro has /dev/random as a good, cryptographically secure source of randomness that is refilled by as many sources as possible. It can and has been audited by many developers to ensure this. The main issue you will have is having multiple identical instances of a linux VM built from a single source, or something like that. Alternatively, you suggest a sole remote source over a public internet connection.…

Software can only do so much without good hardware sources. A small embedded box, barred from networking, has roughly zero entropy available. But if you combine microsecond network timings, only vulnerable to local attack, with third party random data that is safe from mitm, you get resonably good random numbers. Don't use it to generate a root certificate, but it'll work for general purposes.

> Don't use it to generate a root certificate, but it'll work for general purposes.

"General purposes" is exceedingly hard to quantify.

Re: The Raspberry Pi’s Hardware Random Number Generator

#66

Post by tptacek »

ooorlllyyy wrote: post #49
tptacek wrote: post #37

Earlier quoted context omitted.

If you don't trust a chip vendor's remote patching, there's nothing you can trust on the chip cryptographically at all.

Wait a second, wouldn't this statement imply that things like cert-pinning and PFS are completely useless? Does skepticism of remote patching while trust of the original chip not protect you against being specially targeted if you assume that the chips aren't being wholesale manufactured with back doors built in?

Yes, if you think the NSA has backdoored all mainstream Intel chips, then certificate pinning and forward secrecy are not particularly meaningful.

Re: The Raspberry Pi’s Hardware Random Number Generator

#67

Post by Dylan16807 »

marshray wrote: post #65
Dylan16807 wrote: post #64

Earlier quoted context omitted.

Software can only do so much without good hardware sources. A small embedded box, barred from networking, has roughly zero entropy available. But if you combine microsecond network timings, only vulnerable to local attack, with third party random data that is safe from mitm, you get resonably good random numbers. Don't use it to generate a root certificate, but it'll work for general purposes.

> Don't use it to generate a root certificate, but it'll work for general purposes. "General purposes" is exceedingly hard to quantify.

How about this: it's much easier for an attacker to physically compromise the device than it is for them to attack your network AND attack random.org.

Is that not good enough? It's about as secure as your average desktop. You can't make a device more secure than the access to it, and there is no such thing as perfect security.

Re: The Raspberry Pi’s Hardware Random Number Generator

#68

Post by ooorlllyyy »

tptacek wrote: post #66
ooorlllyyy wrote: post #49

Earlier quoted context omitted.

Wait a second, wouldn't this statement imply that things like cert-pinning and PFS are completely useless? Does skepticism of remote patching while trust of the original chip not protect you against being specially targeted if you assume that the chips aren't being wholesale manufactured with back doors built in?

Yes, if you think the NSA has backdoored all mainstream Intel chips, then certificate pinning and forward secrecy are not particularly meaningful.

That's not really what I was getting at though.

Let's say I don't think the NSA has backdoored all the mainstream fablines, but have reason to fear being individually targeted, and assume that the NSA has the power to coerce cooperation from Intel. In that case, would skepticism of post-purchase remote patching not be prudent?

Re: The Raspberry Pi’s Hardware Random Number Generator

#69

Post by ooorlllyyy »

tptacek wrote: post #66
ooorlllyyy wrote: post #49

Earlier quoted context omitted.

Wait a second, wouldn't this statement imply that things like cert-pinning and PFS are completely useless? Does skepticism of remote patching while trust of the original chip not protect you against being specially targeted if you assume that the chips aren't being wholesale manufactured with back doors built in?

Yes, if you think the NSA has backdoored all mainstream Intel chips, then certificate pinning and forward secrecy are not particularly meaningful.

(I mentioned PFS and CP because I perceive them as paradigmatically analogous to the threat model I described - suppose that not ALL of DDG's queries are MITM'd, and yours weren't when you first connected, but you're afraid of the NSA MITMing the queries coming from your connection starting at some date after you made your initial connection to DDG's server, when they start targeting you. If you trust the initial connection, then CP prevents that. Or, again, post facto to you starting to use DDG, the NSA could obtain DDG's SSL private key and decrypt your queries, but if you use PFS, then this is mitigated.

So in each case, it seems, whatever trust you have in the initial transaction -- be it a SSL cert presentation, the particular SSL sessions based on it, or just the purchase of your hardware -- being malice-free, then in each case the pinning/PFS/lack of remote patching abilities guarantees the extension of this trust indefinitely, and prevents the other party from going back after the fact and screwing you, it locks the trust in, so to speak.)

(I realized after typing this that I actually have no idea what specifically remote chipset patching refers to or how it's performed, but I assume that it's what it sounds like.) :-/

Post reply on HN