On Mon, May 25, 2015 at 8:05 AM, lists <lists at rustichelli.net> wrote: > On 05/15/2015 12:09 AM, Jay Foster wrote: >> >> What is the down side of truncating a hash? For example, an SHA-256 hash >> is 256 bits. Is it any less secure if one was to drop the last 128 bits to >> make a 128 bit hash or take the MD5 hash of the SHA-256 hash to get a 128 >> bit hash? It does not seem that such an action would make it any easier to >> brute force reverse the hash, but then again, I am clearly not a security >> expert. > > > I'm not sure the previous replies, though correct, made the point clear. > Theoretically speaking, truncating a 256 bits long hash to 128 bits makes it > as good as if you applied an hash of 128 bits, that's all (provided that the > "hypotetical" latter hash algorithm has the same virtues of the former). > And yes, it is bad idea to re-hash, it is much better to truncate because > re-hashing will not increase security, can only weaken it. Its not clear that property exists for truncated hashes. At minimum, the prefix does not change whether you lop off the last 10 bytes or 20 bytes. I believe one of the things you are supposed to do is feed in the truncated digest size to ensure a different digest based on the truncation size. You should visit some of John Kelsey's work on it. http://csrc.nist.gov/groups/ST/hash/documents/Kelsey_Truncation.pdf is the one I am familiar with. Also see https://www.google.com/search?q=truncated+hash+kelsey+nist Also, for SHA-1, see Marc Steven's HashClash (https://marc-stevens.nl/p/hashclash/). I believe he's engineering prefix collisions. > What is the purpose of it, though? For instance, HOTP uses a fraction of a > hash to produce the (next) One Time Password, the security of the procedure > depends on the use you make of it. A HOTP is a one time password. Its just that - a temporary password. It makes not guarantees on collision resistance and such. The range is so small it probably can't make any guarantees. Jeff
