Re: [Cfrg] Question from JOSE working group

As I said - with the introduction of new signature algorithms led to the
fact that the hash algorithm was no longer protected.

If you are looking at breaking an RSA signature, you have two ways of going
about it.  You can either break the hash in some way - or you can factor the
RSA keys.   The RSA problem is related to the factoring of the keys and has
little to do with attacking the hash algorithm.

If I could get you to substitute my hash algorithm for the actual hash
algorithm used, and they had the same hash value for different messages then
the RSA problem is not relevant for the purposes of the attack.  The
PKCS#1.5 RSA defended against this by placing the hash algorithm identifier
in as part of the "to be signed" value.  This was both good - the hash
algorithm was defended and bad - there were lots of known bits fixed bits in
the signature block for lots of signatures.

There can be operational/convention steps that deal with this - for example
there is a suggested practice that the hash algorithm used in the RSA-PSS
signature operation and the one computing the hash of the message should be
the same.  But there is no current requirement that these steps be followed.
(Oops - need to file an erratum on RFC 4056 about what to do for a hash
algorithm if signed attributes are not used.)

The reason for writing RFC 6211 was precisely the issue of protecting the
hash algorithm used in the signature operation in those cases where it was
not completely obvious (i.e DSA which only permitted one signature
algorithm) or it was not included in the cryptographic block (RSA v1.5).  

Jim

> -----Original Message-----
> From: Richard L. Barnes [mailto:rbarnes@bbn.com]
> Sent: Tuesday, July 03, 2012 12:59 PM
> To: Jim Schaad
> Cc: 'Russ Housley'; cfrg@irtf.org; jose@ietf.org
> Subject: Re: [Cfrg] Question from JOSE working group
> 
> More precisely:
> RSASSA-PKCS1-v1_5 includes the hash algorithm under the signature
> RSASSA-PSS (introduced in PKCS#1 v2.1) does not include the hash algorithm
> 
> Doesn't this seem to argue against the need to protect parameters, since
the
> security of RSASSA-PSS is tightly related to the RSA problem itself?
> 
> 
> On Jul 3, 2012, at 1:43 PM, Jim Schaad wrote:
> 
> > I would also note that when PKCS#7 was designed, the hash algorithm
> > was always protected independent the presence of signed attributes.
> > Either the hash algorithm was in the signed attributes or it was in the
RSA
> signature
> > block encoding.   It was only with the introduction of other algorithms
that
> > this was no longer true.
> >
> > Jim
> >
> >
> >> -----Original Message-----
> >> From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf
> >> Of Russ Housley
> >> Sent: Tuesday, July 03, 2012 8:02 AM
> >> To: Richard L.Barnes
> >> Cc: cfrg@irtf.org; jose@ietf.org
> >> Subject: Re: [Cfrg] Question from JOSE working group
> >>
> >> Richard:
> >>
> >>> Actually, the inclusion of the hash algorithm under the signature is
> > optional:
> >>> "
> >>>     signedAttrs is a collection of attributes that are signed.  The
> >>>     field is optional, but it MUST be present if the content type of
> >>>     the EncapsulatedContentInfo value being signed is not id-data.
> >>>     [...]  If the field is present, it MUST
> >>>     contain, at a minimum, the following two attributes:
> >>>
> >>>        ...
> >>>
> >>>        A message-digest attribute, having as its value the message
> >>>        digest of the content.  Section 11.2 defines the message-digest
> >>>        attribute.
> >>> "
> >>>
> >>> Since "id-data" means "no more ASN.1 structure", for JOSE, the
> >>> content
> >> type is effectively always "id-data".
> >>
> >> In practice, there are other attributes that one wants signed, such
> >> as
> > signing-
> >> time, so the algorithm identifier gets included.
> >>
> >> Russ
> >>
> >> _______________________________________________
> >> Cfrg mailing list
> >> Cfrg@irtf.org
> >> http://www.irtf.org/mailman/listinfo/cfrg
> >