> From: Sid Shetye [mailto:sid...@outlook.com] > > Edward, compressibility as a PRNG test isn't that reliable. It can weed out > really bad PRNGs but RNGs need to protect against predictability.
I agree. The compression test is kind of primitive, but it's easy and successful at detecting the most obvious faults. It should be only one of many tests for statistical analysis of RNG data. I looked at diehard, and dieharder, and the NIST sts. One of these should be usable; I just haven't settled on an answer yet. Compression is trivially easy and gets some results on the most offensive behaviors. Also, even with a really good statistical analysis suite, you're not going to be able to detect every problem. The output of a PRNG with no seed will pass every statistical test you can possibly imagine. > For example: compressibility would pass for the previously circulated digest > RNG with same seed code but its a horrible failure from a RNGs perspective. This is the point I was illustrating above. The output of a PRNG with no seed will pass every statistical test you can possibly imagine. This is unfortunately impossible to detect. For example, you could seed your PRNG with system time, and it will always pass the best statistical analysis, yet it would be immediately crackable by any attacker. > For your CBCrypt requirement, instead to imposing a new weakening > requirement on RNGs (repeatability), why won't you use digests as the > primitive construct? There is no weakening happening in CBCrypt. CBCrypt is not a random number generator, so it's ok for its output to be deterministic and repeatable. In fact that's a design requirement. The whole point of CBCrypt is to deterministically convert a password into a public/private keypair, so you can authenticate to a server without sending your password. There have been some things in the past, which send a hash of the user's password to the server instead of sending the user's password, but that's bad crypto for two reasons: (1) you need to apply a rate limiting workfactor first such as pbkdf2/bcrypt/scrypt, because any attacker who finds an un-salted un-stretched hash of your password can simply start brute force guessing until they find a password whose hash matches the hash in question, and then they know your password. To counter, you need to rate-limit any attacker's attempt at brute force guessing. (2) Suppose the communication channel gets compromised (such as heartbleed etc). Any attacker who finds your hash can impersonate you because you're effectively using a hash of your password *as* your password. So if they find your pass hash, then they can impersonate you without needing to know your password. If instead, you apply a rate limiting hashing function to generate a public/private keypair instead of generating a simple hash... Then you're able to do asymmetric authentication techniques which keep your password private, and also cannot be impersonated without the attacker working forward through the rate-limiting function to guess the password. The present state of the art (prior to CBCrypt) is that users send their passwords to the server, and then the server uses bcrypt or scrypt to hash and check, and store the salted/stretched hash on disk. CBCrypt instead applies scrypt client-side, so that work is already done *before* sending to the server.