Olle Mulmo wrote:
Seems to me that a CA can nullify this attack by choosing a serial
number or RDN component (after all, a CA should vet the DN and not
simply sign what's in the PKCS#10 request), such that the public key
does not end up at an appropriate DER-encoded offset in the
certificate.
http://www.infosec.sdu.edu.cn/paper.htm
Xiaoyun Wang, Hongbo Yu: How to Break MD5 and Other Hash Functions,
Eurocrypt'2005
Xiaoyun Wang, Hongbo Yu: Cryptanalysis of the Hash Functions MD4 and RIPEMD,
Eurocrypt'2005
-
The
Benne,
One could e.g. construct the to-be-signed parts of the certificates,
and get the one certificate signed by a CA. Then a valid signature for
the other certificate is obtained, while the CA has not seen proof of
possession of the private key of this second certificate.
From the paper I
Florian Weimer wrote:
I think you can forward the PassCode to AOL once the victim has
entered it on a phishing site. Tokens à la SecurID can only help if
Indeed.
the phishing schemes *require* delayed exploitation of obtained
credentials, and I don't think we should make this assumption. Online
