Dean Anderson wrote: > On Sun, 24 Aug 2008, Brian Dickson wrote: > > >> Dean Anderson wrote: >> >>> On Sun, 24 Aug 2008, Dean Anderson wrote: >>> >>> >>> >>>> Ok. But when you resign using arbitrary data controlled by the >>>> attacker, the private key can be obtained. [There is a crypto attack on >>>> rekeying] OOPS!!. Rekeying is out of the question for, say, .com, .net, >>>> etc. I guess you didn't know that. >>>> >>>> >>> Correction: The above should say there is a crypto attack on re-SIGNing. >>> ReKEYing is fine. Apologies for the confusion I just created. >>> >>> >> You say there is a crypto attack on re-signing. >> >> One using arbitrary data provided by the attacker - what is the >> "arbitrary" data, as opposed to some other kind of data? >> > > I don't think I can give the exact correct mathematics without using a > book--and I don't have my crypto library right now--so I'll try to > armwave a bit: > > Basically, if the attacker can pick a known-plaintext that corresponds > to a large-prime, they can use the result and the public key to obtain > the private key. This is consequence of modular arithmetic. I'm not > entirely certain from memory if the plaintext has to be prime or if it > can be a multiple of a prime. > >
What Dean describes is a general "attack" on PKI math, not on (re-)signing as DNSSEC (RFC4034) specifies for RRSIG. His theory is, if the attacker can arrange for the thing being signed to be a prime (or possibly even the product of two known primes), then it may be possible to recover the key used for signing, based on the signature. The question is, is it possible for an attacker to arrange for the thing being signed to be a prime, or some arbitrary value? No. There is no way to deterministically cause a known value to be used for what gets signed. Here's why: signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) But: RRSIG_RDATA includes the expiry and incept date - chosen by the signer, not the attacker. Even worse, the contents of RR(1) are a DS record, which is itself a digest of a DNSKEY record. The DNSKEY record includes a few fields which are mostly 0's (7/8, 7/8, 6/8 on three octets). The DS may be provided by the operator of the subordinate zone, or built by the parent operator, most likely the latter. So, there are 20 bits of zeros which get used in a digest, and 64 bits not under the attackers control, plus 16 bits of fixed value (Type Covered), an 8-bit fixed value field (Labels), plus the Signer's Name is also a fixed value. That's way more than 88 bits of data not under the control of the attacker. For perspective, 2^88 is the number of seconds in the age of the universe, estimated. To suggest that appending a digest value to that, and having the result be a prime, does not strike me as a serious threat to key recovery by an attacker. So, I would say that in all likelihood, re-signing with the *same* key is perfectly safe. (The inclusion of the signature's own timestamp values in the data being signed was, IMHO, genius.) Brian P.S. This does not, however, mean that there does not exist some other key recovery risk; if anyone knows of one, please detail it or give a reference. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
