3 ms·

if it's anything like what other big players are doing: the attempts are limited and the code will destroy its knowledge of the key once you reach this limit.

if it's anything like what other big players are doing: the attempts are limited and the code will destroy its knowledge of the key once you reach this limit. Looking at the code quickly I see that nothing is documented and it's not clear what code gets executed there. So good luck understanding what they're doing. But it seems to be using Raft, probably to bring several HSMs to consensus on what's the state of the number of attempts. And it does seem to erase stuff if you reach some threshold of attempts: https://github.com/signalapp/SecureValueRecovery/blob/00d023abcaf16d7ea664f9e6f1dd8b2aff4da915/enclave/kbupd_enclave/src/service/replica/partition_data.rs#L518 https://github.com/signalapp/SecureValueRecovery/blob/00d023... My follow up question is: what prevents someone from destroying your account's backup key by entering wrong PINs for your account?

kijiki 6y ago
That isn't quite how it is implemented, there are no HSMs, we use SGX for that function instead. See my reply to Josh's follow up for details. You need a random id not the phone number, so other users can't do guesses unless they get that random id somehow. The ID is stored on the phone, and if you lose it, when you reinstall Signal, the signal server will give it to you after SMS phone # verification. A sim-jacker could nuke your key, but that seems like a lot of work for griefing. Signal of course, has the plaintext random id, so they could nuke your backup, but there are tons of ways Signal can DoS attack their own service. Stopping paying for the servers, for one.