Disk Partition

[markus reichelt]

* Thomas Jones <admin at buddhalinux.org> wrote:

> The use of prng generated data to seed another prng function is
> utilized to compute data that is inherently random from the
> previous generation.

That is not my point, tho this might be the case. :)

If this generated data is used once, it's ok. If not, then there's a
problem. /dev/urandom is not as random as it might seem to the
ordinary user, that's what I'm trying to point out by having posted
the relevant part of a slackware boot init script. The discrepancy
lies in what the comment says and what the shell code actually does.

If an attacker gains access to random-seed, which has already been
used in cryptographic operations, it is to his advantage. The
ordinary user just doesn't want that, and is most likely not aware of
this flaw/possibility.

The best analogy would be the one-time pad. It's very secure if used
once, but if the same one-time pad is used twice, an attacker has a
foot in the door (if he intercepts relevant data, etc etc). I believe
this is what happened to some Soviet codes during the cold war.
One-time pads were reused which allowed American codebreakers to
eavesdrop. Anyway, this leads away from the topic at hand, so...


> Now this is not to say that it is truly random. Only that it is
> "sufficiently" random to provide for security of a particular
> resource.

Ack on that, and it is sufficient to use this pseudo-random data
once. Emphasis lies on once. If need be, just generate some chunk of
pseudo-random data again. The ordinary user most likely isn't aware
that /dev/urandom is initialized by re-using pseudo-random data. The
re-usage is the problematic thing. When reading the init scripts
(what even less users actually do...) they believe what the comments
say, hence ppl point out not to use /dev/urandom the way it is set up
on most systems. If in doubt one should have a close look at the
system's init scripts, and don't hesitate to ask.

I have been to some computer fairs and conferences, and each and
every time the crypto ppl never got tired of telling users about such
snares.


> For instance, there are such entities such as cryptographically
> secure prng; also known as csprng. A few instances of these
> entities are block ciphers such as 3des, aes, and the idea
> algorithms in cbc mode of operation.

Cryptographically secure random numbers are f.e. derived from
radioactive decay. John Walker wrote some article about it. But
that's not the point, I don't want to split hairs; and I would not
call 3des secure by any modern standards, even from aspects of
csprng. We most likely are talking at cross-purposes, so I would like
to sum up what is really important to me:

Concerning crypto stuff, using /dev/urandom is a bad idea, if
/dev/urandom has been initialized re-using pseudo-random data. Not
the quality of randomness of the data is the main concern, the data's
re-usage to initialize at boot a supposedly sufficiently random
device, namely /dev/urandom, is. Most linux distributions initialize
/dev/urandom in such a way. I merely want to draw attention to this
fact, because it often is overlooked. Additionally, it's easily
avoidable and the setup of /dev/urandom should be changed in
distributions which use the procedure.

-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20051008/7dbccea9/attachment.pgp