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...

W





> 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
pants.
   ---maf
-------------- 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