Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)

Evgeniy Polyakov
2005-03-25T07:52:27Z

[-- Attachment #1: Type: text/plain, Size: 1803 bytes --]

On Fri, 2005-03-25 at 18:25 +1100, Herbert Xu wrote:
> On Fri, Mar 25, 2005 at 10:19:55AM +0300, Evgeniy Polyakov wrote:
> >
> > Noone will complain on Linux if NIC is broken and produces wrong
> > checksum
> > and HW checksum offloading is enabled using ethtools.
>
> This is completely different. The worst that can happen with checksum
> offloading is that the packet is dropped. That's something people deal
> with on a daily basis since the Internet as a whole does not guarantee
> the delivery of packets.

It will just completely stop network dataflow.
It is of course not as catastrophic as removing strong random numbers
from system.
But nevertheless - write cahce in disks may corrupt data on power-down,
but people do not turn it off, crypto HW can be broken and does not
encrypt dataflow, but people want it, broken NIC can corrupt data with
various sg/offload combinations, but it can be enabled.

It is a feature, that _may_ broke thing badly.
But if all is ok - it is extremly usefull.

And as I said there may be other [HW/driver] validating techniques,
not only userspace daemon.

> On the other hand, /dev/random is something that has always promised
> to deliver random numbers that are totally unpredictable. People out
> there *depend* on this.
>
> If that assumption is violated the result could be catastrophic.
>
> That's why it's OK to have hardware RNG spit out unverified numbers
> in /dev/hw_random, but it's absolutely unaccpetable for the same
> numbers to add entropy to /dev/random without verification.

Userspace daemon can read data from /dev/random and validate it
in background, if it fells it is broken - turn feature off.

--
Evgeniy Polyakov

Crash is better than data corruption -- Arthur Grabowski

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]