Deleted my inbox, who knew that also deleted all of the article comments? Unhappy Jan!
Anyways, here are some responses to the issues which people have mentioned.
The people who posted with concerns that Broadcom may have subverted the random number generator miss a point. There are two things happening here: the addition of randomness to the kernel's entropy pool, and the accounting for that. If you don't trust the RNG then add the randomness, but set the accounting to count zero bits of randomness added. The entropy pool won't release bits any faster than are provided by non-RNG data sources, but the quality of the randomness may be better if the RNG is outputting any randomness at all.
You might reasonably choose not to trust the Broadcom RNG due to the lack of documentation explaining it's principles of operation. For example, what happens when you apply environmental stress? Presumably the RNG is there to allow randomness for choosing GSM and 3G session keys, and that might mean that the RNG keeps providing numbers, rather than halting -- after all no one wants their phone to stop working just because it was left in the sun or ice. Explaining to users that their phone may be operating in a subverted mode is a user interface nightmare, so it's possible that the RNG isn't even designed to signal when it is operating out of range.
You also shouldn't assume that the Linux random number system can't be subverted. You wouldn't do that through source code, but through timing and memory attacks.
If you start to audit the sources of entropy against their ability to be subverted externally the news gets bad rather quickly on a computer without spinning disk. Adding the output of /dev/hwrng to the entropy pool of /dev/random is really meant to be a simple way to overcome this major problem of a lack of system entropy where near boot. It isn't anything approaching trusted computing, where every minor problem has the be shut tightly.
If you really need a random number you are better off doing this in your application: k = read /dev/random (whichout /dev/hwrng contributing to the entropy pool) b = read /dev/hwrng n = x xor b as that will save you from timing attacks (assuming the Broadcom hwrng isn't subverted, but then you are no worse off anyways).
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Date: 2013-10-14 01:52 (UTC)Anyways, here are some responses to the issues which people have mentioned.
The people who posted with concerns that Broadcom may have subverted the random number generator miss a point. There are two things happening here: the addition of randomness to the kernel's entropy pool, and the accounting for that. If you don't trust the RNG then add the randomness, but set the accounting to count zero bits of randomness added. The entropy pool won't release bits any faster than are provided by non-RNG data sources, but the quality of the randomness may be better if the RNG is outputting any randomness at all.
You might reasonably choose not to trust the Broadcom RNG due to the lack of documentation explaining it's principles of operation. For example, what happens when you apply environmental stress? Presumably the RNG is there to allow randomness for choosing GSM and 3G session keys, and that might mean that the RNG keeps providing numbers, rather than halting -- after all no one wants their phone to stop working just because it was left in the sun or ice. Explaining to users that their phone may be operating in a subverted mode is a user interface nightmare, so it's possible that the RNG isn't even designed to signal when it is operating out of range.
You also shouldn't assume that the Linux random number system can't be subverted. You wouldn't do that through source code, but through timing and memory attacks.
If you start to audit the sources of entropy against their ability to be subverted externally the news gets bad rather quickly on a computer without spinning disk. Adding the output of /dev/hwrng to the entropy pool of /dev/random is really meant to be a simple way to overcome this major problem of a lack of system entropy where near boot. It isn't anything approaching trusted computing, where every minor problem has the be shut tightly.
If you really need a random number you are better off doing this in your application:
k = read /dev/random (whichout /dev/hwrng contributing to the entropy pool)
b = read /dev/hwrng
n = x xor b
as that will save you from timing attacks (assuming the Broadcom hwrng isn't subverted, but then you are no worse off anyways).