Hi,
I'm using CryptoKit to implement a spec that uses ECDH using P256. The spec says that one should check that the computed shared secret is not all 0x00 bytes. I understand that this can only happen if one of both keys used is the identity point on the curve.
Does CryptoKit guarantee that P256.KeyAgreement.PublicKeys can never be the identity point by construction? (as e.g. the Rust elliptic_curve public keys do, according to their documentation)
Does CryptoKit guarantee that
P256.KeyAgreement.PublicKeyscan never be the identity point by construction?
Yes.
This critical security feature should be documented, so I’d appreciate you filing a bug against the docs about this. Please post your bug number, just for the record.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Thanks!
Here's the bug number: FB11989432
A heads up: as far as I can tell, this may not be true.
Based on someone else's report that their experiment seemed to conclude that CryptoKit wasn't validating points, I also did an experiment. I indeed seem to be able to create a PublicKey using the DER representation of what I believe is the point at infinity.
The following test fails using CryptoKit:
XCTAssertThrowsError(try P256.KeyAgreement.PublicKey(derRepresentation: Data(base64Encoded: "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==")!))
The same test succeeds using Swift Crypto.
That said, it seems you can construct the key, but you can't use it in operations AFAICT.