Subject: Re: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 support?)

From: =JeffH <[email-masked]>
Date: Thu, 1 Sep 2016 17:28:15 -0700

Brian Campbell wrote on Thursday, September 1, 2016 1:06 PM
 >
 > Each of RSASSA-PKCS1-v1_5 using SHA256, RSASSA-PSS using SHA256 and
 > MGF1 with SHA256, and ECDSA using P-256 and SHA256 can all sign
 > arbitrary length byte sequences.

AFAICT this assertion is correct, at least for the above RSA functions 
specified in RFC3447.

thus when Brian says "Yes, we sign an unhashed byte string", what he 
means is that we do not need to specify hashing the to-be-signed octets 
prior to invoking..

   RSASSA-PSS-SIGN (K, M)
   https://tools.ietf.org/html/rfc3447#section-8.1.1

..or..

   RSASSA-PKCS1-V1_5-SIGN (K, M)
   https://tools.ietf.org/html/rfc3447#section-8.2.1

..since both of those operations hash the input message M before 
invoking the RSA signing primitive [1].  Note also that there is no 
stated length restriction for input message M in RFC3447 for these 
operations.

wrt ECDSA, I do not have a copy of ANS X9.62, however I note that 
NIST.FIPS.186-4.pdf clearly states in section 6.4 that a hash function 
is employed in ECDSA digital signature generation.

HTH,

=JeffH

[1] RSASP1
     https://tools.ietf.org/html/rfc3447#section-5.2.1

---

From: Andrei Popov <[email-masked]>
Date: Fri, 2 Sep 2016 03:11:07 +0000

Reading deeper into RFC 3447, it does seem that RSASSA-PKCS1 and RSASSA-PSS use hash for both the input message and padding. I guess we all agree that there's no need to double-hash, so I'll go ahead and make the change Brian is suggesting.

Cheers,

Andrei

-----Original Message-----
From: Unbearable [mailto:[email-masked]] On Behalf Of =JeffH
Sent: Thursday, September 1, 2016 5:28 PM
To: IETF TokBind WG <[email-masked]>
Subject: Re: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 support?)

Brian Campbell wrote on Thursday, September 1, 2016 1:06 PM  >  > Each of RSASSA-PKCS1-v1_5 using SHA256, RSASSA-PSS using SHA256 and  > MGF1 with SHA256, and ECDSA using P-256 and SHA256 can all sign  > arbitrary length byte sequences.

AFAICT this assertion is correct, at least for the above RSA functions specified in RFC3447.

thus when Brian says "Yes, we sign an unhashed byte string", what he means is that we do not need to specify hashing the to-be-signed octets prior to invoking..

   RSASSA-PSS-SIGN (K, M)

..or..

..since both of those operations hash the input message M before invoking the RSA signing primitive [1].  Note also that there is no stated length restriction for input message M in RFC3447 for these operations.

wrt ECDSA, I do not have a copy of ANS X9.62, however I note that NIST.FIPS.186-4.pdf clearly states in section 6.4 that a hash function is employed in ECDSA digital signature generation.

HTH,

=JeffH

[1] RSASP1

_______________________________________________
Unbearable mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/unbearable

---

From: Brian Campbell <[email-masked]>
Date: Fri, 2 Sep 2016 06:26:24 -0600

I'm happy to submit a PR, if you like?

On Thu, Sep 1, 2016 at 9:11 PM, Andrei Popov <[email-masked]>
wrote:

> Reading deeper into RFC 3447, it does seem that RSASSA-PKCS1 and
> RSASSA-PSS use hash for both the input message and padding. I guess we all
> agree that there's no need to double-hash, so I'll go ahead and make the
> change Brian is suggesting.
>
> Cheers,
>
> Andrei
>
> Brian Campbell wrote on Thursday, September 1, 2016 1:06 PM  >  > Each of
> RSASSA-PKCS1-v1_5 using SHA256, RSASSA-PSS using SHA256 and  > MGF1 with
> SHA256, and ECDSA using P-256 and SHA256 can all sign  > arbitrary length
> byte sequences.
>
> thus when Brian says "Yes, we sign an unhashed byte string", what he means
> is that we do not need to specify hashing the to-be-signed octets prior to
> invoking..
>
>    RSASSA-PSS-SIGN (K, M)
> ..since both of those operations hash the input message M before invoking
> the RSA signing primitive [1].  Note also that there is no stated length
> restriction for input message M in RFC3447 for these operations.
>
> NIST.FIPS.186-4.pdf clearly states in section 6.4 that a hash function is
> employed in ECDSA digital signature generation.
>
> HTH,
>
> =JeffH
>
> [1] RSASP1

---

From: Andrei Popov <[email-masked]>
Date: Sat, 3 Sep 2016 01:01:34 +0000

No need for a PR, thanks Brian. The updated TBPROTO-10<https://tools.ietf.org/html/draft-ietf-tokbind-protocol-10> has this change.

I’ve also uploaded TBNEGO-05<https://tools.ietf.org/html/draft-ietf-tokbind-negotiation-05> (with a correction in the acknowledgements section).

Cheers,

Andrei

From: Brian Campbell [mailto:[email-masked]]
Sent: Friday, September 2, 2016 5:26 AM
To: Andrei Popov <[email-masked]>
Cc: =JeffH <[email-masked]>; IETF TokBind WG <[email-masked]>
Subject: Re: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 support?)

On Thu, Sep 1, 2016 at 9:11 PM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:
Reading deeper into RFC 3447, it does seem that RSASSA-PKCS1 and RSASSA-PSS use hash for both the input message and padding. I guess we all agree that there's no need to double-hash, so I'll go ahead and make the change Brian is suggesting.

Cheers,

Andrei

-----Original Message-----
From: Unbearable [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of =JeffH
Sent: Thursday, September 1, 2016 5:28 PM
To: IETF TokBind WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 support?)

   RSASSA-PSS-SIGN (K, M)

..or..

HTH,

=JeffH

[1] RSASP1

_______________________________________________
Unbearable mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/unbearable