

The Skein Hash Function - bdfh42
http://www.schneier.com/blog/archives/2008/10/the_skein_hash.html?1

======
tptacek
The nut of this story: use SHA256 until NIST selects a "winner" in a couple
years. Schneier's team submission will be competing with submissions from
better-regarded cryptographers, and everything submitted to this contest is
unusually liable to be broken due to the competition.

Just so you know, you're reading about Skein because Schneier has an extremely
popular blog and is a well-known personality. He is less well-established as a
credible cryptographic researcher, as a Google Scholar search will establish.
He has a smart team, and his last NIST submission (Twofish) was an AES
finalist, but you'd get looked at funny if you were caught using Twofish in
2008.

~~~
Tichy
Is Twofish broken, or is the reason to look funny at it's users simply that
they should use AES because it is the standard?

~~~
tptacek
None of the AES finalists have been "broken", and all of them (except maybe I
think Serpent?) have had cryptanalytic results published in the literature. It
is indeed because AES is the standard --- everybody uses it, there are many
good-quality implementations, and everybody knows _how_ to use it.

It's all kind of a moot point. If you're typing the name of a cipher into your
code, you're doing it wrong, and you'll pay down the road when you get
pentested.

------
liuliu
I'd like to see how it goes. Among some of the submissions I viewed, it is the
fastest one which make it very practical to replace now file digest method.
But I do not want to adopt the method now as it is not be widely accepted yet.
As there are other interest algorithms out there (more than using block
cipher) like using properties of log func. From my own perspective, I do
prefer different ideas.

~~~
tptacek
Check out:

<http://cr.yp.to/hash.html>

The cipher DAG paper is pretty awesome. I want to make prints and hang them on
my wall.

------
jotto
This function is purportedly quite fast, but I thought slower hashing
functions were more secure because they take longer to build tables from?

~~~
tptacek
A secure hash function is a cryptographic primitive. Its goal is to resist
collisions, particularly preimages (predictable collisions), while being _as
fast as possible_. To steal Schneier's words, hash functions are the glue that
binds most cryptosystems (like SSL/TLS or PGP).

A password storage function is a cryptosystem built out of crypto primitives.
The primitives are designed to be fast, but the cryptosystem should be slow.
One of the goals of a password storage function is to find a reasonable,
flexible way to slow down fast crypto primitives.

So the problem here is just terminology; you're conflating password storage
functions with hash functions.

And now you have another perspective on why "salted SHA256" is an evil
password storage function: it's simply using a raw hash function, rather than
building a password storage function out of them.

Also: you can't really "build tables" out of any password storage function
with a nonce ("salt"); defeating "tables" is as simple as adding a public
random number to each password. I'm writing this because it's worth
remembering that "building tables" is just one of many attacks against a
password storage function, and it is not the most important one.

