New issue
Advanced search Search tips

Issue 532728 link

Starred by 5 users

Issue metadata

Status: Duplicate
Merged: issue 389400
Closed: Jul 2016
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Sign in to add a comment

Chrome cannot import public ECDH key generated in Firefox exported via SPKI

Reported by, Sep 17 2015

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.93 Safari/537.36

Steps to reproduce the problem:
gen.htm is the code used to generate the keys

import.htm is the test to import, with embedded ECDH public keys generated in Firefox Nightly (43.0a1 (2015-09-16))

What is the expected behavior?
Successfully import the key.

What went wrong?
Uncaught (in promise) DOMException 

Did this work before? No 

Chrome version: 46.0.2486.0   Channel: dev
OS Version: Ubuntu 15.04
Flash Version:
1.5 KB View Download
615 bytes View Download
Labels: Cr-Blink-WebCrypto

Comment 2 by, Sep 17 2015

Status: Assigned

Comment 3 by, Sep 17 2015

Thanks for the report.

BoringSSL does not recognize OID id-ecDH, which is what Firefox uses for its exported ECDH keys (and is also what the WebCrypto spec says to do, so they are correct to do so).

Chromium however will only recognize id-ecPublicKey.

I have bugs on file talking about this equivalent issue for RSA algorithms, and this limitation was discussed when writing the code.

This is something I need to address.

In the meantime as a workaround you may need to use JWK.

There are ways as well to do a manual transformation of the key exported from Firefox to get it to import in Chrome. It isn't as simple as just a string replace, since the length of the two OIDs is different.
Yeah, as I discovered. Hance the thought that raw exports would be more compatible.

Am using a fixed binary message format, as have multiple ECDH public keys per message.

There are other issues preventing cross browser crypto atm anyways. The only common KDF implementation between Firefox and Chrome is PBKDF2, which seems ill suited for deriving keys from DH/ECDH shared secrets. 

Will probably just implement a raw export/import shim for Chrome, as exporting the same ASN.1 data for each key makes little sense.

Comment 5 by, Sep 17 2015

If you run into other compatibility bugs between browsers please file them as that feedback is helpful.

Comment 6 by, Sep 18 2015

Labels: -Cr-Blink-JavaScript
Labels: Hotlist-Recharge
This issue likely requires triage.  The current issue owner maybe inactive (i.e. hasn't fixed an issue in the last 30 days).  Thanks for helping out!

Labels: -OS-Linux -Hotlist-Recharge OS-All

Comment 9 by, Mar 21 2016

I opened a related bug for Firefox:

There seems to be a big of confusion about which OID to really use:

Does Chromium (BoringSSL) maybe support as an OID? That one is defined in the RFC 5480 standard.

Anyway, this bug is really problematic. At we hit it when we were implementing our OTR implementation. It is really complicated to do cross-browser compatible crypto.
No, Chromium only supports id-ecPublicKey.

The support for ASN.1 key formats is being discussed by the working group, since these sorts of compatibility issues are definitely a problem.

My best recommendation to you right now is to use the JWK key format if you want cross browser compatibility.

Comment 11 by, Mar 21 2016

Problem is that other tools (like OpenSSL) do not really support JWK.

Comment 12 by, Mar 21 2016

> The support for ASN.1 key formats is being discussed by the working group

Hm, but is clearly specified in current web crypto standard as one to be used? Not sure what further discussion are you referencing here? To add even more OIDs? Like support the id-ecPublicKey?

As a matter of fact, Firefox supports both standard and id-ecPublicKey. So in some way it is lenient in the output (reads both) but strict in the output (outputs based on the current standard).

I think Chromium should do the same.
Support for ASN.1 key formats has been suggested to be removed. As Eric mentioned, the best recommendation for interoperability is to use JWK, until these issues can be resolved and the proper direction for implementations decided. Until that's decided in the WG, there are no plans to change Chromium's implementation.
> Problem is that other tools (like OpenSSL) do not really support JWK.

OpenSSL doesn't support id-ecDH ( either, by the way. That's actually where BoringSSL not supporting it comes from. Support for id-ecDH is rather rare. We could probably add it, though, as Ryan mentioned, this is kind of up in the air at the WG right now.
Mergedinto: 389400
Status: Duplicate (was: Assigned)

Sign in to add a comment