> https://twitter.com/randomoracle/status/1217198437281804290 https://twitter.com/randomoracle/status/1217198437281804290 Some speculation on CVE-2020-0601. E

> https://twitter.com/randomoracle/status/1217198437281804290 https://twitter.com/randomoracle/status/1217198437281804290 Some speculation on CVE-2020-0601. Earlier version of Windows cryptography API only supported a handful of elliptic curves from NIST suite-B. It could not handle say an arbitrary prime-curve in Weierstrass form with user defined parameters … While it could not grok arbitrary curves, Windows API made an attempt to recognize when a curve with explicit user-defined parameters was in fact identical to "built-in" curve that is supported It appears that mapping was "lazy:" it failed to check that all curve parameters are identical to the known curve. In particular, switching the generator point results in a different curve in which an attacker can forge signatures that match a victim public key > https://twitter.com/esizkur/status/1217176214047219713 https://twitter.com/esizkur/status/1217176214047219713 It looks like this may be a caching issue: There's a CCertObjectCache class in crypt32.dll. In the latest release its member function FindKnownStoreFlags (called from its constructor) started checking the public key and parameters > https://twitter.com/thracky/status/1217175743316348929 https://twitter.com/thracky/status/1217175743316348929 ChainComparePublicKeyParametersAndBytes used to just be a memcmp before the patch. Same with any calls to IsRootEntryMatch. Both new functions.