Re: Security Engineering vs. Crypto Academics... (was strengthening /dev/urandom)

From: Patrick J. LoPresti (patl_at_users.sourceforge.net)
Date: 08/30/04

  • Next message: Jay Miller: "Re: Software-Only Pseudo-Random Numbers" 
    Date: 30 Aug 2004 16:45:12 -0400
To: "Theodore Y. Ts'o" <tytso@mit.edu>

    tytso@mit.edu (Theodore Y. Ts'o) writes:

    > No, my stance is that it is conceivable that at some point in the
    > future, someone may find collisions in SHA-1, or find some unknown
    > weakness in AES.

    Of course. But in that case, there is no reason to think that any of
    your manipulations will help!

    > Bull***. It can't possibly be shown, because we don't know enough
    > about crypto hashes to prove that they are secure in the first
    > place.

    Right, so we design functions with simply-stated properties and get
    lots and lots of smart people to try to disprove those properties.
    When those people all fail, we assume those properties hold, and we
    create simple-to-analyze systems whose security bounds can be proven
    based on those properties.

    Tacking on bizarre hand-rolled contortions does not help.

    For example, you mentioned replacing CTR mode (where C' = C+1) with
    something like C' = AES_K (C+1), because hey, who knows, maybe AES on
    consecutive values is "dangerous". Just two problems:

      1) Maybe iterated AES is actually more "dangerous". If AES is
         broken someday, who can say what form the break will take?

      2) What is the period of the PNRG with your revised counter mode?
         Hm, hard to say... Oops. At least CTR mode has easily analyzed
         and provable properties.

    We either assume the crypto is strong, or we do not. You seem to want
    to assume that the crypto might be weak, but not so weak that a few
    randomly-chosed contortions cannot save it. That is just silly,
    because your contortions are completely trivial compared to the design
    and analysis that went into the crypto in the first place.

    > Sure, "everybody knows" that truncation and XOR are the same for a
    > crypto hash function. But what if SHA has some kind of weakness?

    If SHA-1 has a weakness, it might apply as much, or more, to your XOR
    than to the truncation. Which is the whole point. If SHA-1 is
    strong, then truncation and XOR are (provably) equally good. If SHA-1
    has some unspecified weakness, then truncation and XOR are equally
    suspect. Either way, the XOR is pointless. Contortions like this
    make academics roll their eyes, not because they have unwarranted
    faith in the crypto, but because you have simply added complexity
    which makes analysis harder and does nothing to improve security.

    As long as I am ranting, here is what I want from /dev/{,u}random.

    /dev/random should give me real, information theoretic randomness as
    best it can based on conservative entropy estimates. If my machine
    has a hardware RNG with a known bandwidth of true random bits,
    /dev/random should use that, and probably ignore everything else (at
    least for entropy estimation).

    /dev/urandom should give me computational randomness based on strong
    crypto. Which means it should *block* until 128 bits of real
    randomness are available, then use that as a seed to drive a
    cryptographic-strength PRNG, preferably one with a widely-known and
    well-analysed design.

    The problem with the current /dev/urandom, as I see it, is that it
    never blocks. So it does not even give me computational randomness,
    because the seed might be very short. Or am I mistaken? Is there
    some way I can ensure that 128+ bits of "real" randomness (as
    determined by the entropy estimator) are being used for the
    /dev/urandom seed before I use the output?

     - Pat

  • Next message: Jay Miller: "Re: Software-Only Pseudo-Random Numbers"
    • Quantcast