FW: Hash for ECDSA

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