W3C home > Mailing lists > Public > public-webcrypto@w3.org > January 2015

RE: Hash for ECDSA

From: Ryan Sleevi <sleevi@google.com>
Date: Mon, 19 Jan 2015 12:19:55 -0800
Message-ID: <CACvaWvZ7TKH1fKBQsk7AeDWpDjPujMUMH484DKa+eZs3e-5S4Q@mail.gmail.com>
To: Jim Schaad <ietf@augustcellars.com>, public-webcrypto@w3.org
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
> >
> >
>
Received on Monday, 19 January 2015 20:20:23 UTC

This archive was generated by hypermail 2.3.1 : Monday, 19 January 2015 20:20:24 UTC