'tsig-keygen' vs 'dnssec-keygen' - keysize
Stuart.Browne at team.neustar
Thu Sep 6 04:28:23 UTC 2018
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?
> -----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.
> > 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-
> 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-
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
More information about the bind-users