This is related to the implementation from https://bugs.webkit.org/show_bug.cgi?id=246145 The Ed25519 algorithm implementation in WebKit produces what seems like valid signatures but they're not the expected ones despite Ed25519 being a deterministic algorithm. I've opened a PR for updating the WPTs to check that the known vectors produce the correct signature and the Safari implementation is the only one exhibiting this unexpected behaviour. In addition to Chromium, where the produced signatures match the known vector, I have also checked non browser WebCryptoAPI implementations and in all of them the signatures generated match the known vectors too. This way i've tested Chromium, Node.js, Deno, Bun, Cloudflare Workers, and Vercel's Edge Runtime. The relevant WPT update PR is at https://github.com/web-platform-tests/wpt/pull/42292
I'll take a look
<rdar://problem/116364104>
Filip, thanks for filing! Javier, this may be platform-dependent, just so you know.
(In reply to John Wilander from comment #3) > Filip, thanks for filing! > > Javier, this may be platform-dependent, just so you know. Yeah, I think it affects only to the Mac-port implementation, but I'll take care of the WebKitGtk+ port's as well if needed.
Pull request: https://github.com/WebKit/WebKit/pull/19217
(In reply to Javier Fernandez from comment #5) > Pull request: https://github.com/WebKit/WebKit/pull/19217 This PR provides a test case to reproduce the issue just using the CoreCryptoSPI primitives for signing, 'cced25519_make_pub' and 'cced25519_sign' The test case uses the OKP key pair (in raw format) defined in the ok_importKey.https.any.js import_export test [1] suite from the Web Platform Test repository. The data and expected signature were extracted from the sign_verify test [2] suite from the Web Platform Test repository. The first test verifies that the public key generated from the private key as a result of the the 'cced25519_make_pub' function matches the expected public key. This is correct, according to the new API test's results. The second tests tries to repeatedly sign the mentioned data passing the same private and public keys in every iteration. The first thing that I noticed is that the generated signature is different for each iteration and in all cases different to the expected signature. I've also attached an html test to be used with a Safari STP shipping the Ed25519 implementation to verify that the generated signature matches the expected one. It shows that the import and signing operation succeed, but that the produced signature doesn't match the expected one. However, the signature verification with the public key works, so that the round-trip process succeed. [1] https://github.com/web-platform-tests/wpt/blob/efd2c5fade72fb07176e6db7c33fd86d3088e23d/WebCryptoAPI/import_export/okp_importKey.https.any.js#L11 [2] https://github.com/web-platform-tests/wpt/blob/efd2c5fade72fb07176e6db7c33fd86d3088e23d/WebCryptoAPI/sign_verify/eddsa_vectors.js#L31
Created attachment 468260 [details] Test case for the Ed25519 sign operation
This bug should be handled by someone with knowledge on the Mac's Crypto core module.