To clarify the Windows crypto fail: The problem isn't in signature validation. The problem is the *root store/cache*. CryptoAPI considers an (attacker-supplied) root CA to be in the trust store if its public key and serial match a cert in the root store, Ignoring curve params.
-
-
one of the hardest problems in CS is finding the right touhou picture to use as your avatar on social media
-
They should atleast be cute right?
End of conversation
New conversation -
-
-
Why are the params not part of the serial?
-
What do the params have to do with the serial? The serial is just an arbitrary serial number.
- Show replies
New conversation -
-
-
Thanks for this excellent and comprehensive explanation.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Is it easier to find params that generate an arbitrary pub key than to find a pub key given the params? Aren't both roughly just at hard? What am I missing?
-
What you're trying to find is the private key given the public key. You cannot find the original private key for the original params, but you can trivially craft parameters in such a way to make a private key of 1 "happen" to correspond to the original public key.
End of conversation
New conversation -
-
-
Presumably, only for ECC...ah, because only ECC has params significant/agile in this manner?
- Show replies
New conversation -
-
-
I wonder why does it even touch the supplied CA certificate. Shouldn't it simply get the CA certificate from the trusted store, keyed by the signer Subject/KeyID listed in the child certificate?
-
I'd suspect it's because the chain verification is distinct from whether the chain is trusted by policy. Therefore you supply the full chain with the bogus cert, which checks out okay. Then the trust is checked, it compares AuthKeyIDs and find a matching trusted root. Job done!
- Show replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.