I don't know who needs to know this, but a cryptographic seed can safely generate about 700M times its size in secure random output. Meanwhile a Sequoia seed can generate a Redwood tree that is about 2.5B times its volume.
That doesn't sound right. I'm not sure what the usage limits would be now in light of sweet32, but it'd have to be much much lower.
-
-
AES is a PRP, not a PRF, so a PRNG based on AES-CTR won't generate collisions until the counter wraps after 2^128 encryptions without rekeying.
-
That's *definitely* not safe; with enough volume of output, the stream becomes statistically predictable. Blocks you haven't seen yet, become more and more likely. Take a look at the AES-CTR DRBG design and where it's limits are.
- 3 more replies
New conversation -
-
-
Take 512-bit seed S. Compute h(S||1) h(S||2) h(S||3)... and produce essentially any length of pseudo random string for a decent hash function hash function h().
-
That sounds a bit like HMAC_DRBG or HASH_DRBG; HMAC is considered better for some prediction resistance reasons. Either way, 3DES is a cipher, not a hash :)
End of conversation
New conversation -
-
-
The 785 GB limit is for when there's a 50% chance that at least one 64 bit block in CBC mode will match at least one other, which messes up a bunch of security assumptions behind CBC once that starts happening. For AES the blocksize is 128 bits, and it's exabyte limits instead
-
50% is way beyond the comfortable safety factor. For example the safety limit for AES-CTR DRBG is 2^35 bytes, universes of magnitude short of the 50% birthday bounds.
- 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.