> By definition, if you can do better than brute
force, you need a
> better hash algorithm.
Actually, this was a slight overstatement. If you can do much better
than brute force, then. For password hashing, slight biases don't
really matter much - a work factor of 2^63 is about as good as a work
factor of 2^64, and most biases won't skew things by as much as a whole
bit.
Surprisingly, I've had students who had been
taught that ALL one-way
functions are completely and totally uncrackable.
I don't find that surprising - which fact I find somewhat depressing.
The only hash function that reveals nothing of its source data is one
that maps everything to the same value - and such a one fails
second-preimage resistance rather catastrophically. :-)
It will most likely be a nonsense string of
characters, rather than
the name of the user's canary, but it will work.
Not necessarily; for example,
if it contains NL or NUL characters,
Your brute force algorithm should be limited
to keyboardable
characters that are accepted by that OS.
Then there's no guarantee any but the actual password will work. (If
the hash function is good, approximately 1/N of any simply-defined set
of strings will work, where N is the number of postimages. I don't
know whether the hash functions actually used for passwords are known
to be good in this sense, though I suspect they actually are.)
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B