> > It's a universal keyed hash. Which you could use as a MAC, although, admittedly, > > it would be rather weak, which is why the tag is usually additionally encrypted. > > (which you could do externally, knowing that that's needed with GHASH) > > In any case, the crypto API's ghash does not do what you would expect of a GHASH. > > Well you could also use CRC-32 "as a MAC". That doesn't actually make it a MAC. > For one thing, CRC-32 is not keyed so I don't see how you would use it as a MAC? It's also not a cryptographic hash function as the output is biased. And it's true GHASH by itself is not a good MAC as you can recover the key, but that is easily solved by encrypting the tag with a one-time pad. Which, admittedly, is not included in the GHASH definition itself, which makes it rather oddball as it is also not a cryptographic hash function if the key is known. Then again, does it have to be? You just mentioned CRC-32 being supported by the crypto API, which is also not a cryptographic construct ... > > I guess my constructive suggestion *for the future* would be to be more careful > > with the naming. Don't give something a "known" name if it does not comply with > > the matching specification. Renaming stuff now is probably counter-productive, > > but putting some remarks somewhere (near the actual test vectors may work?) > > about implementation x not actually being known entity X would be nice. > > (Or even just some reference on where the test vectors came from!) > > > > I think a comment at the top of ghash-generic.c would be helpful, similar to the > one I wrote in nhpoly1305.c explaining that particular algorithm. > That sounds good as well. Although that would be the very last place I would (and did) look. > I'm surprised that you spent "days" debugging this, though. Since the API gives > you a single data stream, surely you would have had to check at some point how > the two formal arguments (AAD, ciphertext) were encoded into it? Were you just > passing the whole thing as the AAD or something? > Well, I had 2 possibilities: either everything was AAD or everything was ciphertext and neither got matching results ... and then you go off into trying various byte orders (9 our of 10 times it's just some endianess issue) and investigating potential bugs or limitations with the hardware itself. Of course this being crypto (and worse: only getting a tag out of the hardware at the very end) there's not a whole lot of information to work with. Basically only pass or fail. So yes, you quickly end up wasting a lot of time. I was NOT expecting ghash not to be GHASH as I know it, so it really was the last place to look. > Also to reiterate, it actually > does implement the GHASH algorithm correctly; the two formal parameters just > have to be encoded into the single data stream in a particular way. > I was about to make a remark stating that that's like saying a simple block XOR actually does implement AES counter mode (or ARC4 or Chacha20 or other random stream cipher) correctly as long as you generate the key stream data block in a particular way ... And then I came across a 2007 NIST specification that defines GHASH exactly as it's implemented here, namely with all the formatting left out, just GHASH(K, X). I've always known GHASH the way Wikipedia defines it (which comes from the original 2005 spec by McGrew and Viega), and that's also how our hardware implements it (i.e. it cannot do GHASH without the padding and the appended length word), but apparently there are different opinions out there ... so I stand corrected?! Regards, Pascal van Leeuwen Silicon IP Architect, Multi-Protocol Engines @ Verimatrix www.insidesecure.com
