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

91–100 of 100 posts

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

#91

Post by burtonator »

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…

Here's an example... when you validate the client and run a native app.

What we did was that we built out a generic datastore system which supports any storage provider backend.

https://getpolarized.io/2019/03/22/portable-datastores-and-p...

But the app is downloaded. It's not just a web app that could be changed on you.

If it's something that's open source and you download it you have less of an issue with people swapping out the JS on you.

The idea in this situation is when you store your docs it's encrypted before we even see the data.

This way you don't have to trust us. No trust required. We could even be a hostile actor and as long as your code is legit you're good to go.

I like this honestly as I don't have to rely on our customers trusting us. We literally CAN NOT see your data.

The main issue is getting keys between machines though. Firefox has an interesting strategy for that but I haven't had time to dive into it yet.

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

#92

Post by robmccoll »

chii wrote: post #90
robmccoll wrote: post #89

Earlier quoted context omitted.

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…

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

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.

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

#93

Post by itslennysfault »

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…

You can use subresource integrity in the script tag which uses a sha hash to confirm the script is what is designated in the html. However, the html could be changed in transit so the only real way this can work is if you do that AND expose the sha hash to the user who has the last known valid sha hash locally that they can manually check against. It's not pretty, but it works.

https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

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

#94

Post by alias_neo »

blastrock wrote: post #67
alias_neo wrote: post #52

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

Thanks for clarifying all that.

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

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

#95

Post by alias_neo »

tux3 wrote: post #65
alias_neo wrote: post #52

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…

Yeah it's sounds reasonable within those constraints given the clarification above.

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

#96

Post by Aeolun »

robmccoll wrote: post #89
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…

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…

Defense in depth?

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

#97

Post by aytekin »

We have been supporting this feature on our web app for many years: 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.

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

#98

Post by btown »

robmccoll wrote: post #89
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…

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…

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

One great example of this Eve is https://mega.nz - by design their servers never have access to the encryption key for any uploaded file, and files are shared by including said key in the hash of the URL. This is done for perfect legal deniability of any material on the site. As long as you trust Mega to not alter their code (you can defend-in-depth against this with various methods, including running an open-source client), and you send sharing links only to trusted parties, the content of your data cannot be detected.

https://mega.nz/SecurityWhitepaper.pdf

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

#99

Post by dmerej »

t2riRXawYxLGGYb wrote: post #68
ricardobeat wrote: post #46

Earlier quoted context omitted.

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.

Hi, other Tanker dev here. In the browser, we use IndexedDB (via dexie). Keys are encrypted using a secret that has to be provided when starting a Tanker session.

On mobile we use an SQLCipher DB encrypted with the same secret.

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

#100

Post by nullwasamistake »

y96V89C668e7Q74 wrote: post #84
nullwasamistake wrote: post #76

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.

Genuine question - is this what you're referring to? Very curious. https://www.usenix.org/system/files/conference/usenixsecurit...

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

Post reply on HN