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?
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.
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"
> 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.
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
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.
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.