[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate


Oh, OK. I got it now. Eek.

On Jan 5, 2009, at 9:37 AM, Yoav Nir wrote:


OK. Now I'm a lot confused :-)

On Jan 5, 2009, at 12:02 AM, Weger, B.M.M. de wrote:


Hi Paul,


Just to repeat it one more time: #3 does not prevent the

published attack.


It does if the random fluff is inserted by the CA. The

attack depends on their ability to predict the entire TBS part.

I may have misunderstood the paper, but I think that changes
after the subjectPublicKeyInfo do not affect the attack.


Almost correct. A random looking "collision block" has to be inserted
somewhere. We chose to insert it in the public key, as that seems
the most convenient. Somebody else may find another place where
it can be hidden (maybe in a "subject key identifier" field or something, 
I don't know what would be feasible). Everything after the "collision
block" must be copied bitwise into the twin certificate, and must be
'harmless' there. If 'random fluff' is inserted by the CA after the
"collision block", this 'random fluff' can be copied into the twin
certificate as well, retaining the collision property, and this
would indeed be irrelevant to our attack.
If you inserted a random looking collision block in the public key, how did your signature on the PKCS#10 request verify? 





Also, I've updated today and all the "bad" CAs with MD5

signatures are still in the TAS.

As was pointed out to me earlier: it does not matter if the
CA has its cert signed with MD5, only whether that CA *signs*
with MD5. RapidSSL, for example, is still signed with MD5 but
is now signing with SHA-1.


Correct.
Sure, but the other authorities that signed with MD5 (no idea if they've changed their evil ways) are still there. 




Email secured by Check Point