Re:Microsoft is Abandoning SHA-1 Hashes for Updates
by comex on Wednesday February 20, 2019 @10:29AM
(#19208560)
To further clarify:
> You make two documents A and B, A is an ordinary seeming true statement which you can get certified, while B is something outrageous nobody would certify,
This does imply that the attacker only has limited choice with respect to A and B. They can’t just be random bytes: A has to be not only a syntactically valid X.509 certificate, but one that a legitimate CA will generate (based on the attacker’s inputs in a Certificate Signing Request) and sign, while B has to be a syntactically valid certificate which is useful to the attacker to have a signature for. However, in practice, collision attacks tend to let the attacker arbitrarily pick parts of both messages, while other parts are chosen by the algorithm and do look like a large amount of random binary gunk. In this case, most of the fields of an X.509 certificate are not adequately controllable and/or not large enough to stick the gunk into, but there’s one exception: the public key field, which just happens to be a large blob of binary data that’s chosen by the attacker and expected to look random. So that’s what was used, in the famous proof-of-concept MD5 certificate forgery from 2006 that resulted in the random serial number requirement being added. More details:
> You make two documents A and B, A is an ordinary seeming true statement which you can get certified, while B is something outrageous nobody would certify,
This does imply that the attacker only has limited choice with respect to A and B. They can’t just be random bytes: A has to be not only a syntactically valid X.509 certificate, but one that a legitimate CA will generate (based on the attacker’s inputs in a Certificate Signing Request) and sign, while B has to be a syntactically valid certificate which is useful to the attacker to have a signature for. However, in practice, collision attacks tend to let the attacker arbitrarily pick parts of both messages, while other parts are chosen by the algorithm and do look like a large amount of random binary gunk. In this case, most of the fields of an X.509 certificate are not adequately controllable and/or not large enough to stick the gunk into, but there’s one exception: the public key field, which just happens to be a large blob of binary data that’s chosen by the attacker and expected to look random. So that’s what was used, in the famous proof-of-concept MD5 certificate forgery from 2006 that resulted in the random serial number requirement being added. More details:
https://blog.cloudflare.com/why-its-harder-to-forge-a-sha-1-...