lobsters score: 2 · tags: cryptography
I’d take a look at the spec instead of the writeup. It’s a lot easier to understand, imo.
score 1 · canonical
It’s the same class of vulnerabilities as injection attacks. When you are hashing structured data it must be properly delimited to preserve the correct structure regardless of the contents of the data. If you concatenate without delimiters then an attacker can make you treat their malicious data as if it were your trusted metadata.
score 1 · canonical
I kinda guessed that but when the article says it can create many vulnerabilities, an example would be good. And also maybe why a naive approach with custom escaping or length prefixes isn’t enough.
score 1 · canonical
I wrote about more efficient (and IMO much simpler) constructions for multiple-input MACs some time ago:
https://neilmadden.blog/2021/10/27/multiple-input-macs/
score 1 · canonical
fn cascade_mac key1 key2 inputs = inputs |> foldl mac key1 |> mac key2How do I drop that in as replacement for a mac? In particular, where does
key2come from and how do I manage it? Or arekey1andkey2derived from a user-providedkeyala SequenceHash’sK_IandK_O?
score 1 · canonical
You can derive them from a single key using HKDF or any key derivation function or just concatenate them together as in eg JWT’s CBC+HMAC modes.
score 1 · canonical
Oops, I’m glad you replied as I apparently posted under the wrong thread! 😅
Just to be crisp, you’re suggesting either:
- Derived from a single key ala SequenceHash:
inputs |> foldl mac (derive key mac 0x55) |> mac (derive key mac 0xaa) - Concatenated (256-bit user key, 128-bit mac key)
inputs |> foldl mac key[0:16] |> mac key[16:]
score 1 · canonical
(Meta: I think you did reply to the right thread, as I got notified - Lobste.rs glitch? I’ve noticed meesages being mis-parented on my Threads page too sometimes).
Yes, those are mostly fine. I think SequenceHash’s “derive” only XORs the first byte with the tweak. If it did the whole key then you could end up undoing that in HMAC when it also does the same trick. So you’d have to carefully examine that I think. (In my use-case I’m doing authenticated encryption so the main key is for AES-CTR and I use the first two blocks of keystream for the MAC keys).
score 1 · canonical
If it did the whole key then you could end up undoing that in HMAC when it also does the same trick.
I don’t understand. I don’t see where an HMAC used in SequenceHash? Or do you mean for your cascade construction?
HMAC pads and then xors the same key with two different bytes. Why is that not OK with your cascade? Why does SequenceHash only xor the first byte rather than the full block?
n.b. I’m not in any way shape or form a cryptographer or cryptographic engineer. Thank you for answering my freshmen questions!
score 1 · canonical
Well, let’s say the original key is the same length as the hash blocksize (eg 64 bytes for SHA-256). If you use SequenceHash’s
deriveto derive the two MAC subkeys then it will just xor the provided tweaks into the first byte and leave the rest of the key untouched. That’s already somewhat dubious as a general purpose KDF, as the keys are then very related when they should be independent.If you chose the HMAC constants 0x5c or 0x36 as the tweaks then applying HMAC as the underlying MAC (in my construction) would undo that tweak, leaving the two subkeys practically identical. (You’d effectively just be swapping the inner and outer keys of HMAC).
This probably doesn’t create an actual vulnerability, because HMAC is very forgiving, but it’s at least a bad smell.
So my advice is to not use SequenceHash’s
derivefunction as a general-purpose KDF and instead use something standard like HKDF.
score 1 · canonical
Does HKDF needs a random number generator for the salt? I wonder if there’s a way to define your cascade such that it’s generic and deterministic.
score 1 · canonical
- Derived from a single key ala SequenceHash: