Subject: Re: Protect Algorithm identifiers?

From: Russ Housley <[email-masked]>
Date: Tue, 02 May 2006 15:49:35 -0400

Jim:

If the recipient has confidence in the hash algorithm, I do not see 
any problem with the current documents.  I think that implementations 
are going to need to be modified to provide an interface for users to 
indicate which ones are acceptable and which ones are not.  The 
default setting will be vital.

Russ

At 11:38 PM 4/17/2006, Jim Schaad wrote:

>In the process of reviewing documents dealing with multiple signature
>processing, I suddenly realized that we currently do not have any attribute
>which lets us verify that the correct digest and signature algorithms have
>been used in verifying a SignerInfo.  The question is do we need to do this?
>
>More details on what I mean:
>
>When you create a signer info you:
>
>1.  Hash the body of the message, place the digest value as a signed
>attribute and the digest algorithm into the SignerInfo structure in an
>unprotected location.
>
>2.  Create the sequence of signed attributes, hash the value, create a
>signature value using your private key and place the signature algorithm and
>the signature in unprotected locations.
>
>The signature does not need any additional protection, however one could
>change the digest algorithms being used in both the signature and body
>digest locations without a verifier being able to know that it has happened.
>
>
>The attack I envision would be to find a body that has a digest of the same
>length, but uses a different algorithm and update the SignerInfo structure
>with the new digest algorithm data and the body with the updated body.  This
>would currently be undetectable by a verifier.
>
>Jim

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 2 May 2006 13:24:33 -0700

Russ,

As I have stated, what really worries me is if one starts to play with the
parameters of the new round of hash algorithms that are being looked at.
There is no protection for these parameters either in the signature or in
the default settings of the validation code.

Jim

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Russ Housley
> Sent: Tuesday, May 02, 2006 12:50 PM
> To: [email-masked]; [email-masked]
> Subject: Re: Protect Algorithm identifiers?
> 
> 
> Jim:
> 
> If the recipient has confidence in the hash algorithm, I do 
> not see any problem with the current documents.  I think that 
> implementations are going to need to be modified to provide 
> an interface for users to indicate which ones are acceptable 
> and which ones are not.  The default setting will be vital.
> 
> Russ
> 
> 
> >processing, I suddenly realized that we currently do not have any 
> >attribute which lets us verify that the correct digest and signature 
> >algorithms have been used in verifying a SignerInfo.  The 
> question is do we need to do this?
> >
> >signature value using your private key and place the signature 
> >algorithm and the signature in unprotected locations.
> >
> >The signature does not need any additional protection, however one 
> >could change the digest algorithms being used in both the 
> signature and 
> >body digest locations without a verifier being able to know 
> that it has happened.
> >
> >
> >The attack I envision would be to find a body that has a 
> digest of the 
> >same length, but uses a different algorithm and update the 
> SignerInfo 
> >structure with the new digest algorithm data and the body with the 
> >updated body.  This would currently be undetectable by a verifier.
> >
> >Jim
> 
> 
>

---

From: Russ Housley <[email-masked]>
Date: Tue, 02 May 2006 16:22:37 -0400

Jim:

If one has confidence in the hash algorithm and the hash values 
match, then there is not a problem, regardless of the parameter values.  Right?

Russ

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 2 May 2006 13:37:30 -0700

Russ,

Wrong -- If one changes the parameters that are being used, one can change
the source document as well and still get a match of the hash values.

There have been proposals (which I am sure will not survive) to use a random
value and xor to strengthen the hash function.  Change the both the document
and the random in a well known manner would still result in a match on the
have value, but the document would no longer be the same.

Jim

> From: Russ Housley [mailto:[email-masked]] 
> Sent: Tuesday, May 02, 2006 1:23 PM
> To: Jim Schaad; [email-masked]
> Subject: RE: Protect Algorithm identifiers?
> 
> Jim:
> 
> If one has confidence in the hash algorithm and the hash 
> values match, then there is not a problem, regardless of the 
> parameter values.  Right?
> 
> Russ
> 
> >As I have stated, what really worries me is if one starts to 
> play with 
> >the parameters of the new round of hash algorithms that are 
> being looked at.
> >There is no protection for these parameters either in the 
> signature or 
> >in the default settings of the validation code.
> >
> >Jim
> >
> >
> > > any problem with the current documents.  I think that 
> > > implementations are going to need to be modified to provide an 
> > > interface for users to indicate which ones are acceptable 
> and which 
> > > ones are not.  The default setting will be vital.
> > >
> > > Russ
> > >
> > >
> > > >attribute which lets us verify that the correct digest and 
> > > >signature algorithms have been used in verifying a 
> SignerInfo.  The
> > > >1.  Hash the body of the message, place the digest value as a 
> > > >signed attribute and the digest algorithm into the SignerInfo
> > > structure in an
> > > >unprotected location.
> > > >

---

From: Russ Housley <[email-masked]>
Date: Tue, 02 May 2006 19:37:17 -0400

Jim:

I now understand your concerns.  Hugo Krawczyk is advocating the use 
of a random number, but he is not advocating the use of the 
parameters field to carry them.

In the case of RSA, Hugo is suggesting the encryption of the random 
number and the hash value output with the private key.  Verification 
is performed by decrypting the signature value, recovering the random 
number and hash value, and then computing the hash with the random 
number, and then comparing the output to the hash value from the signature.

In the case of DSA, Hugo has suggested using the r value as the 
random number.  Recall that a DSA signature is two values: r and 
s.  The r value is independent of the message content, and it can be 
computed before the s value, which depends on the hash value.

As you say, the proposal made by Hugo may not become widely 
accepted.  But if it is, it does not depend on integrity protection 
of the parameters.

Russ