From: Thomas Pornin on
According to Tom St Denis <tom(a)iahu.ca>:
> You really need vectors for
>
> 1. the 0 length message
> 2. the 55 [or 111] byte message
> 3. the 56 [or 112] byte message
> 4. the 57 [or 113] byte message
> 5. A few between [e.g. 16 bytes with order swapped to promote
> catching endianess errors]

For that matter, the NIST was much more thorough in their requirements
for SHA-3 candidates. They provided (under an easy-to-process format)
sample messages to hash for all sizes from 0 to 2047 bits, then for a
number of lengths from 2048 to 34304, and also requested the hash for a
2^30-bytes long message. Moreover, since NIST specified a common API for
the reference code to be submitted with each candidate, they provided
some application code to actually compute all those test vectors.

The documentation and source code for that can be downloaded from:
http://csrc.nist.gov/groups/ST/hash/sha-3/Submission_Reqs/test_vectors.html

Now, for a SHA-2 implementation, all that remains to do is to write some
wrapper which follows the NIST API, and find another implementation
which also uses said API. For that, may I suggest sphlib:
http://www.crypto-hash.fr/modules/wfdownloads/singlefile.php?cid=13&lid=10
which includes implementations for SHA-2 functions _and_ wrappers which
implement the NIST API for SHA-3.


--Thomas Pornin
From: Wolfgang Ehrhardt on
On Tue, 30 Mar 2010 17:23:30 -0400, "David T. Ashley"
<dashley(a)gmail.com> wrote:

>I implemented FIPS 180-3 (I'm not really a competent Windows programmer).
>
>You can find the executable here:
>
>http://www.s-512.com/filehash.exe
>
>and the source code here:
>
>http://www.s-512.com/filehash.zip
>
>Anyway, I will review the code carefully in the next few days, and do some
>unit tests (boundary cases, etc.).
>
>But if anyone wants to beat it around and tell me if it seems correct ...
>I'd be grateful.

The description on you web page seems (due to some fuzzyness of spoken
language) to confuse collision resistance with (second) preimage
resistance:

"The mathematics of a birthday attack suggest that 1.6�10^74 guesses
would be required to obtain even a one-in-a-million probability of
finding a file with the same cryptographic hash.

Using 10 billion computers that each could calculate 10,000 hashes per
second (both very optimistic assumptions), to get a one-in-a-million
probability of finding another file with the same SHA-512 hash would
require 5�10^52 years."


--
Do not use the e-mail address from the header! You can get a
valid address from http://home.netsurf.de/wolfgang.ehrhardt
(Free open source Crypto, CRC/Hash, MPArith for Pascal/Delphi)
From: Wolfgang Ehrhardt on
On 31 Mar 2010 18:58:38 GMT, Thomas Pornin <pornin(a)bolet.org> wrote:

>According to Tom St Denis <tom(a)iahu.ca>:
>> You really need vectors for
>>
>> 1. the 0 length message
>> 2. the 55 [or 111] byte message
>> 3. the 56 [or 112] byte message
>> 4. the 57 [or 113] byte message
>> 5. A few between [e.g. 16 bytes with order swapped to promote
>> catching endianess errors]
>
>For that matter, the NIST was much more thorough in their requirements
>for SHA-3 candidates. They provided (under an easy-to-process format)
>sample messages to hash for all sizes from 0 to 2047 bits, then for a
>number of lengths from 2048 to 34304, and also requested the hash for a
>2^30-bytes long message. Moreover, since NIST specified a common API for
>the reference code to be submitted with each candidate, they provided
>some application code to actually compute all those test vectors.
>
>The documentation and source code for that can be downloaded from:
> http://csrc.nist.gov/groups/ST/hash/sha-3/Submission_Reqs/test_vectors.html
>
>Now, for a SHA-2 implementation, all that remains to do is to write some
>wrapper which follows the NIST API, and find another implementation
>which also uses said API. For that, may I suggest sphlib:
> http://www.crypto-hash.fr/modules/wfdownloads/singlefile.php?cid=13&lid=10
>which includes implementations for SHA-2 functions _and_ wrappers which
>implement the NIST API for SHA-3.
>
Even for SHA1/2 the algorithms are defined for messages with arbitrary
bit lengths up to specific limits, but most published test vectors or
source codes only deal with byte/octet oriented messages. An exception
is RFC 4634 with reference code for SHA1, SHA256, SHA512, and HMAC.

--
Do not use the e-mail address from the header! You can get a
valid address from http://home.netsurf.de/wolfgang.ehrhardt
(Free open source Crypto, CRC/Hash, MPArith for Pascal/Delphi)
From: Wolfgang Ehrhardt on
On 31 Mar 2010 18:58:38 GMT, Thomas Pornin <pornin(a)bolet.org> wrote:
>The documentation and source code for that can be downloaded from:
> http://csrc.nist.gov/groups/ST/hash/sha-3/Submission_Reqs/test_vectors.html
>
I just downloaded your source and tested my own bit api functions with
your test cases from the test_sha1/2/3.c files. Are the test vectors
other than the well-known "abc" etc from other sources or do you have
calculated them for reference and/or regression tests?

From: Thomas Pornin on
According to Wolfgang Ehrhardt <WE(a)completely.invalid>:
> I just downloaded your source and tested my own bit api functions with
> your test cases from the test_sha1/2/3.c files. Are the test vectors
> other than the well-known "abc" etc from other sources or do you have
> calculated them for reference and/or regression tests?

The test vectors I use are from FIPS 180-3 (the "abc" etc) and from RFC
4634 (some of them have a length not multiple of 8). Note that only my C
code can deal with inputs which are not an integral number of bytes; my
Java code cannot do that (yet).


--Thomas Pornin