DNSSEC will eventually generate Identical Key ID's

Warren Kumari warren at kumari.net
Wed Sep 12 20:46:36 UTC 2018

On Mon, Sep 10, 2018 at 4:45 AM Ray Bellis <ray at isc.org> wrote:

> On 09/09/2018 18:51, Mark Elkins wrote:
> > Just for the record, although I do look from a curiosity point of view
> > for Identical Key ID's once every few month - I've never seen them -
> > until now.
> >
> > Now I have them - generated by BIND within a few days of each other...
> >
> > I've been running DNSSEC for 7 years and have around 400 DNSSEC keys for
> > 133 signed Domains.
> > I'm a smallish Registrar for ZA domains.
> >
> > Never assume a KeyID is unique.  :-)
> It's inevitable that they won't be.
> With only a 16 bit key tag space (and in 2016 Roy Arends discovered that
> the effective space is only 15 bits) then due to the birthday collision
> paradox you only need of the order of sqrt(32k) different keys to get a
> 50% chance of a collision.
This reminds me of some interesting (well, interesting to me :-)) related
research Ben Laurie and I did around that time -- while looking at the
distribution of generated keys I noticed that OpenSSL / GnuTLS generate a
different distribution than e.g mbedTLS.
OpenSSL / GnuTLS optimize the generation of primes by setting the least
significant bits (fair, they have to be odd to be primes :-)) but also
clear the most significant bits of both P and Q (to ensure that the product
of P & Q do not overflow) -- this results in a key with less bits of
"security" than most would expect...


> Ray
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20180912/ec9c5873/attachment-0001.html>

More information about the bind-users mailing list