If Signal database leaks, can somebody bruteforce access into my contact's chat history?

Question

Recently Signal started forcing users to create a pin. I'm curious about the feature - doesn't it make Signal less secure if their database gets compromised? In other words, suppose that I'm chatting with someone from my family and they set their pin to 1234. If Signal's database leaks, is it possible to brute-force passwords of my relatives and - as a result - see logs of their conversations with me?

Answer 1

There is a Signal blog post titled "Improving Registration Lock with Secure Value Recovery" that partially addresses this question:

By transitioning Registration Lock PINs to Secure Value Recovery, we can restrict offline brute force access for those PINs.

To understand how Secure Vault Recovery works under the hood, another post titled "Technology Preview for secure value recovery" must be read. Here's how the process works from a high level, according to the article, with some key notes included:

1. Clients use Argon2 to stretch the passphrase or PIN into a 32-byte key.
2. Two additional variables are generated from this stretched key: an authentication token, and (combined with a randomly generated input) a master key. This master key can then be used to derive additional application keys used to protect data stored in “the cloud.”
3. The master key incorporates c2 (256 bits of secure random data), which requires limited access to be resilient to offline brute force attacks.
4. auth_key, part of what is used to reconstruct the master_key, is put into a secure enclave, which is "isolated from the host operating system and kernel," with c2, which enforces a maximum failed guess count. "For example, if we set the maximum failed guess count to 5, then an attacker who obtained access to the service (or the service operator) would only get 5 password guesses rather than an unlimited number of guesses that they could attempt as fast as their hardware would allow."
5. Finally, because this is provisioned by SGX, and SGX supports remote attestation, "clients can transmit these values into the enclave over an encrypted channel with the assurance that they are actually being stored and processed by an enclave rather than someone pretending to be one."

The article goes further down the rabbit hole to address concerns that spring up with this approach, but this seems to me to be a good starting point.