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

FileKit: An open source end-to-end encrypted cloud storage service in JavaScript

github.com

Post reply on HN
Print view View original

11–20 of 34 posts

Re: FileKit: An open source end-to-end encrypted cloud storage service in JavaScript

#11

Post by espadrine »

tptacek wrote: post #6
edwardr wrote: post #5

Earlier quoted context omitted.

Browser crypto has come a long way. With libraries like libsodium and proper implementation I think it’s drastically better than at the time of those articles (2013 and 2011). Source: we also write encryption libraries and have a free implementation of our browser sdk at https://share.labs.tozny.com

No, it's not drastically better than it was in 2013. People have done lots of things with browser cryptography, that's true. But none of what they've done addresses or mitigates the central flaw of browser javascript cryptography, which is that to use it, you have to continuously and durably trust the server. If you're doing that, you might as well just do the cryptography serverside.

My understanding of FileKit is that you do trust the Tanker server, but only for delivering JS and handling identities.

It only contains public keys and encrypted DEKs (data encryption keys); see this image: https://docs.tanker.io/filekit/latest/going-further/file-enc...

The file content should therefore only be accessible by holders of private keys for which the file was encrypted.

Re: FileKit: An open source end-to-end encrypted cloud storage service in JavaScript

#12

Post by tptacek »

espadrine wrote: post #11
tptacek wrote: post #6

Earlier quoted context omitted.

No, it's not drastically better than it was in 2013. People have done lots of things with browser cryptography, that's true. But none of what they've done addresses or mitigates the central flaw of browser javascript cryptography, which is that to use it, you have to continuously and durably trust the server. If you're doing that, you might as well just do the cryptography serverside.

My understanding of FileKit is that you do trust the Tanker server, but only for delivering JS and handling identities. It only contains public keys and encrypted DEKs (data encryption keys); see this image: https://docs.tanker.io/filekit/latest/going-further/file-enc... The file content should therefore only be accessible by holders of private keys for which the file was encrypted.

There's no difference between trusting the server to deliver Javascript cryptography source code and trusting the server with your secrets. The server can just deliver code (in a number of different ways) to compromise those secrets.

Re: FileKit: An open source end-to-end encrypted cloud storage service in JavaScript

#13

Post by Tomte »

tzs wrote: post #8
wglb wrote: post #3

Doing cryptography in the browser is a bad idea: https://tonyarcieri.com/whats-wrong-with-webcrypto Also https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...

The author of that second one is a frequent HN commentator. Let me attempt to summon him to this thread to see if he has anything more to say, since that was written in 2011 so might be a bit out date. Begin summoning ritual... • It's easy to secure email with GPG. • DNSSEC is a state of the art design that you should adopt on your website as soon as possible, to make up for the deficiencies of TLS. • You should use…

Something culinary is missing... you should pour those big-corporate MGP Whiskeys down the drain and get something from a small distillery. Or sous-vide is overrated, just a way to have plastic seep into your dinner.

(spoken without much experience in either)

Re: FileKit: An open source end-to-end encrypted cloud storage service in JavaScript

#14

Post by belenos46 »

tptacek wrote: post #9
tzs wrote: post #8

Earlier quoted context omitted.

The author of that second one is a frequent HN commentator. Let me attempt to summon him to this thread to see if he has anything more to say, since that was written in 2011 so might be a bit out date. Begin summoning ritual... • It's easy to secure email with GPG. • DNSSEC is a state of the art design that you should adopt on your website as soon as possible, to make up for the deficiencies of TLS. • You should use…

I only have an alert set up on DNSSEC, for what it's worth. I won't notice most GPG or /dev/random arguments. (Thankfully, the /dev/random debate is moribund).

I'm just tickled pink that it actually worked. It made my workday.

Re: FileKit: An open source end-to-end encrypted cloud storage service in JavaScript

#15

Post by devoply »

tptacek wrote: post #6
edwardr wrote: post #5

Earlier quoted context omitted.

Browser crypto has come a long way. With libraries like libsodium and proper implementation I think it’s drastically better than at the time of those articles (2013 and 2011). Source: we also write encryption libraries and have a free implementation of our browser sdk at https://share.labs.tozny.com

No, it's not drastically better than it was in 2013. People have done lots of things with browser cryptography, that's true. But none of what they've done addresses or mitigates the central flaw of browser javascript cryptography, which is that to use it, you have to continuously and durably trust the server. If you're doing that, you might as well just do the cryptography serverside.

I wonder why browsers don't build their own browser api for file and mail crypto ... and that way you don't have to trust the server. And you can verify that the server is using browser crypto.

Re: FileKit: An open source end-to-end encrypted cloud storage service in JavaScript

#16

Post by danShumway »

tptacek wrote: post #12
espadrine wrote: post #11

Earlier quoted context omitted.

My understanding of FileKit is that you do trust the Tanker server, but only for delivering JS and handling identities. It only contains public keys and encrypted DEKs (data encryption keys); see this image: https://docs.tanker.io/filekit/latest/going-further/file-enc... The file content should therefore only be accessible by holders of private keys for which the file was encrypted.

There's no difference between trusting the server to deliver Javascript cryptography source code and trusting the server with your secrets. The server can just deliver code (in a number of different ways) to compromise those secrets.

Well... there's no technical difference.

My understanding from the Apple/FBI fiasco is that it's an open question whether the US government is legally able to compel you to write and deliver custom code to your clients. But any local judge can issue you a warrant to hand over encrypted customer data that you're holding the key to.

But IANAL, maybe my take on that is overly simplistic.

Re: FileKit: An open source end-to-end encrypted cloud storage service in JavaScript

#17

Post by adamredwoods »

devoply wrote: post #15
tptacek wrote: post #6

Earlier quoted context omitted.

No, it's not drastically better than it was in 2013. People have done lots of things with browser cryptography, that's true. But none of what they've done addresses or mitigates the central flaw of browser javascript cryptography, which is that to use it, you have to continuously and durably trust the server. If you're doing that, you might as well just do the cryptography serverside.

I wonder why browsers don't build their own browser api for file and mail crypto ... and that way you don't have to trust the server. And you can verify that the server is using browser crypto.

I wonder if we'd even need the server at any capacity for encryption by that point.

Re: FileKit: An open source end-to-end encrypted cloud storage service in JavaScript

#19

Post by dboreham »

tptacek wrote: post #6
edwardr wrote: post #5

Earlier quoted context omitted.

Browser crypto has come a long way. With libraries like libsodium and proper implementation I think it’s drastically better than at the time of those articles (2013 and 2011). Source: we also write encryption libraries and have a free implementation of our browser sdk at https://share.labs.tozny.com

No, it's not drastically better than it was in 2013. People have done lots of things with browser cryptography, that's true. But none of what they've done addresses or mitigates the central flaw of browser javascript cryptography, which is that to use it, you have to continuously and durably trust the server. If you're doing that, you might as well just do the cryptography serverside.

Wondering...browsers do seem to be able to do secure crypto in two existing scenarios: when presenting a client TLS certificate; and when performing authentication via WebAuthn in conjunction with U2F. Would it be possible to re-purpose either of those mechanisms to do other potentially useful secure crypto (e.g. sign blockchain transactions)?
Post reply on HN