Re: SHA-3 in libc

[Alistair Crooks <agc%pkgsrc.org@localhost>]

On Sun, Dec 14, 2014 at 06:47:37PM +0000, Taylor R Campbell wrote:
>    Date: Sat, 13 Dec 2014 14:10:11 +0000 (UTC)
>    From: christos%astron.com@localhost (Christos Zoulas)
> 
>    What would be the plan if the standard changes, and the functions are
>    made to compute different output? How are we going to recognize good
>    vs. broken versions of the functions.
> 
> Hmm...  What I had in mind was that nobody would actually use it until
> SHA-3 is finalized, and the symbols would be there only so that when
> 7.x(.y) comes out after it is finalized, packages built on a 7.0 host
> would be able to use it.

Well, regardless of whether SHA-3 is finalised, keccak could be added
quite easily.
 
> But on further reflection I see that leaves plenty of screw cases, of
> people using applications on <7.x(.y) that were developed with
> >=7.x(.y) who will get bad results.
> 
> Adding mandatory run-time logic to the API to detect whether it's
> finalized would be a bad idea, so I'll just hold off on this until
> then, and anyone who wants to use SHA-3 in applications on 7 once it
> is finalized can copy & paste it (it's a relatively small amount of
> code, a few hundred lines).

The review period of FIPS-202 is over:

	http://csrc.nist.gov/groups/ST/hash/sha-3/fips-202-public-comments-aug2014.html

(comments had to be in by August 26, 2014).

Anyway, given how far along the review process for draft FIPS 202 is,
I'd be surprised to see any issues right now.  And, even if SHA-3 is
changed in the future, keccak could be added right now.

Regards,
Alistair