3 ms·

This attack would not have been avoided if the output of the RNG had been hashed, since the attack essentially brute-forces all entropy in the system (i.e. the

This attack would not have been avoided if the output of the RNG had been hashed, since the attack essentially brute-forces all entropy in the system (i.e. the timestamp jitter). No amount of deterministic post-processing can save you if you have no entropy to begin with. You also don't build backdoors by building bad products.

rainsford 9y ago
Unless I'm missing something, I think hashing actually would make this attack much harder to pull off. The attack works by AES decrypting the generator output, which gives you V (the state) XOR T (the timestamp). If you can guess the timestamp, you have V and can now run the generator both forwards and backwards as long as you can keep guessing the timestamp for each output. If the generator output was hashed after being encrypted, it would not be possible to perform the decryption step of the attack. You could still perform a brute force attack by encrypting and then hashing, but now you're brute forcing both the state and the timestamp together (i.e. you have to guess V XOR T, then encrypt, hash, and validate your guess), which will likely be much more difficult if the generator has been running for some amount of time. Without being able to invert the encryption step, an attacker has to basically guess ALL previous timestamps rather than just the one associated with the current output. If the attacker is able to see the first few outputs, the attack would still work, but it would be much harder to just start at an arbitrary point in time. Edit: I still don't think the addition of a hashing step would make this a great generator design, but it would make it more resilient against this kind of attack.
- JoachimSchipper 9y ago
  You're right; but the conclusion would still be "this is horrifically broken". A passive attacker can get all random generated since boot, and any internal RNG calls are not secret (neither in theory, nor probably in practice.) One abstraction level up, hashing the output of a RNG is a bad countermeasure against a possibly-bad RNG. Good countermeasures including mixing the outputs of multiple RNGs and using protocols that don't require entropy.
  - jorangreef 9y ago
    "hashing the output of a RNG is a bad countermeasure against a possibly-bad RNG" Why? I would think it's a fair suggestion for defense in depth, especially if you need to expose the result as a nonce, and you don't want to leak anything else unwittingly. It's also a good idea if you're not sure whether the entropy is evenly distributed, which is where something like HKDF would also want to hash the entropy source. "using protocols that don't require entropy" That rules out most secure protocol handshakes.
    - wbl 9y ago
      You could just use a better RNG in the first place.
      - jorangreef 9y ago
        The point is that it's not XOR. You can use a better RNG and also hash entropy before exposing it as a nonce. Why throw out defense in depth?

rainsford 9y ago

Unless I'm missing something, I think hashing actually would make this attack much harder to pull off. The attack works by AES decrypting the generator output, which gives you V (the state) XOR T (the timestamp). If you can guess the timestamp, you have V and can now run the generator both forwards and backwards as long as you can keep guessing the timestamp for each output. If the generator output was hashed after being encrypted, it would not be possible to perform the decryption step of the attack. You could still perform a brute force attack by encrypting and then hashing, but now you're brute forcing both the state and the timestamp together (i.e. you have to guess V XOR T, then encrypt, hash, and validate your guess), which will likely be much more difficult if the generator has been running for some amount of time. Without being able to invert the encryption step, an attacker has to basically guess ALL previous timestamps rather than just the one associated with the current output. If the attacker is able to see the first few outputs, the attack would still work, but it would be much harder to just start at an arbitrary point in time. Edit: I still don't think the addition of a hashing step would make this a great generator design, but it would make it more resilient against this kind of attack.

JoachimSchipper 9y ago
You're right; but the conclusion would still be "this is horrifically broken". A passive attacker can get all random generated since boot, and any internal RNG calls are not secret (neither in theory, nor probably in practice.) One abstraction level up, hashing the output of a RNG is a bad countermeasure against a possibly-bad RNG. Good countermeasures including mixing the outputs of multiple RNGs and using protocols that don't require entropy.
- jorangreef 9y ago
  "hashing the output of a RNG is a bad countermeasure against a possibly-bad RNG" Why? I would think it's a fair suggestion for defense in depth, especially if you need to expose the result as a nonce, and you don't want to leak anything else unwittingly. It's also a good idea if you're not sure whether the entropy is evenly distributed, which is where something like HKDF would also want to hash the entropy source. "using protocols that don't require entropy" That rules out most secure protocol handshakes.
  - wbl 9y ago
    You could just use a better RNG in the first place.
    - jorangreef 9y ago
      The point is that it's not XOR. You can use a better RNG and also hash entropy before exposing it as a nonce. Why throw out defense in depth?