Subject: [dnsext] draft-hoffman-dnssec-ecdsa-04

From: Miek Gieben <[email-masked]>
Date: Thu, 12 Apr 2012 09:14:21 +0200

Hello,

I've (re)read and implemented dnssec-ecdsa-04 in some code. During that
process I got some questions about it:

* Section 1: It says ECDSA is 20 times faster than RSA for signing
    and 5 times slower for validating. Shouldn't that require a reference?

* Section 4: How should I know that, x and y are of equal length?

* Section 4: Same question for r and s?

* Section 6: In the examples the privatekey file is shown. I haven't seen
    (or can't remember) this in any previous RFC specifing new algorithms
    for DNSKEYs. Also all other (DSA/RSA) .priv key files (as generated by BIND) 
    put the public key info in the .priv file, this one is an exception. Why?

    (My local elliptic curve documentation tells me the the private key consists
    out of the public key and a bigInt called D)

 Kind regards,

-- 
    Miek Gieben
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Francis Dupont <[email-masked]>
Date: Thu, 12 Apr 2012 13:17:18 +0200

>      and 5 times slower for validating. Shouldn't that require a reference?

=> I got the same differences at a lower level. BTW it seems both RSA and
ECDSA are very sensible to optimizations, the only thing which seems
unlikely is ECDSA signing not very faster than RSA signing, and ECDSA
validating faster than RSA.

>  * Section 4: How should I know that, x and y are of equal length?

=> as the public key is an opaque bit string I don't believe it matters
(and if you need to know the FIPS 186-3 should provide all details).

>  * Section 4: Same question for r and s?

=> in fact they can get leading zeros so not the length you expect.
IMHO the critical thing is (quoting the I-D):
   For P-256, each integer MUST be encoded as 32 octets; for
   P-384, each integer MUST each be encoded as 48 octets.

>  * Section 6: In the examples the privatekey file is shown. I
>    haven't seen (or can't remember) this in any previous RFC
>    specifing new algorithms for DNSKEYs. Also all other (DSA/RSA)
>    .priv key files (as generated by BIND) put the public key info
>    in the .priv file, this one is an exception. Why?

=> RFC 5933 (about GOST for DNSSEC, which is BTW another EC stuff).

>      (My local elliptic curve documentation tells me the the private
>      key consists out of the public key and a bigInt called D)

=> usually the public key is not considered as being a part of the
private key. I know some PKCS#11 devices which don't return the public
values when a RSA private key is looked up (note IMHO it is a bad
behavior). Here it is clear the private key is a bigInt.

Thanks

[email-masked]

PS: as far as I can see the example is hard to use to test code:
the only thing you can do is to validate old/expired signatures...
PPS: the crypto answer is Q = dG so the public key Q is trivial to
compute from the private key d and the curve parameters (which
includes the generator G).
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Miek Gieben <[email-masked]>
Date: Thu, 12 Apr 2012 13:25:09 +0200

[ Quoting <[email-masked]> in "Re: [dnsext] draft-hoffman-dnssec-e..." ]
>    P-384, each integer MUST each be encoded as 48 octets.

Ah, I completely missed that and now I know way: browser caching :(
Thanks.

> => RFC 5933 (about GOST for DNSSEC, which is BTW another EC stuff).

Ok, so we are stuck with that.

> includes the generator G).

Thanks for you answers.

 Regards,

---

From: Miek Gieben <[email-masked]>
Date: Thu, 12 Apr 2012 15:45:02 +0200

>    P-384, each integer MUST each be encoded as 48 octets.

I'm still an ECC noob (and I expect other people reading this might also lack
some crypto skills), but are those integers *always* 32 or 48 octets? I.e there
is never a need for padding?

Regards,
    Miek Gieben

---

From: Francis Dupont <[email-masked]>
Date: Fri, 13 Apr 2012 10:55:12 +0200

>  is never a need for padding?

=> they can get leading zeros so you can have to pad them to the required size.

Regards