August 21st, 2024

"YOLO" is not a valid hash construction

The article warns against insecure ad-hoc cryptographic practices, highlighting vulnerabilities in custom constructions. It advocates for established alternatives like HMAC, KMAC, and modern key derivation functions for better security.

Read original articleLink Icon
ConfusionSkepticismConcern
"YOLO" is not a valid hash construction

The article discusses the common pitfalls in cryptographic practices, particularly the use of ad-hoc or "YOLO" constructions that attempt to create custom hash functions or message authentication codes (MACs) without proper understanding. It highlights several problematic constructions, such as YoloMultiHash, YoloMAC, and YoloPBKDF, which can lead to security vulnerabilities like ambiguous encoding, length-extension attacks, and inadequate key derivation from passwords. The author emphasizes that these issues arise from a lack of awareness of established cryptographic standards and solutions. Instead of relying on these insecure methods, the article recommends using well-defined alternatives like TupleHash for hashing multiple values, HMAC or KMAC for MACs, and modern password key derivation functions such as Argon2 or scrypt. These alternatives are designed to address the specific security challenges posed by their predecessors, ensuring better protection against potential attacks.

- Ad-hoc cryptographic constructions often lead to significant security vulnerabilities.

- Established alternatives like HMAC, KMAC, and TupleHash provide robust solutions to common cryptographic needs.

- Modern password key derivation functions, such as Argon2 and scrypt, are essential for secure key generation.

- Awareness of cryptographic standards is crucial to avoid insecure implementations.

- Length-extension attacks and ambiguous encoding are common issues with poorly designed hash functions and MACs.

AI: What people are saying
The comments reflect a range of opinions on cryptographic practices and the article's recommendations.
  • Several commenters express skepticism about the complexity and practicality of certain key derivation functions (KDFs) and their recommendations.
  • There is a discussion on the importance of encoding methods, with some suggesting JSON as a solution to ambiguous encoding issues.
  • Concerns are raised about the real-world implications of following certain cryptographic guidelines, particularly regarding performance and denial-of-service (DoS) vulnerabilities.
  • Some commenters emphasize the need for better education on cryptography to prevent misuse of cryptographic primitives.
  • There is a general consensus that the article may be too technical for non-specialists, making it less accessible to a broader audience.
Link Icon 12 comments
By @layer8 - 8 months
> The issue we run into here is ambiguous encoding.

What I have done in the past for this is to encode the messages as UTF-8 and separate them by 0xFF, since that byte value never occurs in UTF-8 encoding [0]. If the messages to be hashed are character strings, you have to decide on some encoding anyway in order to hash them.

[0] UTF-8 bytes always contain at least one zero bit: https://en.wikipedia.org/wiki/UTF-8#Encoding. Incidentally, if one wanted to create the UTF-8 equivalent of zero-terminated strings without reserving a character value (like NUL) as the sentinel value, one could use 0xFF for that.

By @trainofbit - 8 months
The RFC recommendation for 1G RAM or 64MB Argon PKDF is insane. Don't follow this advice. In a real world server, any API endpoint using this advice will quickly become a DOS vector. A saner value is 1MB for Argon. It stills blocks major GPU attacks, which is the whole point.
By @tptacek - 8 months
This is a good post, but there's a little too much ritual in here about password-based KDFs for my taste. Put all the mainstream KDFs on a dartboard, yes including PBKDF2, and throw a dart. I think you'll be fine. Bcrypt, the most popular password hash, has held up surprisingly well, and scrypt might still be one of the best options.
By @Dylan16807 - 8 months
> While Keccak doesn’t suffer from the length-extension attacks that HMAC is meant to address, the phrase “simply prepending the message with the key” carries a lot of assumptions about key length and key formatting with it.

A lot of assumptions, or just that it's fixed length?

By @blauditore - 8 months
I'm no expert and a bit tired, but: Is the problem around hashing password + salt for a key just about the fact it can be brute-forced with enough recources, or did I miss something?
By @hiddencost - 8 months
Oh fun. They actually give some erroneous advice.

Proto bufs don't guarantee consistent serialization.

By @jgalt212 - 8 months
At one point do I need to be concerned about this? i.e. have someone review hash generating code sites.

- 100s of hashes?

- 1000s of hashes?

- 1,000,000s of hashes?

By @theamk - 8 months
It's interesting that using JSON encoding for all messages eliminates many of the problems.

ambiguous encoding? Nothing ambiguous about JSON, you don't even need any separator. Or merge them into json array.

length-extension attacks? appending non-whitespace to json makes it invalid (for sane decoders at least)

By @krackers - 8 months
A cryptography course should be mandated in the curriculum of most universities, just so people gain some intuition about the types of attacks that are possible. Just yelling "don't roll your own crypto" isn't practical advice when most issues come from misusing primitives or combining primitives in a "weak" manner.
By @playingalong - 8 months
The article is not that different than "don't invent your own cryptography".

It's hard to understand for non-crypto specialists. It uses notions which are unknown to most programmers like MAC or other *MACs.

So not sure who is the target audience for this.