On Tue, July 24, 2012 4:17 am, Johannes Merkle wrote: >> If the mapping between curve and hash function is fixed then I don't >> see what you mean by "not hash-independent but only curve-independent". >> Seems that there is nothing independent, it's all fixed. > > I have the impression that we misunderstand each other. The solution that > I propose is to define one new auth method > ECDSA_generic which indicates that > - the curve shall be taken from the certificate > - the hash function shall be the minimum SHA-1/2 function matching or > exceeding the security level of the curve.
So the signer says "ECDSA_generic" and the curve is determined from the subjectPublicKeyInfo and one infers the correct SHA-1/2 algorithm from the curve. OK, so if the curve is the 320-bit brainpool curve then we always use SHA-384. Got it. >> And there are 7 new brainpool curves so that's 7 new auth methods >> plus 4 new ones to deal with the non-EC version of DSA for a total >> of 11 new auth methods to go along with the existing 4. 15 different >> auth methods just for the digital signature standard! >> > Not with the approach I proposed: there is only one method ECDSA_generic. > > Note, that for DSA (on EC), it would also be sufficient to specify a new > auth method DSS_key_length_defined_hash > accompanied with the requirement to choose the hash function as the > smallest SHA-2 function meeting the minimum > requirements of FIPS-186-3. Well FIPS 186-3 specifically refers to SP 800-57 for "information about the selection of the appropriate (L,N) pair in accordance with a desired security strength for a given time period for the generation of digital signatures." And SP 800-57 says that, for example, to produce a signature valid "beyond 2030" it requires a minimum of 128 bits of strength (table 4) and that when performing digital signatures of 128 bits of security the valid hash functions are SHA-256, SHA-384, and SHA-512. You want to restrict such signatures to SHA-256 so it's not really meeting the requirements of FIPS 186-3. >> Yes, it is unfortunate. What's also unfortunate is that the 11 auth >> methods mentioned above (plus the 3 existing ECDSA auth methods) >> will probably have to be duplicated for SHA-3 thereby eating into this >> "scarce resource" of an 8-bit registry even further. > > We have the choice: Either spending many assignments out of the 256 > available, or to specify a generic auth method > deviating from the approach previously tken for ECDSA (but being in > accordance with the approach taken for DSA). But the "generic ECDSA" does not solve the problem with SHA-3. As you said above, "the hash function shall be the minimum SHA-1/2 function matching or exceeding the security level of the curve." So how do you support SHA-3? I guess we could assign a bit (clear=SHA-1/2, set = SHA-3) but that's getting pretty hackish. Or we could have 2 "generic ECDSA", one for SHA-1/2 and another for SHA-3. Yuck. If only this protocol was designed better.... Dan. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
