RE: Hash for ECDSA

Accidentally dropped the list from my reply; sorry about that.
On Jan 19, 2015 11:52 AM, "Ryan Sleevi" <sleevi@google.com> wrote:

>
> 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.
>
> > 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.
>
> >
> > 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
> >
> >
>