
SHA-3 Standard [pdf] - dchest
http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf
======
pshc
Whoa, finally! I've been oddly attached to Keccak's story over the years ever
since it won the contest. Glad to see SHA-3 finished.

Did NIST make any changes to the algorithm since? From what I can tell it
looks like they only made clarifications.

To celebrate, here's a hacked-up keccak-512 implementation in Rust:
[https://github.com/pshc/keccak](https://github.com/pshc/keccak) (I have yet
to check whether it's actually SHA-3.)

~~~
joeyh
I'm not clear either on whether anything substantial has changed since the
April 2014 draft. Would be good to have some authoratative hash values to test
libraries against.

Glad to see it sets c = 2d at least.

------
AceJohnny2
This was the result of the contest in 2012, commented by Bruce Schneier here:
[https://www.schneier.com/cgi-bin/mt/mt-
search.cgi?search=SHA...](https://www.schneier.com/cgi-bin/mt/mt-
search.cgi?search=SHA-3&__mode=tag&IncludeBlogs=2&limit=10&page=1)

------
dchest
Released today.

Here are responses to draft comments:
[https://www.federalregister.gov/articles/2015/08/05/2015-191...](https://www.federalregister.gov/articles/2015/08/05/2015-19181/announcing-
approval-of-federal-information-processing-standard-fips-202-sha-3-standard)

------
AceJohnny2
Anyone have a VHDL or Verilog implementation of this? :)

For that matter, I haven't looked at the algorithm. Is it readily
implementable in hardware?

~~~
zokier
There is a VHDL implementation of Keccak on their homepage:
[http://keccak.noekeon.org/files.html](http://keccak.noekeon.org/files.html)

------
e12e
"The KECCAK-p permutations were designed to be suitable as the main components
for a variety of cryptographic functions, including keyed functions for
authentication and/or encryption. The six SHA-3 functions can be considered as
modes of operation (modes) of the KECCAK-p[1600,24] permutation. In the
future, additional modes of this permutation or other KECCAK-p permutations
may be specified and approved in FIPS publications or in NIST Special
Publications. "

Aww. Is there any news on a standard (NIST, or just informal RFC) on an
authenticated encryption mode for KECCAK? I remember seeing a presentation of
KECCAK at passwords[1] -- and I thought that part looked the most fun ;-)

[1] [http://passwords12.at.ifi.uio.no/](http://passwords12.at.ifi.uio.no/)

~~~
pbsd
I don't know about NIST standardization, but you can see what the Keccak team
is planning with the Keyak and Ketje CAESAR candidates:

[http://keyak.noekeon.org/](http://keyak.noekeon.org/)

[http://ketje.noekeon.org/](http://ketje.noekeon.org/)

------
mykhal
recap:
[http://keccak.noekeon.org/fips202final.html](http://keccak.noekeon.org/fips202final.html)

------
mykhal
XOF, nice.. but what is the point of expanding SHAKE256 to e.g. 4096 bits, if
its security remains 256 bits ?

~~~
amluto
To derive 4096 bits of pseudorandom data from an input. For example, you could
derive 16 256-bit keys from one master secret.

------
infinity0
If I were the NSA, how would I backdoor this?

~~~
tedunangst
I would tell people new crypto can't be trusted, and they should stick with
proven standards like MD5.

~~~
Retr0spectrum
That's exactly what the NSA would say to get us to use a new, backdoored hash
function! /s

------
logicrime
For non-scientists, what does this mean? Is SHA-2 not good anymore? What
should I do?

~~~
tptacek
SHA-2 is fine, and in fact the more conservative choice right now. SHA-3
didn't happen because SHA-2 was threatened.

My current favorite conservative hash choice is SHA512/256, which is the SHA-2
that generates a 512-bit output but truncates it to 256. It gives you the same
length extension protection that is the most important feature of SHA-3, and
is available in most libraries already.

I have never recommended to anyone that they switch from SHA-2 to SHA-3. I'm
actually in "wait and see" mode about SHA-3; there are compelling other hashes
available if you want to be ultra-modern about which hash you use.

~~~
Perseids
> SHA-2 is fine, and in fact the more conservative choice right now. SHA-3
> didn't happen because SHA-2 was threatened.

To extend on that, shortly after SHA-1 fell, there was the very real threat
that the SHA-2 family would follow suit (they are conceptionally similar).
This worry brought NIST to hold the SHA-3 competition. Fortunately, the SHA-1
attacks did not turn out to be transferrable, so far, and consequently trust
in SHA-2 has substantially increased since. Still, NIST (rightly) followed
through with the initial idea of the contest and chose a hash function that
was as different from SHA-2 as possible (Keccak).

Thus, we have now two very high quality hash functions to our disposal. If you
need a _really_ conservative choice, hash the message _m_ as SHA512( _m_
)||SHA3-512( _m_ ) (the concatenation of the individual hashes). This
construction is collision resistant if at least one of them remains collision
resistant. (Pseudo randomness relies on the security of both hashes, though,
and hashing the whole message twice comes at a hefty performance hit.
Especially since SHA3-512 is veeery slow – blame it on the clueless tech media
attacking NIST for tweaking Keccak, ignoring even the authors who supported
NIST's decision.)

~~~
KMag
> This construction is collision resistant if at least one of them remains
> collision resistant

Please don't throw around well-defined terms. This isn't true.

What you mean is that "the work factor for finding a collision in the
concatenated pair is at least the max of finding a collision in either half of
the concatenation." That's a true statement.

On the other hand, collision resistance is a comparison between
2^(hash_length/2) and the work factor required to find a collision.
Concatenating the two outputs would only remain collision resistant if it
caused an exponential increase in the work factor to find a collision.

Since the SHA-512 output is the whole hash state, once you've found a SHA-512
collision, you can keep appending to the two collided documents and they'll
stay collided, so you can use this as a starting point for your SHA3-512
collision. So, even assuming no weaknesses, the work factor to find collisions
in your 1024-bit concatenated construction is 2^256 + 2^256, not 2^512, and
thus not collision resistant.

Note that some hash functions output only half of their state vector as the
final hash. If you built your construction out of two such hash functions, and
no weaknesses were found in either, then your proposed construction would be
collision resistant. However, as proposed, it's not collision resistant, even
if both underlying hash functions are collision resistant.

~~~
Perseids
> Note that some hash functions output only half of their state vector as the
> final hash. If you built your construction out of two such hash functions,
> and no weaknesses were found in either, then your proposed construction
> would be collision resistant.

Actually, as long as the hash functions are iterative, the whole construction
can never be significantly stronger than the best hash function, see [1].

> What you mean is that "the work factor for finding a collision in the
> concatenated pair is at least the max of finding a collision in either half
> of the concatenation." That's a true statement.

What I meant was "as long as it is infeasible _in practice_ to find a
collision in either of them, it is infeasible to find a collision in the
concatenation". Comparing the security of hash functions to random oracles
with the same output length only makes sense if the construction of the hash
function supposedly affords this security.

Conversely, I find it absurd to call the hash function that outputs the first
64 bits of SHA-1 collision resistant, because it requires at least 2^32 steps
to find a collision. It fits with the oracle definition, but gives you no
information about its real world security.

If you want to make precise statements, you can add the work factor to your
statement, e.g. "The first 512 output bits of SHAKE-256 afford preimage
resistance up to a work factor of up to 2^256".

[1] Antoine Joux. Multicollisions in Iterated Hash Functions. Application to
Cascaded Constructions. In Advances in Cryptology - CRYPTO 2004, volume 3152
of Lecture Notes in Computer Science, pages 306–316. Springer Berlin
Heidelberg, 2004.
[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.128...](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.128.8566&rep=rep1&type=pdf#page=318)

