On 2014-01-14, at 18:04, George Michaelson <g...@algebras.org> wrote:

> If multiple independent entities sign, can't they elect to use shorter 
> algorithms?
> 
> I know 'short can be spoofed' is out there, but since there are now n * <512> 
> instead of 1 * 2048 is it not theoretically possible that at a cost of more 
> complexity, it can be demonstrated that as long as 1) the sigs are all 
> current 2) all the sig agree then the risk of n 512-bit signings is not 
> necessarily worse than one 2048 or 4096 bit signing, for the specific need we 
> have: proof of correctness. (n is unstated. 512 is a nonce. I have no idea 
> what the sweet spot of keysize and number of keys would be.)

If you sign the DNSKEY RRSet with N KSKs of the same size as the single current 
KSK, then presumably the expected time for one of them to be factored is N 
times lower than the expected time to factor a single key, given the same 
compute resources being available for each key in all cases.

This suggests that if multiple KSKs are used, the keys need to be longer, not 
shorter, if the same degree of protection is desired.

I'm assuming that what we're talking about is this:

. IN DNSKEY ZSK0
. IN DNSKEY ZSK1
. IN DNSKEY KSK0
. IN DNSKEY KSK1
. IN DNSKEY ...
. IN DNSKEY KSKn
. IN RRSIG DNSKEY KSK0
. IN RRSIG DNSKEY KSK1
. IN RRSIG DNSKEY ...
. IN RRSIG DNSKEY KSKn

(the size of which makes my hair stand on end) and not this:

. IN DNSKEY ZSK0
. IN DNSKEY ZSK1
. IN DNSKEY KSKnew
. IN RRSIG DNSKEY KSK

where KSKnew is some combinatorial function of {KSK0, KSK1, ..., KSKn} since 
this second approach still requires a single KSKnew to be prepared in a single 
place in order to generate the RRSIG, which would presumably be a non-goal of 
de-centralising control of the keys.

> I am not a cryptographer and do not play one on TV

Me neither.


Joe

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to