[jpgoldberg]

Yep. There is very definitely a reason. You might not like it, but there is. For the moment we need a client that runs reasonable well in web browsers.

As libraries become more available or the nature of our clients change, we can switch. We certainly look forward to having the smaller keys that ECC will give us.

We are aware of tweet-nacl, but we are trying to avoid the number of external JS libraries we would need. This is why the Teams web app is limited to browsers that most fully support WebCrypto.(Of course our own browser extension for Desktop 1Password runs in more browsers as it does not rely on any crypto itself.)

I admit it is kind of weird using GCM where a stream cipher would be faster, lighter, cheaper. And so we definitely are looking forward to moving to something like that for our transport layer encryption. There aren't any security problems with our current ciphersuites, but we should be able to improve performance by using things like what you recommend.

[Titanous]

Thanks for the answer! WebCrypto is obviously a disaster, it is very unfortunate that new systems are being stuck with legacy crypto if they use it instead of non-native libraries.

[jpgoldberg]

I think that there are three issues with WebCrypto that people often conflate. But they need to be looked at separately when judging the security of any particular things.

1. Limited algorithms. This is what has use using GCM instead of a stream cipher for our transport layer. 2. It allows developers to shoot themselves in the foot by not enforcing best practices. 3. It encourages crypto delivered over the web.

If (3) is your concern, then it doesn't matter how good, modern, up to date, the methods are. This objection applies to tweet-nacl just as well.

If (1) is your concern, keep in mind that there is nothing wrong with the algorithms and modes we are using. Sure we had to forego some slicker alternatives, but this is a performance hit.

If (2) is your concern then what is true about WebCrypto is true of almost every crypto library out there. Whether we use libcrypto, CommonCrypto, MS CAPI, etc, we have just as great a chance of "using it wrong" as we do with WebCrypto. WebCrypto isn't worse than most of the alternatives, it is just new enough that we all hoped it would be better than the alternatives in this regard.

So given these three general concerns with WebCrypto, you need to make a judgement about how these play out when evaluating 1Password for Teams.

[tptacek]

(2) is not true of misuse-resistant crypto primitives and libraries, which is kind of the point of Nacl.

[jpgoldberg]

Notice I said "almost every other crypto library". I had NaCl specifically in mind with that qualification.

It's no secret how you feel about crypto delivered over the web and run in the browser, but one of the the factors in our choice involved speed and stability of WebCrypto versus <strike>tweet-nacl</strike>NaCl in JavaScript.

NaCl might be a good choice for our transport layer, but we do a lot of encrypting of keys and not just of non-key data. So we needed to make use of .subtle methods every now and then. So if we needed things that NaCl didn't offer, it was simpler to use a single other API/Library than to mix and match.

I am a huge supporter of efforts like NaCl. I'd obviously prefer to be denied the opportunity to shoot myself (and our customers) in the foot than to use tools that are prone to misuse. It would have also been really cool to show off using NaCl. It is the direction we'd like to see the world move. But we couldn't quite swing it this time around.

[sdevlin]

TweetNaCl is a C library.

[jpgoldberg]

Oh. Never mind.

I somehow had it confused with a JavaScript implementation. Not sure how I had that misconception in my head.

[newman314]

Why not give us the option to choose? That way, shops that have more recent crypto in place can start taking advantage sooner rather than later.