[lamps] Does 6211 actually do what it claims to?

[Mike Ounsworth <[e-mail]>]

This is maybe a dumb question coming from a relative PKIX newcomer.

RFC 6211 sets out to solve algorithm substitution attacks in CMS by including the digestAlgorithm, and either signatureAlgorithm or macAlgorithm in the digested-and-signed content.

Cheekily: does this actually solve algorithm substitution attacks?

Seems like a chicken-and-egg situation where, during signature verification, you are using the (currently unverified) content to tell you how to verify the content. In particular, 6211 puts the digest alg id inside the digest, and therefore it's fair game for manipulation during a hash collision attack. 

PKCS#1 v1.5 puts the digest alg id outside (ie next to) the digest in the signed data, which seems like it gets you out of the checken-and-egg situation because now you would need a collision in the signature primitive, not in the hash primitive (ie it's now the sig primitive protecting the hash primitive, rather than the hash primitive protecting itself). RSA-PSS internally does something that looks distinctly HMAC-y, so it's probably ok too but for different reasons.


Furthermore, a quote from Kaliski, Burton, 2002, "On hash function firewalls in signature schemes":

"Note that identifying the hash function in the message itself is not enough; it is likely as easy for an opponent to control the identifier as any other part of a message when forging a signature." 

.. which seems exactly what 6211 has done.



So, am I missing something, or are hash function substitution attacks only really solvable via the construction of the signature primitive, and not at the protocol layer? In which case, 6211 does not actually solve the problem that it set out to solve?



PS: I also posted this to stack exchange: https://crypto.stackexchange.com/q/90318/24012

---
Mike Ounsworth
Software Security Architect, Entrust