Sign up ×

Let's say I want to hash some data, using SHA256, in order to prove I know something. Maybe it's my secret ID for something.

In the real of passwords we have moved from hashing -> hashing+salt -> cpu hard problems -> cpu+memory hard problems. However, the main reason we did all this is because passwords are (in the actual world) very low on entropy since people use "123456" as their password. Since websites gets hacked all the time we have started trying to protect these low entropy passwords from being cracked by brute force.

However, there are a lot of other cases where the input is not as "bad". Say I instead want to hash my secret bittorrent sync ID, my bitcoin wallet ID or any other kind of secret identification. Isn't a single round of SHA256 enough here and for the foreseeable future? Even with the NSA building the worlds largest cluster of ASIC's for brute forcing SHA256.

I've seen people using algorithms like bcrypt/scrypt in many othe contexts than passwords, and of course it doesn't hurt - but is there any reason a single hash of SHA isn' good enough? (Assuming I know my input has high enough entropy)

share|improve this question

closed as unclear what you're asking by Adi, Xander, TildalWave, Steve, GdD Feb 8 '14 at 20:40


Hashing is conveniently used with passwords for purposes of secure storage, mainly because authentication doesn't require the authenticator to know the password itself in plaintext. However, why hashing your BitTorrent sync ID or your BitCoin wallet ID, for what? If for storage, then you do realize that you cannot retrieve them afterwards, right? Your question doesn't make any sense. – Adi Feb 7 '14 at 15:40
If the input has high entropy then there is usually no reason to use a slow hash. Public key fingerprints could be an exception, since humans suck at comparing them. – CodesInChaos Feb 7 '14 at 15:43

2 Answers 2

up vote 2 down vote accepted

The password-hashing functions (and password-based key derivation functions, in the case of PBKDF2) are designed to cope with the low entropy of passwords: they start from a bad situation (initial secret is vulnerable to a practical exhaustive search) and apply salts and slowness (to prevent parallel/precomputation attacks, and to make exhaustive search slower) so that this badness can be tolerated to some extent.

If your initial secret has sufficient entropy to withstand exhaustive search, then using a password-hashing function is unnecessary. If you have a secret 256-bit key which was generated properly, then bcrypt or scrypt or whatever will not do any additional good. On the other hand, if your initial secret has low entropy even if it is not a "password" per se (e.g. some biometrics-derived value, assuming you could find one that is somewhat secret and can be turned reliably in a value which won't move too much for a given individual), then "password"-hashing functions will be an appropriate tool.

The core functionality of password-processing functions like bcrypt is to convert a low-entropy input value in a non-regular format into a nice hash value (for verification) or symmetric key (for symmetric cryptography) in a way which improves practical resistance to exhaustive search (which is feasible due to the low entropy). "Passwords" are just a very common case of "low entropy secret with a non-regular format".

share|improve this answer

Let's say I want to hash some data, using SHA256, in order to prove I know something. ... However, there are a lot of other cases where the input is not as "bad".

Ask the following questions, but answer then at the worst case (from your point of view) that will exist between now and when in the future you predict you will no longer care at all about an attacker finding and/or publishing what you're hiding. In your case, "what you're hiding" may be your bitcoin wallet ID, etc.:

What is the value of an attacker finding out what you're hiding?

What is the largest keyspace an attacker would have to search withing to guess what you're hiding? I.e. brute force attack.

What is the smallest keyspace an attacker would have to search withing to guess what you're hiding? I.e. rules-based dictionary attacks, weaknesses in your hashing algorithms, not every bit is random, weaknesses in the RNG that helped with what you're hiding, weaknesses in other algorithms, etc.

Does PBKDF2 (or HMAC, which it includes) increase the smallest keyspace? Scrypt? Bcrypt?

What are the chances of a flaw being discovered that you don't know about now?

At what speed could a poorly funded attacker search said keyspaces (assume $5kish, so perhaps 8 top end GPU's or 10 very good CPU's - a teen with rich parents, a hobbyist, a StackExchange member). A moderately funded attacker? A well funded attacker? A megacorp or government?

What level of attacker do you care about?

How much extra CPU time/member for one of these techniques could you spend without inconveniencing you at all? Inconveniencing you only a little? Inconveniencing you moderately? Inconveniencing you a lot?

What is the chance of the technique you choose helping an attacker compared to the technique you were considering before? For instance, PBKDF2-HMAC-SHA-256 is no worse than SHA-256, since they share the same base hash, but the former has considerably more protection against certain types of attacks.

Take these answers and apply them to a cost-benefit risk analysis. Go with your answer.

For myself, I would at minimum use however many rounds of whichever of the three I like does not inconvenience me at all, and very likely more - I tend to think that 4-8 seconds of waiting isn't a problem when I, a human, am looking up secret information. Scale iterations up over time as you see fit.

share|improve this answer
