# How many possibilities can today's computers check (per second) in a SHA512 hash of a 50-byte-long random entry? [closed]

The problem I want to avoid is "brute force" attacks against a database. So if I add a 50-byte-long cryptographically random salt to my information (which I don't need to retrieve, just its hash) - is it secure enough?

I know the answer is inexact - It depends on if it's a supercomputer, or a PC etc. I want to get a general idea - can a supercomputer go through 10^9 of them in a second? 10^20? Will it take a PC a year to go through all of them? Be vague.

EDIT: The salt will remain in the hashed result only.

• Hi @ispiro, welcome to Information Security. The answers to this question, even if it made sense to answer at all, would by necessity be out of date as soon as they are written... Besides, as the answer below explains, this doesn't really make sense, as I think you may have misunderstood how these mechanisms work. But please hang around, pick up some more details, and maybe we'll be able to help you more with your next question...! – AviD Aug 6 '12 at 17:09

## 1 Answer

The purpose of a salt is not to make computing the hash slower, it's to prevent rainbow tables from being useful. A single iteration of SHA512 is way too fast to be useful against bruteforcing attacks.

On a decent GPU, you can do ~100M hashes/sec (new link) with SHA512. Multiply this for systems with multiple GPUs. With a slow KDF such as bcrypt, you can tweak the iteration count to be more suitable. You want something around ~0.3s/hash for a good security margin.

Keep in mind that 50 bytes is 400 bits, or a keyspace of 2^400. You're almost guaranteed to find a collision in SHA512 if you manage to compute 2^400 hashes. However, the attacker isn't trying to guess the salt. What you should be worried about is an attacker cracking the hashes when they already know the salt.

The solution is use PBKDF2, bcrypt, or scrypt, and store the salt in plaintext in the database.

Update:

It looks like you're trying to implement your own scheme. Please do not do this. There are two widely accepted rules of cryptography:

1. Cryptography is hard.
2. Don't roll your own.

I cannot stress strongly enough how dangerous it is to roll your own schemes, especially when dealing with crypto. Not even the legendary Bruce Schneier would dare write his own cryptosystem without serious peer review and months (if not years) of testing and tweaks.

The advice I've given you with regards to hashing is a standard based on peer review and a huge amount of theoretical and practical testing. Attempting to augment it using extra hashing and other black-magic is a bad idea, and will only increase the attack surface of your application and create a potential security flaw. Stick to the standard.

• a) Thanks. b) "The purpose of a salt is not to make computing the hash slower" - True, but it is to make the number of possibilities larger, and so to create the table (or search for a possibility that will give that hash) - will take longer. 100M/s is slow compared to the 2^400 possibilities in the case I outlined. – ispiro Aug 6 '12 at 14:43
• No, that's incorrect. The attacker already knows your salt, because he's breached your database to get the hash. The point of the salt is to make every hash unique, so that a precomputed database cannot be used to look up all hashes and get the plaintext. The reason you should use a large random salt is that it makes the probability of duplicates near zero. – Polynomial Aug 6 '12 at 14:44
• See edit at the bottom of my question. Thanks for making me realize that wasn't clear. – ispiro Aug 6 '12 at 14:45
• What do you mean by "the salt will remain in the hash"? If you hash the salt, you cannot retrieve the original salt, so how do you verify that a password is correct? – Polynomial Aug 6 '12 at 14:45
• It will not be stored anywhere in the database. The password becomes: itself+salt (and saved by user.) – ispiro Aug 6 '12 at 14:50