4 ms·

> Signature = (message || secret) may be safe in certain circumstances, but you should also AVOID IT! What about `H(s || m || s)`?

yonixw 3y ago
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/ObjectId/ https://www.mongodb.com/docs/manual/reference/method/ObjectI... I think the OP point still stands, just use HMAC instead of inventing crypto schemes.
- stouset 3y ago
  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"))
  - erhaetherth 3y ago
    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.
- smarkov 3y ago
  > 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.
pbsd 3y ago
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 https://doi.org/10.1007/978-3-540-73458-1_26 [2] https://eprint.iacr.org/2013/248 https://eprint.iacr.org/2013/248 [3] https://eprint.iacr.org/2021/097 https://eprint.iacr.org/2021/097
tptacek 3y ago
You are now starting the process of independently re-inventing HMAC.

yonixw 3y ago

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/ObjectId/ https://www.mongodb.com/docs/manual/reference/method/ObjectI... I think the OP point still stands, just use HMAC instead of inventing crypto schemes.

stouset 3y ago
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"))
- erhaetherth 3y ago
  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.
smarkov 3y ago
> 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.

pbsd 3y ago

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 https://doi.org/10.1007/978-3-540-73458-1_26 [2] https://eprint.iacr.org/2013/248 https://eprint.iacr.org/2013/248 [3] https://eprint.iacr.org/2021/097 https://eprint.iacr.org/2021/097

tptacek 3y ago

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