> You hit the nail on the head. I should have thought to test shorter
> keys. I was using a 32-byte key. Just tested with 28 bytes and the
> problem does indeed go away with the shorter key.

Excellent.

> > If that's the problem, I can give you a workaround for the long key.
> 
> I would very much appreciate that!

Okay, the problem was, according to the HMAC specification, if your secret
is longer than the hash block length of the algorithm (which is 64 bytes
for SHA1 through SHA256, and 128 bytes for SHA384 and SHA512), then the
secret is supposed to be hashed, and the resulting digest is used as
the secret instead.

BIND had a bug in it causing this hashing of the secret to occur when the
original secret was longer than the *digest* length of the algorithm--not
the hash block length--and the digest length is shorter.  (As previously
mentioned, it's 28 bytes for SHA224.)  So, any key between 29 and 64 bytes
in length was being hashed to a smaller size before being used to generate
a message authentication code--but shouldn't have been.  Only keys that
were 65 bytes or longer should've been.

So, what you can do is take the key and hash it yourself, creating a
pre-shortened version that will work consistently on all platforms.  It
will also interoperate cleanly with older versions of BIND that still
have the bug and are still using the unhashed version of the key.

On my Linux system, the command for that is:

$ echo -n <oldsecret> | base64 -d | openssl dgst -sha224 -binary | base64

This converts a 32-byte key ("dqzfsrYoMfq+OMBl5XCKfF4KTkwV9m9k9HKlhCi6kFE=",
for example) into a 28-byte key ("yfH3uKZT4eYLXAEb9KtUfnuyzoedJ2sqUe39Xw==")
which, in use, will produce the exact same MAC as BIND9 would've done
before the bug was fixed.

On BSD, the command is:

$ echo -n <oldsecret> | b64decode -r | openssl dgst -sha1 -binary | \
        b64encode - | sed -n 2p

As of BIND 9.7.0rc2, we'll be providing a new tool (isc-hmac-fixup) to do
this for you, regardless of platform.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to