I would recommend letting your opponent pick your salt. Otherwise (especially if you do actually use md5, though I suspect it’s just a convenient example) you can just generate a bunch of plays that have the same resulting hash ahead of time, and use them when convenient.
like carl said, this allows your opponent to compute all possible hashes for your own play ahead of time. preimage attacks are definitely a problem that was overlooked in the current revision – a future revision will address this point.
If the opponent picks the salt, can’t they just see what the hashes are for salt+“rock” salt+“paper” and salt+“scissors”? I think you just have to use a hashing algo without known collisions.
just use two salt values, one from each player, and concatenate them along with the play/move.
also, it seems redundant for the second player to also go through the hashing rigmarole. they can reveal their move immediately, once the first player has locked in their secret answer. so a game would go like this:
<Alice> salt1=ddda0a56c5b73a4c87956d9bdb7df94e
*bob generates salt2 and computes md5(salt1|salt2|move)*
<Bob> hash=4510abdd3eb615ce12df0ec848247385
<Alice> paper
<Bob> ddda0a56c5b73a4c87956d9bdb7df94e-747de43a6b2db08519ec0e56f04f4ead-rock
If you are trying to match a particular hash and completely control the source, you can make a lookup table from hash to source, and efficiently search it for something that will to produce the hash you want. They’re called rainbow tables. A salt removes this attack because you don’t get to control the entire input, so you basically would need one copy of the table for each possible salt.
I would recommend letting your opponent pick your salt. Otherwise (especially if you do actually use md5, though I suspect it’s just a convenient example) you can just generate a bunch of plays that have the same resulting hash ahead of time, and use them when convenient.
like carl said, this allows your opponent to compute all possible hashes for your own play ahead of time. preimage attacks are definitely a problem that was overlooked in the current revision – a future revision will address this point.
what if your opponent gives you a salt and then you add an arbitrary number where mod3 it maps onto RPS, then the opponent can’t test all values.
Of course that is overcomplicated since the mod3 trick means you don’t need a salt, you can just commit to a hash immediately.
Maybe you and your opponent both choose part of the salt and it gets combined?
If the opponent picks the salt, can’t they just see what the hashes are for salt+“rock” salt+“paper” and salt+“scissors”? I think you just have to use a hashing algo without known collisions.
just use two salt values, one from each player, and concatenate them along with the play/move.
also, it seems redundant for the second player to also go through the hashing rigmarole. they can reveal their move immediately, once the first player has locked in their secret answer. so a game would go like this:
Right, yes, fair, you probably want something closer to diffie-hellmann where each party contributes part of the input being hashed
If you have a secure hash function, this should be impossible.
The more relevant weakness here is the attack carlmjohnson mentioned.
If you are trying to match a particular hash and completely control the source, you can make a lookup table from hash to source, and efficiently search it for something that will to produce the hash you want. They’re called rainbow tables. A salt removes this attack because you don’t get to control the entire input, so you basically would need one copy of the table for each possible salt.
You should submit this as the next 4/1 RFC.
i’m considering it :)
fun! i love the idea, and have a similarly themed project in the works myself.
as a presentation note, it’s very hard to read this on my mobile browser.
yeah, sorry about that. the easiest way i could think of to mimick rfc-style formatting was a big ol’ <pre> tag with verbatim content.
nailed it on that front :)