Subject: RE: Protecting Against Weak Hash Algorithms

From: "Turner, Sean P." <[email-masked]>
Date: Tue, 17 Oct 2006 12:53:45 -0400

I'm really curious whether you think we ought to do this in the certificate
or in the protocol that's carrying the signed/hashed object.  Jim Schaad and
I are working on an as yet unpublished ID in S/MIME to protect against an
attacker stripping a SignedData, which has two SingerInfos one that is
"strong" algorithm and one that is "weak" algorithm, of the "weak"
algorithm.  All of this is of course predicated on the relying party
supporting more than one algorithm and processing the new attribute.
 
spt

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Santosh Chokhani
Sent: Wednesday, September 20, 2006 3:10 PM
To: [email-masked]
Subject: Protecting Against Weak Hash Algorithms

As you know the hashing algorithms are in state of flux (We know MD5 is bad,
SHA-1 is beginning to smell and so on).

Also, we know that many relying parties implement many of these algorithms.

Also, Russ has been talking about making PKIX RFCs algorithm independent so
that algorithms can be easily swapped in and out.

I think we should have a debate on security issues surrounding weak hashes,
specifically relying parties snookered into verifying a signature using a
weak hash that can easily create collision with payload that was actually
signed using a strong hash.

While it will be a great deal of pain to the client software, but subject
public key information through OID or parameters could specify one or more
hash algorithms to be used with a signature key.  This will protect against
the spoofing of relying party into using a weak hash during signature
verification.  I thought while we are debating the syntax for ECC based
algorithms, this may be a good time to suffer that pain.

Santosh Chokhani 
Orion Security Solutions, Inc. 
(703) 401-7088 
[email-masked]

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 17 Oct 2006 10:02:24 -0700

Sean,

The long term goal (with defense in depth in mind) is simple.  The
identification of acceptable hash algorithm(s) should be bound to the
pubic key in the certificate.  Thus, listing these as part of SPKI is
what we want to move to.

________________________________

From: Turner, Sean P. [mailto:[email-masked]] 
Sent: Tuesday, October 17, 2006 12:54 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: Protecting Against Weak Hash Algorithms

I'm really curious whether you think we ought to do this in the
certificate or in the protocol that's carrying the signed/hashed object.
Jim Schaad and I are working on an as yet unpublished ID in S/MIME to
protect against an attacker stripping a SignedData, which has two
SingerInfos one that is "strong" algorithm and one that is "weak"
algorithm, of the "weak" algorithm.  All of this is of course predicated
on the relying party supporting more than one algorithm and processing
the new attribute.

spt

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Wednesday, September 20, 2006 3:10 PM
To: [email-masked]
Subject: Protecting Against Weak Hash Algorithms

As you know the hashing algorithms are in state of flux (We know MD5 is
bad, SHA-1 is beginning to smell and so on).

Also, we know that many relying parties implement many of these
algorithms.

Also, Russ has been talking about making PKIX RFCs algorithm independent
so that algorithms can be easily swapped in and out.

I think we should have a debate on security issues surrounding weak
hashes, specifically relying parties snookered into verifying a
signature using a weak hash that can easily create collision with
payload that was actually signed using a strong hash.

While it will be a great deal of pain to the client software, but
subject public key information through OID or parameters could specify
one or more hash algorithms to be used with a signature key.  This will
protect against the spoofing of relying party into using a weak hash
during signature verification.  I thought while we are debating the
syntax for ECC based algorithms, this may be a good time to suffer that
pain.

Santosh Chokhani