in reply to Re^3: Your random numbers are not that random (UtS,L)
in thread Your random numbers are not that random

A simple denial-of-service vulnerability is far from the worst-case scenario... If the code has any sort of cryptographic functionality, if it generates random passwords, or anything of that sort, then weak random numbers can lead to far worse than that, as they'll give an attacker a much better chance of guessing any randomly-generated values (such as session keys or random passwords).

Of course, if you're doing anything along those lines, I sincerely hope that you'd be using a properly-installed perl rather than one copied onto an SD card, so this is unlikely to be an issue in practice.

  • Comment on Re^4: Your random numbers are not that random (UtS,L)

Replies are listed 'Best First'.
Re^5: Your random numbers are not that random (UtS,L)
by davies (Monsignor) on Jul 22, 2012 at 11:04 UTC

    I'm not clear on the distinction between "properly installed" and on an SD card. The Pi boots off an SD card, and while it is possible to put stuff onto a USB hard drive, it's rather complicated for the OS stuff. So the system Perl is certainly on a card, as are most things Pi related. All the cards I'm trying to create are bootable and intended to be used to boot Pis. Am I missing something?

    Regards,

    John Davies

[reply]
Re^5: Your random numbers are not that random (UtS,L)
by Anonymous Monk on Jul 22, 2012 at 19:26 UTC

    I ran on the assumption that it is the random number generator failing only for the hash seeding code -- hence downplaying the problem. I have no idea which RNG the actual rand() function uses, but password/session key generation can be made reasonably secure even with a nonfunctional RNG.

    To the OP: What sort of results do you get if you run perl -le 'print rand() for 1..10' on the faulty boards? If you run it twice, will the same sequence repeat? What about on the working boards?

[reply]
[d/l]

      but password/session key generation can be made reasonably secure even with a nonfunctional RNG

      Really? How? That is a pretty big assumption.

      How do you protect against predictably generated keys? Say, if the device does not have a hardware clock (and this one doesn't) and the program is started as part of the startup scripts, you end up with a very predictable set of constraints (process id, system time, memory layout, ...).

      While it may take a lot of raw processing power to compute the tables, you may only have to do it once. So, access to a bunch of high performance computers with good GPU's and a week or two of waiting may be all that's needed. Say, a few computers optimized for bitcoin mining. Or an attacker could just rent a botnet for a say or two.

      Even if it's only "session keys" that expire after a few minutes. The encrypted data can be stored and decrypted later. With any luck, the session contains a few passwords or other sensitive information that are valid much longer.

      You see, there is no "reasonable" security. It either works, or it doesn't.

      "I know what i'm doing! Look, what could possibly go wrong? All i have to pull this lever like so, and then press this button here like ArghhhhhaaAaAAAaaagraaaAAaa!!!"
[reply]
        You see, there is no "reasonable" security. It either works, or it doesn't.

        The 6-pin rim lock and 2 deadbolts on my front door can be defeated by a Challenger 2, but given the likely risks, they form "reasonable security".

        Overstatement of risk is as damaging as understatement.

        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.

        The start of some sanity?
[reply]

        A very predictable set of constraints and a few KB of salt.

[reply]

In Section Seekers of Perl Wisdom