Hacker News new | past | comments | ask | show | jobs | submit login
Programmers Don’t Understand Hash Functions (soatok.blog)
48 points by todsacerdoti on Aug 24, 2021 | hide | past | favorite | 18 comments



Not sure if this is a tech article or a DeviantArt gallery


Yeah I seem to see the same style across a few security related blogs. I'm not sure what the connection is. Maybe just a sub culture within that group?


Which blogs? I'm curious to see more of them.


I wish I'd compiled a list. Sorry I read far too many articles on HN and don't have the greatest memory. But I think every month or so I see one with a similar style. Black background, bright fonts and the same cartoon avatars.


Hey, that's fine. If you find any, and they aren't from soatok.blog, feel free to let me know. I keep my contact info in my HN bio.

As for the subculture remark: It's a communication style that's popular among furries, due to Telegram and custom sticker packs. This style is not exclusive to furries, but if you're looking for a common thread that's probably it.


Maybe you're thinking of (random blog post) https://christine.website/blog/dev-printerfact-2021-04-17


Yeah that is one of them!


The spectrum of hash functions can be outlined in a fairly straightforward manner:

A) Perceptual (fast, similar inputs result in similar hashes - by design)

B) Checksum (fast, hash collisions from different inputs should be expected - by chance)

C) Cryptographic (slow, similar inputs results in very different hashes - by design)

Many security vulnerabilities involving hash functions come from using A or B when C should have been used. More subtle vulnerabilities come from not using a cryptographically strong algorithm for C (eg SHA1, and more recently SHA2), or not appending a unique and random "salt" to every input of C - so when your database is compromised attackers can pre-compute hashes for common passwords (if the attacker also has access to the secret key supplied to the hash function).

As the OP notes, these are fairly well known hazards which are easy to find more information on. I enjoyed reading about the more nuanced scenarios brought up by OP since they aren't as commonly discussed.


In cryptographic context there are very different hash functions:

* Password hashes including password based key derivation functions. These are salted and deliberately expensive to compute. For example bcrypt, scrypt or argon2. Salted sha2 is not suitable for this purpose.

* collision resistant hash functions like SHA2/3. They're designed to be fast, but can't keep up with non cryptographic hashes/checksums

* keyed hashes. This includes pseudo-random-functions (like HMAC) and MACs (weaker requirements than PRFs)

Plus people sometimes use plain collision resistant hashes when they actually need a MAC or digital signature


“I can prove it to you - I bet when you saw this you thought it was going to be about passwords"

Nope. My first thought was about hash tables and Git style associative DB’s.


So far two people have allegedly quoted this statement, but it never appears on my blog.


True. Not a direct quote.

The claim that:

"Programmers don’t understand hash functions"

followed by a "most people" (i.e. not all) argument to back it up:

"I can demonstrate this to most of the people that will read this with a single observation:"

Is a straw man argument. I think that is what people react to. But yes you are right not a direct quote.


Dumb article.

"I can prove it to you - I bet when you saw this you thought it was going to be about passwords"

His entire first point is about passwords.

Never mind the oddly placed furry inspired art


> "I can prove it to you - I bet when you saw this you thought it was going to be about passwords"

> His entire first point is about passwords.

No, the entire first point is about how vague the term "hash function" is. Passwords don't get discussed (modulo a single aside) until much later in the post.


can confirm.

-austin (murmur author)


so, what are "key-derivation functions"?


Pretty much synonymous with "cryptographic hash functions" [1], just referring to a specific use-case.

> derive one or more keys from a common secret value (which is sometimes also referred to as "key diversification").

> Such use may prevent an attacker who obtains a derived key from learning useful information about either the input secret value or any of the other derived keys

[1] https://en.wikipedia.org/wiki/Key_derivation_function


Not quite.

A key derivation function needs to have a lot of the same properties as a pseudorandom function (which is the space cryptographic hash functions occupy), but with additional requirements.

1. It needs a secret input. This is the password (for Password KDFs) or Initial Key Material. Cryptographic hash functions do not.

2. It needs to satisfy a stronger security model. See section 3 of this paper, especially definition 7: https://eprint.iacr.org/2010/264.pdf

There's some overlap (Argon2id, scrypt) between PHFs and KDFs. There's exclusion in both categories. Bcrypt is a PHF, not a KDF. HKDF is a KDF, not a PHF.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: