Hacker News Reader

Comment by smarkov | Hacker News Reader

> Signature = (message || secret) may be safe in certain circumstances, but you should also AVOID IT!

What about `H(s || m || s)`?

With appropriate padding to ensure each s is in its own separate input block, that is called "envelope" or "sandwich" MAC, and its security can be reduced to the compression function's security using mostly the same techniques as HMAC.

[1] https://doi.org/10.1007/978-3-540-73458-1_26

[2] https://eprint.iacr.org/2013/248

[3] https://eprint.iacr.org/2021/097

Bad against other cases such as constant length m (like user db id) that with combination of other weaknesses may be bruteforcable.

Like if your db is mongo and the 12 byte ID != 12 byte of secure randomness:

https://www.mongodb.com/docs/manual/reference/method/ObjectI...

I think the OP point still stands, just use HMAC instead of inventing crypto schemes.

Even with HMAC you have to be careful! A contrived example:

    HMAC(secret, username || email)

Imagine you have `bob` and `bob@example.com` as inputs. This HMAC can trivially be reused (or learned) by registering `bobb` and `ob@example.com`.

If you ever have multiple fields being concatenated, use fixed-width length prefixes before each field:

   HMAC(secret, 0x0003 || bytes("bob") || 0x000e || bytes("bob@example.com"))

Does this really work? Any arbitrary fixed-length prefix?

I always just serialize the inputs with JSON or something. Any weirdness an attacker might try would just be escaped so they'll never be able to match the original input.

> I think the OP point still stands, just use HMAC instead of inventing crypto schemes.

Completely valid point, I was asking purely out of curiosity since this isn't my area of expertise but I find these kinds of vulnerabilities intriguing.

You are now starting the process of independently re-inventing HMAC.

Reply on news.ycombinator.com