> 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.

Reply via email to