* Thomas Jones <[EMAIL PROTECTED]> 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. --
pgpQYvnBdLqis.pgp
Description: PGP signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
