Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tanker: End-to-End Encryption SDK for JavaScript

github.com

Post reply on HN
Print view View original

51–60 of 100 posts

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

#51

Post by zachrose »

kevin_thibedeau wrote: post #49
penagwin wrote: post #43

Earlier quoted context omitted.

cough it doesn't really matter cough Innovator - To help communicate with other HN readers, I created an analogy about mountain bikes and their tire size! HN - Not a good analogy to compare tire sizes for mountain biking to information security in Javascript. You should be comparing bicycle locks. Innovator - My analogy still makes sense though? Consider my physical safety to be roughly equivalent to information secu…

What color is the bike? I suggest camo for added security.

Forget the bike, what color of shed are you going to keep it in?

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

#52

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

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

#53

Post by michaelchisari »

msy_ wrote: post #5
the8472 wrote: post #4

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 tr…

Could it be done with a browser extension?

Ideally, it would be something the browser supported internally (without external js or plugins) with very minimal javascript entrypoints to decode/encode.

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

#54

Post by tptacek »

y96V89C668e7Q74 wrote: post #40
dfabulich wrote: post #16

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 tag on EveMail.com…

As others have posted, JS is much more than script tags in the browser. There's also React Native, Electron, Node, and many other less well known platforms for JS outside of the browser. Additionally, browser E2E encryption depends on trusting the provider just as WhatsApp or iMesssage depend on trusting Facebook or Apple. The browser is really just another delivery mechanism for code that runs on the client and you…

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

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

#55

Post by dieblur »

blastrock wrote: post #15
dieblur wrote: post #11

Earlier quoted context omitted.

What algorithms? Pretty bare README for a cryptography project.

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 ?

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

#56

Post by skrebbel »

the8472 wrote: post #47
skrebbel wrote: post #35

Earlier quoted context omitted.

It might be great as an alternative to a "we store all data encrypted, pinky promise!" type of model, where eg you encrypt all messages on the backend before storing it in the DB, to reduce the potential impact of breaches, rogue employees, etc. I kind of like it for that, to be honest. There's a difference between trusting the good intentions of a company as a whole, and the good intentions and flawless skill of eve…

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?

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

#57

Post by chrismeller »

y96V89C668e7Q74 wrote: post #40
dfabulich wrote: post #16

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 tag on EveMail.com…

As others have posted, JS is much more than script tags in the browser. There's also React Native, Electron, Node, and many other less well known platforms for JS outside of the browser. Additionally, browser E2E encryption depends on trusting the provider just as WhatsApp or iMesssage depend on trusting Facebook or Apple. The browser is really just another delivery mechanism for code that runs on the client and you…

The only argument you can possibly make here is for Node. Any of the other examples can easily be decompiled or reversed.

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

#58

Post by y96V89C668e7Q74 »

chrismeller wrote: post #57
y96V89C668e7Q74 wrote: post #40

Earlier quoted context omitted.

As others have posted, JS is much more than script tags in the browser. There's also React Native, Electron, Node, and many other less well known platforms for JS outside of the browser. Additionally, browser E2E encryption depends on trusting the provider just as WhatsApp or iMesssage depend on trusting Facebook or Apple. The browser is really just another delivery mechanism for code that runs on the client and you…

The only argument you can possibly make here is for Node. Any of the other examples can easily be decompiled or reversed.

That doesn't make it any less secure, there are plenty of open source cryptography libraries and apps like Signal. Closed source doesn't equate to secure.

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

#59

Post by y96V89C668e7Q74 »

tptacek wrote: post #54
y96V89C668e7Q74 wrote: post #40

Earlier quoted context omitted.

As others have posted, JS is much more than script tags in the browser. There's also React Native, Electron, Node, and many other less well known platforms for JS outside of the browser. Additionally, browser E2E encryption depends on trusting the provider just as WhatsApp or iMesssage depend on trusting Facebook or Apple. The browser is really just another delivery mechanism for code that runs on the client and you…

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.

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

#60

Post by buu700 »

dfabulich wrote: post #16

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 tag on EveMail.com…

We aren't using Tanker, but it is possible to do this securely: https://www.cyph.com/websign
Post reply on HN