Live data from Hacker News

Tanker: End-to-End Encryption SDK for JavaScript

github.com

61–70 of 100 posts

Re: Tanker: End-to-End Encryption SDK for JavaScript

#61
post #47

Earlier quoted context omitted.

I think one issue is that for anyone with a cryptography/information security background "e2e encryption" evokes a very strong security claim where you treat the whole service provider as potential eavesdropper against which the protocol protects you, only conditional on mathematical proofs. Carving out a much more complicated boundary around various kinds of lapses on the other hand muddies the water. It can still m…

Good point. Is there a better name for this that doesn't hint at said security claim?

Just "client side encryption", don't mention or even explicitly disavow "end-to-end" claims.

Re: Tanker: End-to-End Encryption SDK for JavaScript

#62
post #54

Earlier quoted context omitted.

This library is very explicitly targeted to browsers and makes repeated mention of compatibility testing for them, so the parent question is on point.

No because I'm also making the argument that the browser is not much less secure than the other JS platforms.

That argument is also quite faulty, but I'm only engaging with the other argument you made.

Re: Tanker: End-to-End Encryption SDK for JavaScript

#63
post #54

Earlier quoted context omitted.

This library is very explicitly targeted to browsers and makes repeated mention of compatibility testing for them, so the parent question is on point.

No because I'm also making the argument that the browser is not much less secure than the other JS platforms.

[deleted]

Re: Tanker: End-to-End Encryption SDK for JavaScript

#64
post #62

Earlier quoted context omitted.

No because I'm also making the argument that the browser is not much less secure than the other JS platforms.

That argument is also quite faulty, but I'm only engaging with the other argument you made.

Can you explain why it is faulty?

Re: Tanker: End-to-End Encryption SDK for JavaScript

#65

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…

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

Yeah, thankfully that key is generated client-side (in the browser) when you register. Seems pretty end-to-end to me.

(And sure, you could always worry that the server will serve you malicious JS while you're registering to steal your client-side-generated key, but that would be pretty suicidal for any company, not a very realistic threat!)

Re: Tanker: End-to-End Encryption SDK for JavaScript

#67

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…

> 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/

> 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.

Re: Tanker: End-to-End Encryption SDK for JavaScript

#68

Earlier quoted context omitted.

The keys are generated client-side, and encryption is done client-side, the encrypted data is then sent to the app. On sharing, the key is encrypted for the recipient and sent to them through the Tanker server. Neither Tanker nor the app can see the clear data or keys.

This doesn’t answer the question. How come the app cannot see the keys? What about the key used to encrypt the client side key?

This really does answer the question, spot on. The client side app does see the key(s) but it does not send them to the server. This is how E2E encryption works, browser or otherwise.

I'm not sure specifically how Tanker is storing the client-side keys. Generally the client-side keys would be encrypted using an OS-level keychain.

Re: Tanker: End-to-End Encryption SDK for JavaScript

#69
post #50

Earlier quoted context omitted.

More like: Innovator - My fuse is blown so I'll replace it with a copper tube to get it to work. HN - That's a bad idea, it's a fire hazard and you're putting yourself at risk. Innovator - HN is full of no fun pendants. -- It's in-browser JS encryption we're talking about. You should not trust it for many, many reasons.

You're not a real pedant until you can spell it correctly. (Who says we're not fun?)

Pendant is spelled correctly. After all we might be wearing charms against fun.

Re: Tanker: End-to-End Encryption SDK for JavaScript

#70
post #55

Earlier quoted context omitted.

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.

Why would I use your library over the tried and true https://github.com/dchest/tweetnacl-js ?

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.
Post reply on HN