We’re releasing SequenceHash and its sister function SequenceMAC, a pair of related hash constructions that bring secure multihashing to developers using hash functions other than Keccak.
(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).
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!
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 derive to 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 derive function as a general-purpose KDF and instead use something standard like HKDF.
HKDF is really two functions, HKDF-Extract and HKDF-Expand. If you already have a uniform random key then you can skip the first and just use the latter, removing the need for a salt.
If you are using SHA-256 and are happy with 128-bit security then this boils down to:
Oops, I’m glad you replied as I apparently posted under the wrong thread! 😅
Just to be crisp, you’re suggesting either:
inputs |> foldl mac (derive key mac 0x55) |> mac (derive key mac 0xaa)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
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
HKDF is really two functions, HKDF-Extract and HKDF-Expand. If you already have a uniform random key then you can skip the first and just use the latter, removing the need for a salt.
If you are using SHA-256 and are happy with 128-bit security then this boils down to:
Where “some context” is eg a fixed string like “my-app-cascade-mac-subkeys” or whatever.
score 1 · canonical