| 1 |
On 09/03/2010 14:49, Brian Kroth wrote: |
| 2 |
> I read a couple of interesting threads regarding some arguments for and |
| 3 |
> against that yesterday. |
| 4 |
> |
| 5 |
> My basic reading is that |
| 6 |
> |
| 7 |
> - IRF_SAMPLE_RANDOM is due to be replaced by some other interface that's |
| 8 |
> common to all input devices. |
| 9 |
> |
| 10 |
> - There's a general feeling that gathering entropy from a network device |
| 11 |
> can be remotely influenced and is therefore probably not ideal. In |
| 12 |
> theory entropy can be obtained fairly well from other sources, like |
| 13 |
> the various egds mentioned already on this thread, or just by doing |
| 14 |
> hashes over some other special devices that that kernel already |
| 15 |
> provides. |
| 16 |
> |
| 17 |
|
| 18 |
Hmm, that's interesting reading - thanks for the links |
| 19 |
|
| 20 |
I'm not a cryto guy, so by definition I'm wrong, BUT, ignoring sources |
| 21 |
of entropy just seems wrong... |
| 22 |
|
| 23 |
The argument seems to be that: |
| 24 |
|
| 25 |
- You can observe network packets to a high accuracy under *some* |
| 26 |
circumstances |
| 27 |
- You can also observe other sources of entropy under some circumstances |
| 28 |
- Therefore under a fairly constrained set of circumstances it would be |
| 29 |
possible to feed only known entropy into the /dev/random pool |
| 30 |
- Under these circumstances it might be possible to figure out the |
| 31 |
output of the rng |
| 32 |
|
| 33 |
The counter argument is: |
| 34 |
- Instead my entropy pool just ran dry |
| 35 |
- This means that all important crypto algorithms are using /dev/urandom |
| 36 |
anyway |
| 37 |
- Once the entropy pool runs dry we are purely down to the rng |
| 38 |
algorithms anyway - so the quality of our rng is severely reduced... |
| 39 |
|
| 40 |
Seems like you are stuffed either way... |
| 41 |
|
| 42 |
The two big problems seem to be: |
| 43 |
- Using the same source for both high quality cryto needs (small number |
| 44 |
of high quality rng needed) and non crypto needs (eg SSP) |
| 45 |
- Lack of a unified feed for entropy which can take "poor" sources of |
| 46 |
entropy and still use them by blending them with higher quality sources |
| 47 |
(feeding in a known source of entropy from an attacker should not be a |
| 48 |
problem assuming a secure hash function and enough unknown entropy to |
| 49 |
make a bruteforce attack impractical) |
| 50 |
|
| 51 |
|
| 52 |
hmm... |
| 53 |
|
| 54 |
|
| 55 |
Ed W |
Archives