On Wed, Sep 21, 2011 at 2:29 AM, Vincent Hanquez wrote:

Hi Felipe,

it's good to see more Skein stuff. it's a great crypto hash and one of the few remaining candidate for SHA-3.

Have you seen the cryptohash package http://hackage.haskell.org/package/cryptohash ?

I always wanted to expose more skein operations specially the hmac function, but never came around to, and maybe it would be good to merge to avoid duplicating efforts ?

I'm aware of cryptohash. I just went through the lazy route of binding to the C library instead of implementing those UBI details =). It would be nice to merge and have everything on cryptohash though. And I guess that cryptohash may become faster than skein because the C library has some implementation details that are unneeded (e.g. it has a buffer, but hash/hash' are kind enough to only give full buffers to the libraries). Also, it seems that cryptohash's Skein is currently broken. The skein package comes with the "golden" KATs sent by the Skein team to the NIST, and passes everything. OTOH, cryptohash's Skein256/Skein512 do not agree with skein's Skein_256_256/Skein_512_512. I've attached a test suite that quickchecks if both implementations give the same answer. My hunch is that you are using the wrong constants, because the first test case (the empty string) already fails: 1) cryptohash and skein have the same implementation of Skein-256-256 FAILED *** Failed! skein: bc 27 63 f7 07 e2 62 b8 0e 03 13 79 15 43 a7 ab 0a 4b 6c d0 83 27 0a fb 2f ce 42 72 e1 bb 0a a9 cryptohash: 0b 04 10 3b 82 8c dd ae bc f5 92 ac 84 5e ca fd 58 87 f6 12 30 a7 55 40 6d 38 d8 53 76 e1 ae 08 (after 1 test): (none) 2) cryptohash and skein have the same implementation of Skein-512-512 FAILED *** Failed! skein: d3 f7 26 3a 09 83 7f 4c e5 c8 ef 70 a5 dd ff ac 7b 92 d6 c2 ac e5 a1 22 65 bd 5b 59 32 60 a3 ff 20 d8 b4 b4 c5 49 4e 94 54 48 b3 7a bb 1f c5 26 f6 b4 60 89 20 8f de 93 8d 7f 23 72 4c 4b df b7 cryptohash: 5a f6 8a 49 12 e0 a6 18 7a 00 49 47 a9 d2 a3 7d 7a 1f 08 73 f0 bd d9 dc 64 83 8e ce 60 da 55 35 c2 a5 5d 03 9b d5 8e 17 89 48 99 6b 7a 83 36 48 6e d9 69 c8 94 be 65 8e 47 d5 95 a5 a9 b8 6a 8b (after 1 test): (none) Cheers, =D -- Felipe.

On Wed, Sep 21, 2011 at 2:27 PM, Thomas DuBuisson wrote:

...

 The skein package comes with the "golden" KATs sent by the Skein team to NIST

Great! Care to add that to the crypto-api test code?

I don't really understand how the testing workflow works on the crypto-api package, but I confess that I didn't try hard enough to understand. I don't like the use of the test flag to conditionally expose Test.* modules. Given that we can't have a flag constraint in "build-depends", using those modules would basically break the skein package test suite by default. They would break even in my own box, since crypto-api is installed system-wide without the test flag. So, could we split those Test.* modules into a new package like crypto-api-tests? Then I could have in my .cabal: Library Build-depends: ... crypto-api ... Test-suite runtests Build-depends: ... crypto-api, crypto-api-tests ... and everything would beautifully work =). Cheers, -- Felipe.

On Wed, Sep 21, 2011 at 5:19 PM, Vincent Hanquez wrote:

...

Also, it seems that cryptohash's Skein is currently broken.  The skein package comes with the "golden" KATs sent by the Skein team to the NIST, and passes everything.  OTOH, cryptohash's Skein256/Skein512 do not agree with skein's Skein_256_256/Skein_512_512.  I've attached a test suite that quickchecks if both implementations give the same answer.  My hunch is that you are using the wrong constants, because the first test case (the empty string) already fails:

oops darn, thanks for reporting. i'll have a look at that ASAP; It used to work in the past, and i've copied some expected values from the original implementation in my small unit tests (which still pass :-/ ), so i'm a bit puzzle here.

Perhaps you have implemented some old version of Skein? I know they have changed the constants some times in the past. Alas, their paper (I have "skein1.3.pdf", is there an updated version?) actually has wrong test vectors. For example, they say that for "B.pack [0xFF]" the result should be "B.pack [0x0B, 0x98, 0xDC, ..., 0xD2]", while their own KAT says that the result should be "B.pack [0xA4, 0x7B, 0xE7, ..., 0x91]". Unfortunately, for the same input cryptohash's Skein256 says that the result should be "B.pack [0x42, 0xC8, 0x82, ..., 0xE8]" which is different from both =). I assume that the KATs included in the skein package have the "correct" results since those KATs were given to the NIST. Cheers, =) -- Felipe.