On Mon, November 2, 2015 8:58 pm, Yoav Nir wrote: > >> On 3 Nov 2015, at 1:33 PM, Tero Kivinen <[email protected]> wrote: >> >> Yoav Nir writes: >>> There is 1 for âRSA Digital Signatureâ and you can encode any hash >>> function the you would like, but for ECDSA there is: >>> 9 - ECDSA with SHA-256 on the P-256 curve >>> 10 - ECDSA with SHA-384 on the P-384 curve >>> 11 - ECDSA with SHA-512 on the P-521 curve >> >> Also number 3 DSS Digital Signature uses a SHA-1 hash.... >> >>> So unless you go by RFC 7427, you canât mix and match. >> >> So everybody should move to use that :-)
Yes, they should! Note that the repository uses a definite article (and we all know which curves the authors were referring to). So you can't do #9 with the brainpoolp256 curve, which is sub-optimal. > It could work for DSA. ECDSA with P-256 gets as input a 256-bit number. So > you couldnât fit the output of SHA-384 in there. It does work the other > way around (SHA-256 and P-384), but Iâm not sure whether that is any > more secure than SHA-256 with P-256. That's why X9.62 specifies using the left-most length of prime bits when the digest is larger than the length of the prime. It does work. Technically you can use ecdsa-with-SHA384 and "the P-256 curve", why you would want to is a different story. Odd fact: the WAPI protocol (Chinese wireless encryption and authentication protocol) uses SHA-256 with a special Chinese government-specified curve based on a 192-bit prime and doesn't follow X9.62. It uses the entire 256 bit digest to calculate the signature on the 192-bit curve. The 256-bit digest does "fit" since the math is all mod p. The result (r,s) is properly formed but s will be different from a standard ECDSA signature. Dan. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
