Other Software > Developer's Corner

Random Question (About Hash Keys)

<< < (2/3) > >>

db90h:
And note that when two files or sets of data 'match' as mouser eloquently explained it (much better than I), that is what is called a 'collision', as I tried to explain above. Thus, the collision rate is paramount when determining what algorithm you want to use.

If it need be secure, then you want an essentially zero collision rate, but that comes with high computational complexity and a large bitspace. Thus, in *my* rogue thinking, I prefer to call such 'secure hashes', digests. A digest is a hash, but a hash isn't always a digest. Of course, being irreversible is another important characteristic that applies to both forms. Anyway, it just makes it easier to differentiate.

Update: I see mouser did put (collision) is parenthesis. In retrospect, my explanation assumes the reader knows too much already.

db90h:
Updated last post to mention that I was being redundant, and also explain my 'rogue' redefinition of digests. I really do prefer this, and think it is valid. I don't know that anyone teaches my view that secure hashes should be reserved the term 'digests', but I like it because it makes it clear in conversation the difference between a secure hash and an insecure one, as well as its likely intent. That way, if you say 'digest', you know it must be a secure hash. Saying 'hash' could mean it is as little as one bit (arbitrary size, as mouser said), and therefore come with a huge collision rate... or, from a different perspective, mean its some random algorithm that need not be mathematically secure.

Deozaan:
If you require a hash to be secure before you call it a digest, then why do you call MD5 a digest when there are known collisions? Doesn't that make MD5 an insecure hash?

db90h:
If you require a hash to be secure before you call it a digest, then why do you call MD5 a digest when there are known collisions? Doesn't that make MD5 an insecure hash?
-Deozaan (May 08, 2012, 08:02 PM)
--- End quote ---

Well, MD5 had the intent to be secure, and indeed mostly is - except for the known issues I linked to. It's like an encryption algorithm vs an obfuscation algorithm. An encryption algorithm seeks to be secure, while an obfuscation algorithm simply seeks to obfuscate.

Hence, I believe it is intent that matters most, as all digests will eventually be broken. To reduce a larger data set to a much, much smaller one means there is always a probability of collision, even if minuscule, approaching zero. A mathematician maybe can validate that statement, but it seems reasonable to me.

You get my drift. My personal definitions are just that - my preference. Use them at your own risk ;p.

db90h:
Actually, reading a bit, SHA1 is known to theoretically have producable collisions now too, though it is not very practical at this point .. so it is still pretty darn secure.

Navigation

[0] Message Index

[#] Next page

[*] Previous page