- From: Jim Schaad <ietf@augustcellars.com>
- Date: Mon, 19 Jan 2015 13:01:55 -0800
- To: <public-webcrypto@w3.org>
And my response > -----Original Message----- > From: Jim Schaad [mailto:ietf@augustcellars.com] > Sent: Monday, January 19, 2015 12:15 PM > To: 'Ryan Sleevi' > Subject: RE: Hash for ECDSA > > > > From: Ryan Sleevi [mailto:sleevi@google.com] > Sent: Monday, January 19, 2015 11:52 AM > To: Jim Schaad > Subject: RE: Hash for ECDSA > > > On Jan 19, 2015 11:16 AM, "Jim Schaad" <ietf@augustcellars.com> wrote: > > > > I don't understand. > > > > RSA v1.5 allows for a verification that the hash is correct since it is encoded > into the padding. > > > > RSA-PSS uses the hash and the mask function to create the padding. As long > as one makes the hash algorithm consistent throughout the process getting the > same padding for a different hash algorithm is going to be very difficult. > > > > DSA allows for any hash algorithm to be used without any ability to check that > it is the correct hash value. Furthermore there are two hash values which will > produce the same signature in some cases . Hash values larger than q can > cause problems. Also any two hash algorithms with the same output length can > be used so that there is the possibility of having collisions between hash > algorithms be significant. > > > > ECDSA truncates the hash value by taking the leftmost n bits of it. Thus hash > values which are longer than n will have built in collisions. Additionally, the > hash algorithm is not built into the computation so that one hash the issue of > dealing with collisions between different algorithms. > > > This isn't about hash substitution when validating sigs. This has been discussed > in the past, and OAEP and PSS (along with SSA) require the hash algorithm to be > fixed both as a common cryptographic library requirement, and for language > such as that in Section 7.1 of RFC 3447 and Section 9.1 of RFC3447. > > [JLS] OK – that makes more sense to me than saying it is cryptographically > suspect. I had no idea what that was referring to so I was making a best guess. > > > Finally, at least for importing with JWK, the algorithm of the hash is part of > the key so that piece of information is being lost. > s/JWK/JWK keys used by JOSE/ > Again, full fidelity JWK is a non-goal. Some information loss occurs in ALL of the > formats - and likely more needs to occur, judging from early implementation > experience and vendor spec compliance (e.g. no one is handling SPKi > import/export according to spec) > > > > Should I file a bug on this? > > What's the spec bug? That you don't like it? It has been this way for over two > years and changing it breaks backwards compatibility. Which is to say it is > exceedingly unlikely to change in spec or implementation. > The issue here - and which input was sought for - is that no such equivalent > guidance for ECDSA exists - in spec or library. Putting artificial limitations on > the API for consistency thus seemed an exceedingly restrictive and unnecessary > decision. > > [JLS] I happen to like API consistency as it makes my programming life easier. > One of the reasons why no such equivalent guidance exists for ECDSA is that > there is currently an assumption that is made that for any given curve there > will be only a single hash function that is used. This means that one could just > have easily made the hash algorithm implicit rather than explicit. But not a > huge deal. > > > > > > Jim > > > > > > From: Ryan Sleevi [mailto:sleevi@google.com] > > Sent: Monday, January 19, 2015 10:25 AM > > To: Jim Schaad > > Cc: public-webcrypto@w3.org > > Subject: Re: Hash for ECDSA > > > > Because it isn't cryptographically suspect in the way it is for RSA. > > On Jan 19, 2015 10:15 AM, "Jim Schaad" <ietf@augustcellars.com> wrote: > > Is there a reason that we did not move the hash for ECDSA from the sign > operation to the import operation when it was done for RSA? > > > > Jim > > > >
Received on Monday, 19 January 2015 21:03:01 UTC