4 ms·

I would be comfortable using AES keys generated by my algorithm, even though I would prefer djb's proposed key erasure RNG I linked above. If the attacker mana

I would be comfortable using AES keys generated by my algorithm, even though I would prefer djb's proposed key erasure RNG I linked above. If the attacker managed to read the inner state of your RNG, you need to rotate all keys. There is no defense. The key erasure RNG only limits the damage. There is no "entropy fills back up", because it is not drained. There is "adding/replacing non-deterministic entropy", to mitigate how many keys are known to attacker if attacker had access to RNG inner state for limited amount of time. The entropy in /dev/random it not any better than the entropy in /dev/urandom, after the entropy pool has been initialized (step 1 in my algo) they are the same. /dev/random blocks until step 1 is complete. Step #1 is not complete in two cases: very early boot before the entropy pool has been read from storage and boot with no entropy pool stored, so need to gather entropy from I/O or hardware RNG like rdseed. For ssh, tls, wireguard etc, use urandom. For embedded devices: inject entropy pool value at manufacturing time. For VMs: inject entropy pool from host at first start / VM clone. The server never "runs out of entropy". Please watch the CCC presentation I linked above.

dragontamer 7y ago
> If the attacker managed to read the inner state of your RNG, you need to rotate all keys. That's not the attack I'm talking about. The inner-state of your RNG can be brute-forced with an attack of size 2^256 (assuming 256-bits of internal state to your RNG). If your 256-bit RNG creates 100x 256-bit AES-keys, the "common thread" is to attack the RNG. That's the most efficient way to get all 100x AES keys. Case in point: 1. Try state X 2. Did it generate the RNG Sequence you're attacking? If so, you're done. 3. If not, X = X+1. Go back to step #1 and loop. Simple brute-force attack against the state. That is to say, a 256-bit RNG only has "256-bits" of protection. Or to put it another way: the 100x AES Keys you've generated all have 256-bits of protection, max. ----------- Stick a TRUE Hardware random number generator with entropy guarantees (such as RDSEED) as your generator, and you're immune to this brute force attack. In theory, its a non-trivial difference. In practice, 256-bits of entropy is enough for most people, and no one is going to accomplish this brute force attack. Its not about "draining" entropy. Its about asking yourself how much entropy your application needs. I can IMAGINE people needing more than 256-bits of entropy in higher-security contexts.
- wolf550e 7y ago
  What? No, brute forcing 2^256 is not an option. We assume brute forcing 2^128 is not an option. If brute forcing 2^256 were an option, why would anyone use AES-256?
  - dragontamer 7y ago
    No. Its not an option in practice. But its the starting point for a research problem. * 100x different AES-256 keys generated by /dev/random would have 25,600 bits of entropy. (All 100x keys are independent, and would require an attack effort per key). * 100x different AES-256 keys generated by /dev/urandom would "only" have 256-bits of entropy. (/dev/urandom would be attacked, assuming /dev/urandom started with 256-bits of entropy in its pool, assuming /dev/urandom never got extra entropy in the 100x calls) You can't pretend that the two solutions to the problem are the same. At best, you can suggest that 256-bits of entropy is enough for practical purposes.
    - wolf550e 7y ago
      No, brute forcing 2^256 is not the starting point of anything. Again, after seeding with initial entropy, /dev/random and /dev/urandom are the same, /dev/random is not better entropy. Attacking a single 256 bit key is exactly as equally impossible as attacking a 256 bit RNG pool used to generate 100 keys. There is no actual scenario in which using hardware RNG to generate 100 keys would keep me safe while using a hardware RNG to initialize a deterministic RNG to generate 100 keys would lead to compromise. If your attacker model includes brute forcing 2^256, I can't help you. If you're trying to prove that Aleph-one is greater than Aleph-0, perhaps, but the number of atoms in the universe is less than Aleph-0, so it's irrelevant to cryptography or to information security. People who say "maybe an advance in math will break 2048 bit DHE" are at least theoretically correct. But no advance in math is going to break that RNG. If you can't trust that RNG, you can't send secrets using CTR, GCM, CHACHA, etc. because they will all break using that method.
      - dragontamer 7y ago

dragontamer 7y ago

> If the attacker managed to read the inner state of your RNG, you need to rotate all keys. That's not the attack I'm talking about. The inner-state of your RNG can be brute-forced with an attack of size 2^256 (assuming 256-bits of internal state to your RNG). If your 256-bit RNG creates 100x 256-bit AES-keys, the "common thread" is to attack the RNG. That's the most efficient way to get all 100x AES keys. Case in point: 1. Try state X 2. Did it generate the RNG Sequence you're attacking? If so, you're done. 3. If not, X = X+1. Go back to step #1 and loop. Simple brute-force attack against the state. That is to say, a 256-bit RNG only has "256-bits" of protection. Or to put it another way: the 100x AES Keys you've generated all have 256-bits of protection, max. ----------- Stick a TRUE Hardware random number generator with entropy guarantees (such as RDSEED) as your generator, and you're immune to this brute force attack. In theory, its a non-trivial difference. In practice, 256-bits of entropy is enough for most people, and no one is going to accomplish this brute force attack. Its not about "draining" entropy. Its about asking yourself how much entropy your application needs. I can IMAGINE people needing more than 256-bits of entropy in higher-security contexts.

wolf550e 7y ago
What? No, brute forcing 2^256 is not an option. We assume brute forcing 2^128 is not an option. If brute forcing 2^256 were an option, why would anyone use AES-256?
- dragontamer 7y ago
  No. Its not an option in practice. But its the starting point for a research problem. * 100x different AES-256 keys generated by /dev/random would have 25,600 bits of entropy. (All 100x keys are independent, and would require an attack effort per key). * 100x different AES-256 keys generated by /dev/urandom would "only" have 256-bits of entropy. (/dev/urandom would be attacked, assuming /dev/urandom started with 256-bits of entropy in its pool, assuming /dev/urandom never got extra entropy in the 100x calls) You can't pretend that the two solutions to the problem are the same. At best, you can suggest that 256-bits of entropy is enough for practical purposes.
  - wolf550e 7y ago
    No, brute forcing 2^256 is not the starting point of anything. Again, after seeding with initial entropy, /dev/random and /dev/urandom are the same, /dev/random is not better entropy. Attacking a single 256 bit key is exactly as equally impossible as attacking a 256 bit RNG pool used to generate 100 keys. There is no actual scenario in which using hardware RNG to generate 100 keys would keep me safe while using a hardware RNG to initialize a deterministic RNG to generate 100 keys would lead to compromise. If your attacker model includes brute forcing 2^256, I can't help you. If you're trying to prove that Aleph-one is greater than Aleph-0, perhaps, but the number of atoms in the universe is less than Aleph-0, so it's irrelevant to cryptography or to information security. People who say "maybe an advance in math will break 2048 bit DHE" are at least theoretically correct. But no advance in math is going to break that RNG. If you can't trust that RNG, you can't send secrets using CTR, GCM, CHACHA, etc. because they will all break using that method.
    - dragontamer 7y ago