Implement ECDH DeriveKey/DeriveBits operations according to the spec: https://www.w3.org/TR/WebCryptoAPI/#ecdh-operations.
<rdar://problem/23789585>
Created attachment 303839 [details] Patch
This bug only implements ECDH DeriveBits for now. The DeriveKey operation will be tracked on another bug.
Created attachment 303842 [details] Patch
Comment on attachment 303842 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=303842&action=review Looks good. Does this not cause any W3C test cases to start passing? Maybe you need the DeriveKey part, too. > Source/WebCore/bindings/js/JSSubtleCryptoCustom.cpp:-63 > - DeriveKey, Should we leave this in as a "NotSupportedError" case until your second patch? > Source/WebCore/bindings/js/JSSubtleCryptoCustom.cpp:-162 > - case Operations::DeriveKey: Ditto here? Just handle "NotSupported" for now, rather than remove it completely?
Comment on attachment 303842 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=303842&action=review Thanks Brent for r+ my patch. Sadly, all the w3c test cases use SPKI/PKCS as the de facto formats for importing EC keys. Therefore, the test won't run on WebKit until we support SPKI/PKCS. Good news though Firefox doesn't support SPKI/PKCS as well. So the tests don't run on Firefox too. >> Source/WebCore/bindings/js/JSSubtleCryptoCustom.cpp:-63 >> - DeriveKey, > > Should we leave this in as a "NotSupportedError" case until your second patch? Sure. >> Source/WebCore/bindings/js/JSSubtleCryptoCustom.cpp:-162 >> - case Operations::DeriveKey: > > Ditto here? Just handle "NotSupported" for now, rather than remove it completely? Fixed.
Created attachment 303850 [details] Patch
Comment on attachment 303850 [details] Patch r=me.
Comment on attachment 303850 [details] Patch Rejecting attachment 303850 [details] from commit-queue. Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.webkit.org', '--bot-id=webkit-cq-02', 'land-attachment', '--force-clean', '--non-interactive', '--parent-command=commit-queue', 303850, '--port=mac']" exit_code: 2 cwd: /Volumes/Data/EWS/WebKit Last 500 characters of output: ilding .git/svn/refs/remotes/origin/master/.rev_map.268f45cc-cd09-0410-ab3c-d52691b4dbfc ... Currently at 213615 = 4ca78b286ae45bc70b983c531c3b927abd5f921f r213616 = f89f40e92bc59b44ebaf3e209362eaf1c89dfbf2 r213617 = 196c89ab01ab2d2311a910cb5fb43773dff9e9f2 Done rebuilding .git/svn/refs/remotes/origin/master/.rev_map.268f45cc-cd09-0410-ab3c-d52691b4dbfc First, rewinding head to replay your work on top of it... Fast-forwarded master to refs/remotes/origin/master. Total errors found: 0 in 1 files Full output: http://webkit-queues.webkit.org/results/3273373
Committed r213624: <http://trac.webkit.org/changeset/213624>
Comment on attachment 303850 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=303850&action=review > Source/WebCore/crypto/keys/CryptoKeyEC.h:88 > + PlatformECKey platformKey() { return m_platformKey; } const?
(In reply to comment #11) > Comment on attachment 303850 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=303850&action=review > > > Source/WebCore/crypto/keys/CryptoKeyEC.h:88 > > + PlatformECKey platformKey() { return m_platformKey; } > > const? PlatformECKey is a opaque C structure from CommonCrypto. Therefore, const will make it impossible to pass to CommonCrypto APIs.