Mailing List Archive

On Sat, 16 Apr 2005 11:22 am, Brad Hards wrote:
> Has anyone tested HMAC with SHA384 and SHA512?
>
> I've tried the test vectors in
> http://www.ietf.org/internet-drafts/draft-nystrom-smime-hmac-sha-00.txt
> and they work for SHA-256, but almost identical code fails for SHA-384 and
> SHA-512.
>
> I contacted Magnus Nystrom, and he asked:
> "Did you use blocksize = 128 for SHA-384 and SHA-512? It affects the key
> padding."
OK, I'm pretty confident that gcrypt is doing it wrong.

FIPS 180-2 section 5.1.2 says the blocksize is 128 bytes.

RFC2104 says that the padding should be blocksize.

src/md.c:prepare_macpads() is pretty much hardwired to 64byte blocks.
Similarly, md_open() and md_copy both malloc a fixed 128 bytes (for ipad and
opad).

I'm considering two options - an intrusive patch that adds a blocksize
function pointer to gcry_md_spec_t, and then working in terms of the
ctx->blocksize(), or alternatively a less intrusive, but much uglier special
casing (if algo == GCRY_MD_SHA384 || algo == GCRY_MD_SHA512). I'd prefer to
do the first, but the concern I have is that there might be external modules,
and if I change the size of gcry_md_spec_t, then they might break.

Thoughts? Help?

Brad

Hello Brad,

thanks for your research; it will be fixed one way or another.

Moritz

--
Moritz Schulte

On Wed, 20 Apr 2005 01:05 am, Moritz Schulte wrote:
> thanks for your research; it will be fixed one way or another.
Is there any thing else I can do for this? For example, write a test case?

Brad

On Tue, 19 Apr 2005 17:05:35 +0200, Moritz Schulte said:

> thanks for your research; it will be fixed one way or another.

Thanks for your work. However to include this into libgcrypt the FSf
requires a copyright assignment or a disclaimer. If you can do so,
please contact me by private mail.

Thanks,

Werner

On Tue, 19 Apr 2005 12:48:37 +1000, Brad Hards said:

> OK, I'm pretty confident that gcrypt is doing it wrong.

Very likley. At the time I implemented the HMAC thing the SHA-2
algorithms were not known.

> I'm considering two options - an intrusive patch that adds a blocksize
> function pointer to gcry_md_spec_t, and then working in terms of the

We can't do this because it breaks the ABI.

ctx-> blocksize(), or alternatively a less intrusive, but much uglier special
> casing (if algo == GCRY_MD_SHA384 || algo == GCRY_MD_SHA512). I'd prefer to
> do the first, but the concern I have is that there might be external modules,
Yes, we need to do this hack. Which also means that external modules
requiring a blocksize other that 64 can't be used.


Shalom-Salam,

Werner