Why does Signal repeatedly hash the secure passphrase? Background: I'm working on creating a small program to extract my messages from Signal's newly-added (beta) encrypted backup feature.

In the Signal codebase for their Android app, I noticed that instead of just hashing both the salt and passphrase once, they repeatedly hash it 250,000 times.

MessageDigest digest = MessageDigest.getInstance("SHA-512");
byte[]        input  = passphrase.replace(" ", "").getBytes();
byte[]        hash   = input;

if (salt != null) digest.update(salt);

for (int i=0;i&lt;250000;i++) {
    if (i % 1000 == 0) { EventBus.getDefault().post(new BackupEvent(BackupEvent.Type.PROGRESS, 0)); }
    digest.update(hash);
    hash = digest.digest(input);
}

return ByteUtil.trim(hash, 32);


(Source code can be found here)

I don't understand what benefits this offers over something that conceptually does:

sha512sum(sha512sum(concat(salt, passphrase)))


Am I correct in assuming that this does not add any extra security? Why exactly has this been done?



Additional Information:   

The password for the backup is generated here and is 30 bytes long and then set contextually on line 37 of that file. This code was added in the commit 22 days ago, when encrypted backup was added and is currently only visible in the beta version of the app.
Cryptographic hashes are designed to be fast and collision resistant. It turns out that when hashing passwords, it is more secure to have a slow hash function. One way to make a fast hash function slow is to iterate it. Like is done here.

Think about it this way. If an attacker is able to compute a million hash calculations in a second, if you only ran your password through the hash function once, they would be able to attempt a million guesses each second. On the other hand, if you iterate the hash function 250,000 times, now the attacker can only make 4 guesses a second. That is a pretty substantial reduction and increases the amount of work the attacker has to do. If users were really good at choosing passwords, this might not matter, but the fact of the matter is that users are not good at choosing good passwords. Making the hash function slow helps in that regard.

In the case of Signal, it looks like encrypted backups is a beta-feature. Looking at one screenshot, it appears that the backup key is not user chosen. It is likely (haven't dug through the code) a 30 digit random number. That means it has about 100 bits of entropy at best. My guess is that the designers still wanted a slow hash function for the reasons listed above, even though the passphrase was not user chosen. Making it slow is a good trade-off for having less entropy. They could have made the random number longer to get more entropy (256 bits maybe), but that would have made the backup key that the user has to store much longer.