3

I am reading sync.com's white paper, and two questions arise.

  1. Use of the asymmetric key.

    The white paper states the following. However, I am confused why the asymmetric key is necessary and how it is really used. In my mind, since file encryption/decryption all happen on the client side, you would only need a symmetric key that is locked by the password.

    The only reason that I can think of for using an asymmetric key is to enable file sharing. With an asymmetric key, everyone can keep the public key and use it to encrypt contents. When we share a file with another user, this comes in handy, as I (my client software) can encrypt the shared content for another user using their public key, without knowledge of their private key.

    Private key A randomly generated 2048 bit RSA private encryption key serves as the basis for all encryption at Sync. During account creation, a unique private key is generated and encrypted with 256 bit AES GCM, locked with the user’s password. This takes place client-side, within the web browser or app. PBKDF2 key stretching with a high iteration count is used to help make weak passwords more cryptographically secure. Encrypted private keys are stored on Sync’s servers, and downloaded and decrypted locally by the desktop app, web panel or mobile apps after successful authentication. At no time does Sync have access to a user’s private key.

  2. Authentication

    The white paper states the following. In the last sentence, it says, "the server authenticates against the hash, but at no time is the hash itself stored." I wonder how is this possible. To authenticate, the server will have to compare the salted, hashed password with something in its database. This says the hash is stored on the server.

    A username and password is required to authenticate and log into the Sync desktop app, the Sync web panel, and Sync’s mobile apps. During authentication, a BCRYPT hash of the user inputted password is generated locally on the computer or device, using a unique salt that is stored on the server. Bcrypt is a one-way hashing mechanism, meaning the hash cannot be unhashed or deciphered. The benefit of bcrypt is that it is slow by-design, which prevents brute force or rainbow table attacks. At no time is the user’s actual password transmitted or stored. The server authenticates against the hash, but at no time is the hash itself stored. Successful authentication allows the app to download the user’s encrypted private key, which is then decrypted locally with the user’s actual password.

Tom Bennett
  • 132
  • 7

2 Answers2

2

Use of the asymmetric key.

Sync uses hybrid encryption, i.e. each file is protected by its unique symmetric key while the symmetric keys are protected by the common asymmetric key. To cite from their paper: "Sync utilizes a unique 256 bit AES GCM data key on each file, locked with the user’s 2048 bit RSA key ...".

"the server authenticates against the hash, but at no time is the hash itself stored."

I'm not fully sure what this means. But the hash send by the server is basically a stretched user password. It might be that the server is not storing the hash for comparison on the server but a hash of the hash or similar - which is sufficient for comparison too and which does not require storing the original hash (stretched password). But this specific detail is unfortunately missing from the white paper.

Still, the most one could get if this authentication fails is the encrypted private key, which is useless without the original password. So user authentication before getting the key is more an additional layer of protection, but not the main protection.

Steffen Ullrich
  • 190,458
  • 29
  • 381
  • 434
  • Great point that the attacker won't get very far even if they can get through the authentication. – Tom Bennett Dec 18 '22 at 22:59
  • I agree a hash of hash is probably what it means. I am reading LastPass's white paper, which is clear about using a hash of the hash for authentication. So I guess it may be similar. – Tom Bennett Dec 19 '22 at 18:27
2

With regard to the use of asymmetric keys, I think you're correct that this is to enable file sharing, as described on p4 of the white paper, probably as per some method similar to this.

The authentication system seems to be some variation of PAKE/SRP, where the client proves that it has knowledge of a password, without sending the password (or password equivalent data) over the encrypted tunnel, and without the server storing the password (or password equivalent data).

Notwithstanding, being that all of the above client-side crypto is implemented using in-browser client-side scripting - the security of the entire system is vulnerable to the infamous browser crypto chicken and egg problem - i.e. if you can't trust the server with your secrets, then how can you trust the server to serve you secure crypto code? If a server admin at sync.com were to 'go rogue' (or if sync.com's server were to be breached by an attacker), the bad actor could simply modify the client-side crypto code served by there server, which runs in the user's browser, so that it exfiltrates the user's password and/or private key, and sends these back to the bad actor's server.

mti2935
  • 21,098
  • 2
  • 47
  • 66
  • 1
    I briefly looked into PAKE/SRP. It reminds me of the Diffie-Hellman key exchange. To mutually authenticate without revealing the password, I feel it's also possible to use the plain old challenge/response based on a pair of public/secret key - e.g. the server holds a public key, derived from the secret key that is derived from the password. The server sends the client an encrypted challenge, which the client will have to decrypt and send the plaintext back. Similar for the other direction. But the whitepaper didn't mention any of these. Great point on the browser vulnerability problem. – Tom Bennett Dec 18 '22 at 22:57
  • 1
    @TomBennett, Yes, in some respects, PAKE/SRP is similar to good old public key authentication. But, if the user's private key is derived from a password using a PDF (e.g. PBKDF2, Argon2, etc.), then some protocol would need to be worked out for the client first getting the salt for the user from the server, then proceeding with the client-side hashing, and finally authenticating with the server - and at that point, this begins to look very much like PAKE/SRP. – mti2935 Dec 19 '22 at 01:44
  • 1
    PAKE/SRP also offers some additional benefits as well, such as the client and the server mutually authenticating each other (even over an insecure channel, and with a MITM tampering with the connection), and the client and the server end up with a shared secret that can be used to build a secure channel after the process completes. See https://security.stackexchange.com/questions/254820/to-lighten-server-load-is-hashing-a-client-side-argon2-hashed-password-with-sha for more info. – mti2935 Dec 19 '22 at 01:46
  • 1
    Yes, indeed PAKE/SRP allows the client and server to exchange a secret over an insecure channel. It appears the same can be achieved with modified private/public key authentication: 1) server generates a random k1, encrypts it with the client's public key, and sends it over; 2) client decrypts it, appends a random k2, re-encrypts it with the server's public and send it back; and 3) server decrypts K2, re-encrypts it with the client's public key and sends it back to the client. It appears to have exchanged a secret (k1,k2) over an insecure channel while authenticating each other. – Tom Bennett Dec 19 '22 at 04:26
  • 1
    @TomBennett I agree, the process you describe provides mutual authentication and results in a shared secret. This is essentially the process that takes place when client certificates are used in TLS. However this requires the client to store a private key (for step 2). Storing a private key is more difficult than remembering a password for most users. Alternatively, a private key can be derived from a password (using PBDKF2, Argon2, etc.), but this requires a salt. So then, the problem becomes - where is the salt stored? – mti2935 Dec 19 '22 at 12:24
  • 1
    I think we can generate a new salt every time a new password is entered and store the salt in plaintext. Because the key derivation function is one way, there should be no harm in storing it in plaintext, shouldn't it? – Tom Bennett Dec 19 '22 at 15:50
  • 1
    @TomBennett Yes, the salt can be stored on the server in plaintext. So, the protocol would be: 1) client enters username, 2) client requests salt for username from server, 3) client derives private key using KDF(password, salt), 4) server sends challenge, 5) client completes challenge using private key and sends completed challenge back to server. 6) server authenticates client using client's public key and correctly completed challenge. At this point, the protocol starts to look similar to SRP. See https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol – mti2935 Dec 19 '22 at 16:04
  • 1
    Yep, I agree! Thanks a lot. And thanks for introducing the SRP. The math is very interesting. – Tom Bennett Dec 19 '22 at 16:34
  • 1
    LastPass uses the user name as the salt, which is a convenient choice. – Tom Bennett Dec 19 '22 at 18:23
  • 1
    Interesting idea to use the username as a salt. FYI, Another useful property of SRP is that the server authenticates itself to the client (using its knowledge of the password verifier). – mti2935 Dec 20 '22 at 10:38
  • Yeah I saw that. Very interesting. – Tom Bennett Dec 20 '22 at 10:51