
Tanker: End-to-End Encryption SDK for JavaScript - TankerHQ
https://github.com/TankerHQ/sdk-js
======
dfabulich
I keep asking, what is the threat model for end-to-end encryption in JS? Like,
is there an Alice, Bob, Carol, Eve story under which E2E in JS makes sense?

The canonical example that doesn't make sense is when Alice and Bob want to
communicate privately using Eve as a webmail/chat provider who wants to snoop
in on the communications. Alice and Bob can't just trust Eve to provide a copy
of E2Ejs in a <script> tag on EveMail.com, because then they're trusting Eve
to provide a legitimate encryption implementation, trusting Eve not to log
their keystrokes in JS, etc.

I can understand E2E js as a server-side library in Node (though I suspect it
would be safer to run a battle-hardened library like GPG with node FFI).

But, in client-side web code, how could this ever make sense?

~~~
robmccoll
How about a different scenario?

Eve is not the threat. Eve is going along serving email for Alice and Bob just
fine for quite a while.

Then one day Fred compromises Eve. Fred can dump data directly out of Eve's
database. Depending on how Fred gains access, full disk encryption, database
encryption, row-level encryption, etc. might or might not present themselves
as layers of security that he must bypass. If Fred has compromised the running
service, he will likely have access to the data and any keys, source material
needed to derive the keys, or external decryption mechanisms (HSMs, database-
side services) from within the service itself.

If the messages inside of the database have been encrypted on the clients with
keys not held in the server (E2E), Fred now has another layer of defense in
front of him, only this one requires Fred to inject script into the clients to
scrape the necessary keys. When the client is running Javascript in the
browser, this is obviously easier than on clients deployed through some other
mechanism, but still more difficult than being able to get everything Fred
needs in memory in the server.

Mainly, it's another layer of defense, and if the service is using it for
other clients, a browser-based client would need to have it to function anyway
(even if that weakens the security of the users choosing to use it).

An alternate scenario is that Eve is also not a threat, but is instead a
business that doesn't want the liability of having certain material in the
plain inside of its premises ever.

~~~
chii
> Eve is not the threat.

But Eve is where the attacks are going to come from. Whether it's Eve's
intention, or was under coersion by Fred makes no difference to the end user.
Browser E2E encryption is at best marginally harder to break, but it gives the
user a bigger sense of privacy than it deserves, may be to the detriment of
the unlearned user.

~~~
robmccoll
I would argue that collecting keys from all of the user's browsers and dumping
the database is more difficult than dumping the database alone, and that makes
it worth doing.

If as Fred my window of opportunity before I'm detected is small, I might only
be able to get keys from users that are active within a small window. I may
have to deal with CDN TTLs just to get my code to those users in the first
place. The deployment setup might make it a little harder to change the code
than just modifying a plaintext file on disk on the server (personally the
project I'm working on right now packs static assets into the server binary
making them easy enough for Eve to update, but a bit more effort for Fred). In
more complex scenarios, there may be many things standing between Fred and
injecting code into the browser that aren't in the way of reading the
database.

It really depends on the specifics of the threat that you're modeling for and
how your environment works. For example, if we only focus on scenarios in
which we are concerned about an attacker that has wholly compromised the
service as you are describing here, we would similarly conclude that TLS
serves no purpose as the attacker is already receiving the decrypted data at
the other end of the pipe.

------
the8472
The issue with client-side, in-browser encryption is that you cannot audit or
trust the software. Without fingerprinting/certification of the entire
javascript-source the server could serve a manipulated source code that
exfiltrates data, targeted only at specific users, i.e. not the auditors.
Think NSLs or sufficiently crafty industrial espionage. CSPs do not save you
here.

You can't TOFU in-browser JS, you can't trust audits and if any 3rd-party code
is loaded into the environment you can't trust the entire origin.

The browser is the wrong tool for the job here.

~~~
msy_
Could it be done with a browser extension?

~~~
CiPHPerCoder
You'd think, but everyone I know that explored this option ended up just
implementing desktop software instead (e.g. with Electron).

~~~
tptacek
Part of that is because by the time you're asking an ordinary user (not a
super-opinionated "sophisticate" on HN) to install a Chrome extension, you're
95% of the way towards getting them to install a desktop application anyways,
and that remaining 5% of effort is often worth the extra flexibility the
Electron app gets you.

------
CiPHPerCoder
Usually the first thing I check in a project like this when it ends up on HN
or Reddit is their symmetric cryptography features. Not because of any
particularly scientific reason, but because it's a good heuristic on whether
or not it's worth the time and energy to look at the rest of the code.

Tanker's looks like this:

[https://github.com/TankerHQ/sdk-
js/blob/master/packages/cryp...](https://github.com/TankerHQ/sdk-
js/blob/master/packages/crypto/src/aead.js)

Seems pretty OK to me.

------
marknadal
Is libsodium WASMed for the browser?

WebCrypto is pretty good, altho its API is horrid, SEA is a nice wrapper for
it ( [https://gun.eco/docs/SEA](https://gun.eco/docs/SEA) ).

It would be nice if Tanker exposed the cryptography operations, so it could be
a more re-usable library. Is this possible?

~~~
blastrock
> Is libsodium WASMed for the browser?

It is not WASMed yet, but we are working on it.

> It would be nice if Tanker exposed the cryptography operations, so it could
> be a more re-usable library. Is this possible?

Tanker is more of a high-level library. It focuses on the ease of use, and
tries to be hard to misuse, so it does the key handling and uses fixed
algorithms.

------
hbbio
For the record, we built a similar offering, cf.
[https://github.com/wallix/datapeps-sdk-
js](https://github.com/wallix/datapeps-sdk-js) (in my previous life).

We started the implementation after the Snowden revelations, tied to a web
messaging platform called PEPS but after the sale of the company we realized
that most of the value lied in the E2EE SDK itself, and not the messaging app.

We got there as many prospects were interested in the encryption part, but did
not want yet another messaging platform.

I am still unsure about the market for this (disclaimer: I am no longer at
Wallix, so I am not involved anymore with DataPeps although I created it). It
was a tough sale, even as a part of an existing company with hundreds of
customers. Many people felt the need for privacy, but were not ready to
implement a new product or to involve developers to modify an existing
product.

I do feel though that there is a need for a truly, non-profit, open source
solution that handles E2EE. It would be highly beneficial for the whole
developer ecosystem.

The DataPeps SDK (MIT license) is a good start. The accompanying service is
currently proprietary.

------
alias_neo
Your website and documentation is all a bit opaque.

The title reads like a new encryption library for in the browser but in
reality is an (advert for) encryption service, the SDK is open source because
it requires your backend with its "Trustchain", the wording on the website is
vague about how the Trustchain Private Key is "obtained".

Regarding the service, my main issue is that with an open source SDK you're
aiming at a certain type of people, developers, like many of us, but I see no
mention of the algos used which immediately causes me to lose interest
(between that and the sales/marketing heavy website). If you're really
targeting developers I would suggest losing the marketing babble and get down
to brass tacks.

And finally, if the private key really is generated on your service, we can
just pack up and go home.

What it sounds like you have is a PKI infrastructure with open source SDK and
"end-to-end" encryption of things, as much as end-to-end applies for
keys/trust roots generated anywhere but locally.

If any/all of this is wrong, please clarify.

~~~
blastrock
> how the Trustchain Private Key is "obtained".

The Trustchain private key is generated when you create a Trustchain. It is
generated on _your_ machine. You can try it and create a Trustchain yourself
here: [https://dashboard.tanker.io/](https://dashboard.tanker.io/)

> And finally, if the private key really is generated on your service, we can
> just pack up and go home.

It is not :)

> What it sounds like you have is a PKI infrastructure with open source SDK
> and "end-to-end" encryption of things, as much as end-to-end applies for
> keys/trust roots generated anywhere but locally.

That's pretty much it. The trust root is that Trustchain key, and Tanker never
sees its private part.

> Regarding the service, my main issue is that with an open source SDK you're
> aiming at a certain type of people, developers, like many of us, but I see
> no mention of the algos used which immediately causes me to lose interest
> (between that and the sales/marketing heavy website). If you're really
> targeting developers I would suggest losing the marketing babble and get
> down to brass tacks.

I take note of this. The parts targeted at developers available at the moment
are the documentation, the code examples, and the SDK sources. We will write
and publish something that explains how it works under the hood.

~~~
alias_neo
Thanks for clarifying all that.

It'll really benefit from some clarity on those points in the documentation.

------
aytekin
We have been supporting this feature on our web app for many years:
[https://www.jotform.com/encrypted-forms/](https://www.jotform.com/encrypted-
forms/)

Knowing only you have access to tha data is a good thing. For example, we are
able to host our internal employee feedbacks and reviews on our own forms
without worrying about a sysadmin or database admin having access to it.

I understand the concerns about client side manipulation but that is hard to
do without leaving a trail on our code commit history. Both system and product
changes can only be done by code commits.

You cannot protect systems with a single perfect security solution. You have
to be paranoid and have many layers in your security model. This may not be
the silver bullet, but this greatly enhances the security.

------
_rlx_
[https://docs.tanker.io/latest/guide/device-unlocking/#end-
to...](https://docs.tanker.io/latest/guide/device-unlocking/#end-to-
end_or_zero-trust)

> If you want your app to be fully end-to-end, you can use the lower level >
> unlock mechanisms, which are all end-to-end compliant

So if I want to use the SDK in a "fully" end-to-end secure way, I first need
to implement by myself a secure way to transmit the user root secret (the
unlock key) between the user's devices, and make sure this key is always
accessible so that users don't loose access to their data. This doesn't seem
like an easy task...

~~~
blastrock
No, the unlock key is for the user to keep, and never be transmitted by anyone
else than the user themselves. If you do the transmission, it's not end to end
anymore.

This option is only for users concerned about security, the other unlock
methods are less strong but still provide security.

------
instakill
ELI5: this is an open source library. What is the pricing page on the Tanker
website all about?

~~~
tux3
Seems like it's free for open-source projects, so the pricing should apply to
commercial users. Sort of similar to what Qt does.

~~~
detaro
If it is under Apache 2 license as the repo claims, very few commercial
projects are going to have an issue with using it under the open-source terms.
You can't say "this is open-source under license X, but you can't use it
commercially!" (well, you can, but you are creating your own license that's
not compatible with open source projects either). Qt solves this by being
under license(s) not all commercial users want to comply with, and selling
support etc.

It seems what they are selling is not the software, but services it can use to
manage exchange between users etc.

~~~
tux3
There's a server component that's not on Tanker's Github, so commercial users
probably can't start using the SDK without telling anyone.

~~~
detaro
They can legally use the SDK under the open source terms without paying if
they find a way of using it without Tanker's servers. For the server access,
they need to pay, thus that's what they're selling.

In contrast Qt is selling licenses to the code, not access to a hosted
service.

------
nullwasamistake
E2E encryption in JS in browser will never be secure. In a client with shared
threads and untrusted content on the page it will always be vulnerable to
timing attacks. It's unrealistic to create a constant-time implementation in
JavaScript.

For node/backend this is great but please don't use it on a public site.

~~~
y96V89C668e7Q74
Genuine question - is this what you're referring to? Very curious.

[https://www.usenix.org/system/files/conference/usenixsecurit...](https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-vila.pdf)

~~~
nullwasamistake
Hadn't heard of it actually, but side channels have been an issue in browser
security for a long time.

Spectre caused a lot of changes in JS like disabling high precision clocks.
But I'm afraid clock proxies are everywhere. The API surface is gigantic and
all you need is a single call that reliably executes in constant time on the
samr thread

------
TankerHQ
Tanker is an open-source client SDK that can be embedded in any application.
Encrypt data, share it between users, create groups, etc.

The SDK handles key exchanges, cryptographic operations, and identity
verification for you.

Also available for iOS and Android!

~~~
dieblur
What algorithms? Pretty bare README for a cryptography project.

~~~
blastrock
Tanker developer here. We use libsodium as our underlying cryptographic
library. It uses XChacha20/Poly1305 for symmetric encryption, Curve25519 for
asymmetric encryption and signature, and Blake2 for hashing.

~~~
dieblur
Why would I use your library over the tried and true
[https://github.com/dchest/tweetnacl-js](https://github.com/dchest/tweetnacl-
js) ?

~~~
blastrock
TweetNaCl is roughly equivalent to libsodium, on which Tanker builds. Tanker
is easier to integrate into your app because it takes care of key sharing,
multi-devices, user group managment, etc. These are all things you would have
to handle by yourself using just a cryptographic library like TweetNaCl.

