'tsig-keygen' vs 'dnssec-keygen' - keysize

[Browne, Stuart]

Ok, then here goes me in my not-really-understanding HMAC properly.

When using 'dnssec-keygen -a hmac-md5 -b 512 -n HOST some-name' (512 being the max keysize lited in 'dnssec-keygen -h'), we end up with an 88 byte string of secret data.

When using 'tsig-keygen -a hmac-md5 some-name', we end up with a 24 bytes string of secret data.

Is there no cryptographic difference between the short/long output?

For the sha* types, the length of the secret material appears to be the same, but not for the md5.

Sadly, I have some software that requires the use of hmac-md5's for tsigs that I cannot work around at this time.

Incidentally using bind-9.11 I was unable to use the truncation method you mentioned below (not that I really want to). Is it a 9.12 onwards thing?

Stuart

> -----Original Message-----
> From: Mark Andrews [mailto:marka at isc.org]
> Sent: Wednesday, 5 September 2018 3:40 PM
> To: Browne, Stuart
> Cc: bind-users at lists.isc.org
> Subject: Re: 'tsig-keygen' vs 'dnssec-keygen' - keysize
> 
> 
> > On 5 Sep 2018, at 2:50 pm, Browne, Stuart via bind-users <bind-
> users at lists.isc.org> wrote:
> >
> > Was adding in some new internal functionality and noted that the 'tsig-
> keygen' tool doesn’t
> > give the ability to alter the keysize like dnssec-keygen does for
> generating HMAC based tsig keys.
> >
> > I also noticed that in 9.13, dnssec-keygen will no longer be able to
> generate HMAC tsig's, so
> > I'm wondering if the ability to manipulate the tsig keysize will be
> implemented in tsig-keygen
> > to maintain compatibility, or if there is some work-around I've not
> found to be able to set this.
> 
> There is zero point in fiddling with the key sizes of hmacs.  It has no
> impact on the size
> of the HMAC in the TSIG records.  It has negligible impact on the size of
> named.conf, nor
> on the size of a database if we ever get around to storing tsig keys in a
> database, even
> with 100’s of millions of keys.
> 
> tsig-keygen generates maximal sized shared keys for the given algorithm
> which provides
> the largest possible search space for a brute force attack.
> 
> The hmac algorithm used impacts the size of the HMAC in the TSIG record.
> To generate
> truncated hmac append “-<bits>” e.g. -128 to the algorithm name.
> 
> Mark
> 
> > Stuart Browne
> > Neustar, Inc. / Sr Systems Admin
> > Level 8, 10 Queens Road, Melbourne, Australia VIC 3004
> > Office: +61.3.9866.3710
> > stuart.browne at team.neustar / home.neustar
> >
> > Follow Neustar: LinkedIn / Twitter
> >
> > Reduce your environmental footprint. Print only if necessary.
> >
> > The information contained in this email message is intended only for
> the use of the recipient(s) named above and may contain confidential
> and/or privileged information. If you are not the intended recipient you
> have received this email message in error and any review, dissemination,
> distribution, or copying of this message is strictly prohibited. If you
> have received this communication in error, please notify us immediately
> and delete the original message.
> >
> >
> > _______________________________________________
> > Please visit https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__lists.isc.org_mailman_listinfo_bind-
> 2Dusers&d=DwIFaQ&c=MOptNlVtIETeDALC_lULrw&r=udvvbouEjrWNUMab5xo_vLbUE6LRG
> u5fmxLhrDvVJS8&m=VyYL0iKiBdsY762FkEGyvUr-
> FH5Z6vWh3Zs7JPh9g_U&s=SC48Vs3lYvTTgdQlXnms2TK6qbKVLErW2vjypiecjek&e= to
> unsubscribe from this list
> >
> > bind-users mailing list
> > bind-users at lists.isc.org
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__lists.isc.org_mailman_listinfo_bind-
> 2Dusers&d=DwIFaQ&c=MOptNlVtIETeDALC_lULrw&r=udvvbouEjrWNUMab5xo_vLbUE6LRG
> u5fmxLhrDvVJS8&m=VyYL0iKiBdsY762FkEGyvUr-
> FH5Z6vWh3Zs7JPh9g_U&s=SC48Vs3lYvTTgdQlXnms2TK6qbKVLErW2vjypiecjek&e=
> 
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742              INTERNET: marka at isc.org