fyi:

3599 (2.99 KB)

Paul, what exponent does the new key use? (I clicked on the public key

link, but I can't decode the base64 that easily...)

Paul Vixie wrote:

fyi:

My mail reader can sanitize HTML mail for me, but it was stymied by this one. What is it?

paul@vix.com (Paul Vixie) writes:

EARLY KEY ROLLOVER

---

In light of the recently announced OpenSSL security advisory: RSA Signature

Forgery (CVE-2006-4339), ISC has instigated an early rollover of the DLV Key

Signing Key (KSK). ISC reccomends reconfiguration of resolvers to use the DLV

KSK published on September 21, 2006.The old KSK will be retired on September 29, 2006.

---

see http://www.isc.org/ops/dlv/ for details, and note that there's now a

dlv-announce@ mailing list where folks can subscribe to learn about changes

to the dlv trust anchor.

_______________________________________________

dns-operations mailing list

dns-operations@lists.oarci.net

http://lists.oarci.net/mailman/listinfo/dns-operations

LarrySheldon@cox.net ("Laurence F. Sheldon, Jr.") writes:

My mail reader can sanitize HTML mail for me, but it was stymied by this

one. What is it?

included as above in even plainer text. my mail user-agent is emacs/mh-e, and

i as far as i know it could not generate or consume HTML mail even if i tried.

smb@cs.columbia.edu ("Steven M. Bellovin") wrote:

link, but I can't decode the base64 that easily...)

it was made with bind9's "dnssec-keygen" utility, using the -e option, so...

-e use large exponent (RSAMD5/RSASHA1 only)

...hopefully it's a good exponent. (every few years someone tries to explain

to me what a key exponent is, i think you steve have tried, but it just doesn't

stick.)

> Paul, what exponent does the new key use? (I clicked on the public key

> link, but I can't decode the base64 that easily...)it was made with bind9's "dnssec-keygen" utility, using the -e option, so...

-e use large exponent (RSAMD5/RSASHA1 only)

...hopefully it's a good exponent. (every few years someone tries to explain

to me what a key exponent is, i think you steve have tried, but it just doesn't

stick.)

It's pretty simple, if you don't want to understand why it works...

An RSA public key is the pair <e,n>; the private key is <d,n>. 'n' is the

famous product of two primes; e and d have a particular mathematical

relationship relative to those two primes. Broadly speaking, to generate

an RSA key, you find two large random primes, pick a more-or-less

arbitrary number for e, then use e and the two primes to calculate d. You

encrypt (or verify a signature) by calculating m^e mod n; you decrypt or

sign by calculating m^d mod n. The question is how arbitrary e can be.

From a mathematical perspective -- that is, making the equations work,

but not necessarily being secure -- e can be any odd number greater

than 1 that isn't a multiple of either prime, i.e., from 30,000 feet it

doesn't matter too much what you pick as long as it's odd. For years,

people have used 3, because it makes calculations that use e -- in

particular, signature verification -- much more efficient. RFC 3110, for

example, recommends 3 for DNSSEC. (Demonstration of that is left as an

exercise for the programmer.)

The problem, from my perspective, is that there have been a fair number of

attacks over the last several years that work only for low exponents such

as 3. All of them are special-case attacks; they rely on something else

being true. This latest one relies on an implementation bug and (roughly

speaking) the fact that many more numbers are cube roots than are, say,

65537th roots. Again, without going into details, it turns out that the

bug was easy to commit, arguably because of glitches in the standard, and

OpenSSL had it.

From my perspective, the deeper issue is that exponent 3 seems to be

fragile -- there have been so many different attacks on it that I suspect

we'll see many more. The only solution is to avoid the fragility. For

reasons I don't understand, 65537 is a frequently-recommended larger

exponent. NIST, in fact, requires that exponents be at least that large.

(Their suggested upper bound is more mysterious to me.) Anyway, 65537 is

reasonably efficient, though not nearly as good as 3. However, its

density of 0 bits helps a lot.

I tried figuring out just what -e does, but I ended up in a maze of twisty

little indirect function calls. But almost anything is going to be better

than 3. (I'm probably going to write a BCP on that.)

--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

Here's a fairly simple way to extract e:

$ for rdata in `dig dlv.isc.org. dnskey +short | awk '/257/ {print $4}'`; do echo $rdata | base64-decode | od -x -N4; done

0000000 0103 daa7

0000004

0000000 0301 0001

0000004

According to RFC2537 section 2, one of the KSKs of dlv.isc.org has e=3

and the other e=65537.

Not having committed the maths to heart, I might be able to explain it a

little differently.

Paul, I think you know the basic idea of what an exponent is. If you're

raising one number to a certain power (say, 127 to the fifth power),

then the power (5 in this example) is the exponent. 127^5 or 127**5 are

ways in various of the thousands of computer languages in existence for

expressing this. Many more languages just use functions.

This exponent is used to encrypt or sign, by taking numbers calculated

from what you want to encrypt, raising each one to the (exponent)th

power, and doing a number of other mathematical operations on them. It

matters what exponent you use. A bigger exponent isn't necessarily

better - remember, I haven't committed the maths to heart, but I do

recall Don Knuth's warning about choosing such numbers arbitrarily.

Steve has pointed out that 3 is recommended for DNSSEC, and NIST likes

65537 [2^16 + 1]. I don't have the maths to say why, so I'll leave it

at that.

Well, yes, I did just teach the RSA equations to my Network Security

class....

--Steven M. Bellovin, http://www.cs.columbia.edu/~smb