At 08:09 AM 4/22/02 +0200, Eugen Leitl wrote:
>> And if one is implementing a PRNG in software, it is trivial to
>> have lots of internal state (asymptotically approaching one-time
>> pad properties).
>
>Yes, but software is too slow to be able to handle >GBit data rates.
It's
>inefficient use of CPU silicon real estate.
Comment on the latter: There is a lot of (high-margin) hardware made
which does something
that software can do, but much faster. This sounds obvious, but figure
out how long you
have to make a routing decision if your bits are coming in 10^10 / sec
and a new packet is every 2400 bits. Your basic Linux/486+2NICs
hobbyist router
does not have a chance :-) though its a perfectly viable solution at
lower rates.
Neither does your latest bleeding-edge general purpose Pentium-whatever.
So a general-purpose CPU is not just 'inefficient' ---its also
'insufficient'. Also,
they tend to burn a lot more watts than an ASIC would.
Comment on the former:
If you *really* had a reason and money for a hardware PRNG *and* you
needed
a lot of state, you'd just synthesize up a block of memory on your chip,
or an interface
to whatever kind of external D/SRAM you preferred.
\begin{understatement}
Software is a lot easier than h/ware if you don't need performance.
\end{understatement}
