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