RE: Protect Algorithm identifiers?

["Jim Schaad" <ietf@xxxxxxxxxxxxxxxxx>]

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
 

> -----Original Message-----
> From: Russ Housley [mailto:housley@xxxxxxxxxxxx] 
> Sent: Tuesday, May 02, 2006 1:23 PM
> To: Jim Schaad; ietf-smime@xxxxxxx
> 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
> 
> At 04:24 PM 5/2/2006, Jim Schaad wrote:
> >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: owner-ietf-smime@xxxxxxxxxxxx
> > > [mailto:owner-ietf-smime@xxxxxxxxxxxx] On Behalf Of Russ Housley
> > > Sent: Tuesday, May 02, 2006 12:50 PM
> > > To: jimsch@xxxxxxxxxx; ietf-smime@xxxxxxx
> > > 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
> > >
> > >
> > > 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
> > >
> > >
> > >
> 
> 
>