4 ms·

I'm probably going to show my ignorance of RNGs here, but if we know the machine, the algorithm used, and the time the key was generated, doesnt that limit the

I'm probably going to show my ignorance of RNGs here, but if we know the machine, the algorithm used, and the time the key was generated, doesnt that limit the number of possible choices? Could we check when the file was encrypted and brute force the possible keys?

varenc 9y ago
This would work if time was the only thing that went into the seed for the random number generator. Relatively insecure generators do use time, but nothing serious should be using it exclusively. Here's the remark from the Windows Crypto API on how they create the seed. To form the seed for the random number generator, a calling application supplies bits it might have—for instance, mouse or keyboard timing input—that are then combined with both the stored seed and various system data and user data such as the process ID and thread ID, the system clock, the system time, the system counter, memory status, free disk clusters, the hashed user environment block. This result is used to seed the pseudorandom number generator (PRNG). details: https://msdn.microsoft.com/en-us/library/windows/desktop/aa379942(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...
- mikeash 9y ago
  It depends on how granular your clock is, too. If you seed with a number of seconds then it's pretty easy to brute-force that. If you seed with nanoseconds it'll be a lot harder.
  - kaoD 9y ago
    > If you seed with nanoseconds it'll be a lot harder. Not really. Or rather, a lot of zero is zero.
    - mikeash 9y ago
      Can you elaborate? I'm assuming the nanosecond-precision lock seeding the RNG is based on wall clock time or system uptime, so as long as the clock is actually that precise (and why not, when the base clock signal in the CPU is ticking a couple of times each nanosecond) you'll get that many digits.
      - kaoD 9y ago
        Nanosecond resolution multiplies the brute force effort by 10^9, which is negligible.

varenc 9y ago

This would work if time was the only thing that went into the seed for the random number generator. Relatively insecure generators do use time, but nothing serious should be using it exclusively. Here's the remark from the Windows Crypto API on how they create the seed. To form the seed for the random number generator, a calling application supplies bits it might have—for instance, mouse or keyboard timing input—that are then combined with both the stored seed and various system data and user data such as the process ID and thread ID, the system clock, the system time, the system counter, memory status, free disk clusters, the hashed user environment block. This result is used to seed the pseudorandom number generator (PRNG). details: https://msdn.microsoft.com/en-us/library/windows/desktop/aa379942(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...

mikeash 9y ago
It depends on how granular your clock is, too. If you seed with a number of seconds then it's pretty easy to brute-force that. If you seed with nanoseconds it'll be a lot harder.
- kaoD 9y ago
  > If you seed with nanoseconds it'll be a lot harder. Not really. Or rather, a lot of zero is zero.
  - mikeash 9y ago
    Can you elaborate? I'm assuming the nanosecond-precision lock seeding the RNG is based on wall clock time or system uptime, so as long as the clock is actually that precise (and why not, when the base clock signal in the CPU is ticking a couple of times each nanosecond) you'll get that many digits.
    - kaoD 9y ago
      Nanosecond resolution multiplies the brute force effort by 10^9, which is negligible.