fermat primes and dnssec-keygen bug?

Chris Thompson cet1 at cam.ac.uk
Wed Mar 7 12:13:35 UTC 2012

On Mar 6 2012, Paul Wouters wrote:

>See part of the dicsussion Miek and I had at the golang group:
>The bug seems to be that dnssec-keygen upgraded the fermat prime that
>is used per default from F0 to F4, but did not change that "-e" would
>get you the next fermat number.

This is wrong (although I have seen the same thing stated in a number
of other places). When the default public exponent was changed from
3 to 2^16+1 (change 2088) the one selected by -e was changed from
2^16+1 to 2^30+3 ... *not* 2^32+1. And so it remains today.

As it happens, 2^30+3 is prime while of course 2^32+1 is not, although
that isn't really an issue.

I believe that the DNSKEY records (e.g. in a few TLDs) that do use
2^32+1 as the public exponent come from HSMs, not from dnssec-keygen.

In any case, there is no "bug" involved in any of this, other than
in validating code that cannot cope with large exponents.

>                               The result is that people who upgrade
>bind and don't notice this changed behaviour are not changing their
>scripts that explicitely use "-e".
>I would recommend that dnssec-keygen starts ignoring the "-e" parameter
>that everyone has put in their scripts to prevent exponent 3 keys, who
>are not getting keys with exponent 4294967296 + 1 (F5)
>Alternatively, if this is done on purpose, I guess we should all
>migrate the 64 bit machines :)
>You can detect these starts, as they start with BQE

And you will find that the ones generated by "dnssec-keygen -e" start

My personal opinion is that we should stop worrying about people
using buggy pre-2006 versions of OpenSSL and go back to using RSA
public exponents of 3 again most of the time. I notice that this
is what VeriSign do for the DNSKEY records in "com", "net" & "edu".

Chris Thompson
Email: cet1 at cam.ac.uk

More information about the bind-users mailing list