Cannot sign in. The JWK "d" member contained a leading zero.

I'm really sorry for the trouble, @MasterPhW.

Just to give some background, when you first sign up for an account your browser will create a number of keys. One of them is a signing key pair. This is signing key pair isn't integral to what 1Password does today, but we have plans for it.

What is an ECDSA key?

To save space, we decided to create have the browsers create this as ECDSA keys. The EC in that stands for "Elliptic Curve". These are really nice for public key cryptography because the keys (per amount of strength) are so much smaller than RSA keys. The public part of these key pairs is a "point", P, with an x and y coordinate. And the secret part is a value, d that that is how many times the base point (which I will call G) is "added to itself" to get to your public key. The cryptography depends on the fact (well, claim) that while it is easy to calculate P = dG, it is really really hard to calculate d from P and G. (And that you can do things with knowledge of d).

We've got a (long) blog post on that includes more information about these points and numbers: When back doors go bad: Mind your Ps and Qs

Browser inconsistencies

Anyway, it appears that the web-crypto tools that browsers offer is not implemented perfectly or consistently in all browsers. We've run into a couple of browser bugs in the creation of these keys and in the import of them that we are simultaneously trying to report to the browser developers while also trying to put in our own work-arounds for these issues. Sometimes a key created by one browser (when you first sign up) isn't accepted by another.

For example, d is going to be a random 32-byte number. Each byte can contain a number between 0 and 255 (inclusively). Now this means that if you are randomly generating d, there is a 1 in 256 chance that the first byte will be 0. Just as in decimal notation there is no difference between 0678.901 and 678.901 in terms of numerical value there is no difference between a 31 byte number and a 32 byte number in which the leading byte is 0.

Some browsers, when they create a such a number (which will happen roughly 1 out of every 256 times), will set d to a 31 byte value. Others will pad d with a leading zero byte to make it 32 bytes. And some browsers barf when given a 31 byte value, and other browsers barf when given a value that has been padded out (I think).

Our work-arounds involve a lot of browser-specific coding as we attempt to learn the idiosyncrasies of each browser. Naturally, we aren't happy about this. Writing browser specific routines and fixes is a sign of trouble and should be avoided. But at the moment we are forced into it. @rob is the person mostly handling this, and so he will know what our current understanding of each and every browser in this regard.

Please keep in mind that this is also a learning process for us (and browser vendors). It seems that web-crypto ECDSA keys are not much used in cross browser systems, and so these sorts of browser bugs and inconsistencies have not been sorted out yet.

Not a TLS issue

I should point out that these bugs and inconsistencies are only in the web-crypto tools that browsers offer to extension and web-app developers. And that these tools are relatively new. We are not seeing this problem with the kind of key generation that browsers use in their SSL/TLS routines.

What this means for you

In your case, we would need to know what browser you first signed up with to get a better sense of what is happening. It looks like we are over correcting for something, but we can't know without looking at the d of your signing key, and that is your secret and something we should never see. (Though again, it isn't really used currently.)

We are working on more robust work-arounds as we learn more about exactly what does and doesn't trigger an error in each and every browser. As these signing keys aren't really used (much) in 1Password yet, we believe that we can have your browser try to detect problematic signing keys and just generate a replacement for you. This will create a slight weakening in the strength of the key generation process by tossing out what in principle should be valid values, but it is only a small weakening.

So what this means for you is that we ask you to have patience, and follow @brenty's advice about using 1Password in configurations that work. But if you can recall what browser you originally created your account with, please let us know. That will help us better understand which browsers are doing what.

@MasterPhW, can you recall what browser you used when you first created your account?

@roustem, why do I get the feeling that we are the first to actually try to make real use of the web-crypto ECDSA API? (For those who don't know, this issue with the zero padding of d is not the only inconsistency we've found between browsers in the generation and handling of these keys.)

Ah. Roustem is right! I've had my head so wrapped up in a different ECDSA web-crypto key generation issue that I forgot about this RSA one. Yes, we've found inconsistencies there as well with respect to padding. This is almost certainly the RSA private key padding issue. In this case, these keys are central to how 1Password operates today.

Anyway, as with EC private keys, d is also the secret part of RSA keys. (n is the public key, and e is a public parameter). dp, dq, p, q, and qi are all private but are kept around to make computation faster. Note that while the d in the ECDSA private key was 256 bits (32 bytes), the lengths in what @roustem quoted for the RSA keys are in bytes.