1. 18
  1.  

  2. 2

    It seems to me that a complication in implementing such an attack is that the malicious RNG producing r must know the value of x and y (and other numbers it will be hashed with). I suppose if you had the executable of the program you were trying to exploit, you could see what memory locations x and y are placed in and have the RNG in your CPU fetch from those locations. But that exploit would only work for a limited amount of time. Once the developers release a new version, the compiler will probably put x and y in a completely different memory location. It certainly doesn’t seem worth it to insert such a backdoor at the hardware level.

    1. 1

      Yes. In the case of OpenBSD, and the assumed RDRAND backdoor, the rdrand instruction needs to find and read quite a bit of state, roll it backwards, and then hope that nothing random happens after the rdrand instruction (very unlikely).

      It’s less like H(x, y, z) where z is malicious and can peek at x and y. It’s H(x, y, z, a, b, c, d) where a, b, c, d all come after z.

      It’s an attack to think about, but fortunately I don’t think real world random number generators are easily vulnerable to it.

      1. 1

        It depends on the rate of change of the application’s entropy sources. You might get pretty good mileage out of a hardware attack on a particular /dev/random implementation. Attacks that dynamically determine the location of interesting kernel structures are fairly common.