1

It is completely clear how desktop and mobile platforms for sync.com allow zero knowledge. However, it blows my mind when I try to understand how "Zero Knowledge" could be theoretically possible when using a browser, i.e. web application upload.

So I login to sync.com with Chrome. Then I hit upload a file button, and a file from my PC is getting uploaded and encrypted on the fly by the browser? Then the browser must know my encryption key, i.e. my login password! Does this mean the browser (and the sync.com) is keeping my login credentials while I'm logged in? As far as I know the credentials should not be kept like this, the modern practice is JWT token or something.

Anyway, does a browser even have such a complicated encryption capability (comparable with the desktop app), or are my files being uploaded to the server and encrypted there? Either way that would not be a zero knowledge.

roy.stultiens
  • 138
  • 8
user231744
  • 11
  • 2
  • 2
    Of course the browser knows your password. You are typing your password into it. It's the same with desktop and mobile applications. They all know your password. –  Apr 09 '20 at 07:13

1 Answers1

3

This is not how "zero knowledge" works.

Zero knowledge is on the context of your service provider, not the entire Universe. Being a Zero Knowledge Provider means they don't have and can't have the keys to unlock the data they host. In those cases, even if someone manages to get your files (stealing, leaking, or by government order), your data is encrypted and the provider cannot decrypt even by law, coercion, or financial interest.

In this cases, usually the application generates a random symmetric key, and an asymmetric key derived from your password. It used the asymmetric key to encrypt the symmetric, and used the symmetric key to encrypt your data. The encrypted symmetric key and the data are uploaded together. The provider only gets an encrypted key, and encrypted data with a key they don't have.

To decrypt things later, the application asks your password, uses it to derive the asymmetric key, downloads both the symmetric key and the data, decrypts the symmetric key, and uses it to decrypt the data.

The browser knows your key as long as you are logged in, as most of secure applications will invalidate the data on logout. Your browser (or desktop application, or Excel macro) must have the key, or they won't be able to encrypt or decrypt your data.

And a browser can encrypt things very fast, thanks to WebASM, so there's really no noticeable difference in speed unless you are encrypting lots (more than GBs) of data.

ThoriumBR
  • 50,648
  • 13
  • 127
  • 142
  • 2
    This process is explained in sync.com's whitepaper at https://www.sync.com/pdf/sync-privacy-whitepaper.pdf. – mti2935 Apr 09 '20 at 21:13
  • 2
    Of course, there's nothing to stop the providers of the service from going rogue. At any time, they can change the client side scripting, so that it captures the user's password and sends it to their servers. Then, they can derive the encryption key from the password, and proceed to decrypt all of your files. This is a fundamental problem with browser crypto, sometimes referred to as the 'chicken and egg' problem. If you can't trust the server with your secrets, then how can you trust the server to serve you secure code? – mti2935 Apr 10 '20 at 00:52
  • @mti2935 Surely (virtually) the same problem exists with a desktop app? At any time they could issue an update that steals your password. The main advantage (from the POV of stealing credentials) with a browser app is that you can do a "drive-by" code-change slightly more easily (normally deploy "safe" code, issue dodgy code on one visit, then return to safe code in case anyone audits it). – TripeHound Sep 07 '20 at 15:54
  • @TripeHound See answer by `nobody` at https://security.stackexchange.com/questions/238011/why-signal-doesnt-have-web-client for an excellent explanation as to why these issues are much more of a threat in a web app than they are in an app or desktop client. – mti2935 Sep 07 '20 at 19:16