fermat primes and dnssec-keygen bug?

[Chris Thompson]

On Mar 6 2012, Paul Wouters wrote:

>See part of the dicsussion Miek and I had at the golang group:
>
>http://code.google.com/p/go/issues/detail?can=2&start=0&num=100&q=&colspec=ID%20Status%20Stars%20Priority%20Owner%20Reporter%20Summary&groupby=&sort=&id=3161
>
>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
BEAAAA...

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