81–90 of 133 posts
Nitpicks. It seems that he's talking about password hashing: > "Hashes are designed to be tamper-proof". Wrong. Cryptographically secure hash functions are. > "Hashes, when used for security, need to be slow." Wrong. Password hashes needs this; not SHA1/MD5 etc.
Well, I'd say a hash that has no need whatsoever to be tamper-proof (no attackers, ever) and cares only about speed is a checksum -- so maybe a terminology issue. I agree there are certainly other uses for hashes, just trying to distinguish between hashes and checksums. Re-reading what I wrote, I open with "Hashes are a bit like fingerprints for data. A given hash uniquely represents a file, or any arbitrary collecti…
Why would you use MD5 as a checksum if different documents with identical hashes can be produced?
Why would you use MD5 as a checksum if different documents with identical hashes can be produced?
Earlier quoted context omitted.
I have hash functions that work on less bytes than the length of the hash they produce.
Won't that be fairly common? Java's hashCode and the .Net GetHashCode both return 4 byte ints and there are presumably a lot of HashMap and Dictionary objects out there using short strings as keys.
Earlier quoted context omitted.
There is a good motivation to prevent copy-and-paste - they might be storing the password in plaintext somewhere.
No, there isn't. From Stack Overflow ( http://stackoverflow.com/a/4760170/ ): "No. Why stop the user from copy-pasting their own password? Whenever you're looking at a security protection like this, it's important to ask yourself: Exactly what kind of attacks are am I trying to protect against? In this case, even if you prevent copy-paste, the user can just retype it if they really want to, after all. And if you're w…
Earlier quoted context omitted.
Not to quip, but surely some of the blame for that confusion has to lie on the cryptography experts who insist on using lung-spasm-inducing hairballs like "PBDKF" ( edit: typo there was, I swear, unintentional! ) to represent concepts better explained in English as "expensive to compute".
"Password based key derivation function". The problem here isn't that cryptographers are inflicting a terrible name at you, it's that security people have repurposed a function intended for one purpose (generating crypto keys) for another (storing passwords). Also: don't blame us, blame the PKCS standards group.
Earlier quoted context omitted.
Not to quip, but surely some of the blame for that confusion has to lie on the cryptography experts who insist on using lung-spasm-inducing hairballs like "PBDKF" ( edit: typo there was, I swear, unintentional! ) to represent concepts better explained in English as "expensive to compute".
"Password based key derivation function". The problem here isn't that cryptographers are inflicting a terrible name at you, it's that security people have repurposed a function intended for one purpose (generating crypto keys) for another (storing passwords). Also: don't blame us, blame the PKCS standards group.
Earlier quoted context omitted.
I guess what I don't fully understand is just how computationally intensive (slow) a hash needs to be to produce a reliable fingerprint, that is, one that is as collision free as possible and extremely sensitive to any tiny change in the source data. I do understand that password related hashes may have arbitrary computational delays added just to make them tougher to brute force, which would be bad in many other (al…
The first question is an open one. Not even theoretical cryptography people understand collision resistance very well. From a practical standpoint, though, we know that it can be pulled off reasonably fast; SHA-256 is still standing, for example, and it "only" takes 14 cycles per byte hashed. Not great, but not bad either. The first written mention of artificially slowing down key derivation was (AFAIK) here: https:/…
Earlier quoted context omitted.
> What's the point of salt if salt is in plain sight? If you by "plain sight" mean "the same place as the hash" you're misunderstanding what the salt is for. If you want to access X servers in order to verify a password, you don't need a salt; you just split the hash in X parts and store each on different servers. Salts are for preventing rainbow tables.
It doesn't matter if the hash is split into X parts and stored on X servers. We are not talking about Humpty Dumpty here and salt-specific rainbow tables can be built on-demand as long as the reward justifies the time and expense.