-----Original Message----- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Yoav Nir Sent: Sunday, July 22, 2012 9:54 AM To: Tero Kivinen Cc: ipsec@ietf.org; Johannes Merkle; Dan Harkins Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec
> I don't know either, but I can guess. With RSA the hash is much smaller than > the signature (128-512 bits vs 1024-4096 > bits) so we use the PKCS#1 structure that also describes the hash. So you > don't need to specify the hash up front - > it's encoded in the signature itself. > > With ECDSA, the hashes are the same sizes as the signatures, so there's no > room within the signature to encode the > hash algorithm. You need to know what it is by some other means. A comment from the pedants-R-us gallery: well, you've come to the correct conclusion (there's no way to determine from an ECDSA signature the hash used to generate the signature), however the reasoning you used to get there is incorrect. The issue isn't the size of an ECDSA signature (for example, a signature based on the P256 curve is 512 bits long, and uses only 256 bits from the hash). Instead, the way RSA works allows recovery of the padded hash; we can take advantage of that to signify the hash method in the padding bits. In contrast, ECDSA does not allow the analogous operation; even if we padded the hash, we couldn't recover the padding anyways from the signature. We can certainly test if a specific hash value is the one that goes with the signature (that's what the signature verification operation is); however, it is infeasible to recover information about that value (for example, any bits that might signify padding). _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
