3 ms·

In particular, there's all sorts of mischief an attacker can do when serialized(A,B)==serialized(C,D) but A!=C and B!=D. I've seen OAuth implementations do this

In particular, there's all sorts of mischief an attacker can do when serialized(A,B)==serialized(C,D) but A!=C and B!=D. I've seen OAuth implementations do this, allowing someone to submit the signature from a "good" message along with "bad" arguments (of their own choosing), with a very different meaning. An impatient application developer might just use hash(concat(args)). Raw concatenation is serialization, but it's ambiguous: s("manage", "able") == s("man", "ageable"). The safest approach is to ensure that the serialization function is reversible (even though you're just going to throw it into a hash, which is obviously not). When your arguments are arbitrary bytes, you either use a delimiter character (and escape any places where it appears naturally), or prefix each string with (a fixed-length representation of) its length. Either way, if you could conceivably parse the serialized form back into the original arguments, then you're safe from tricky format-confusion attacks.

zAy0LfpBZLC8mAC 10y ago
That's what "injective" means :-) Also, I think that serialization is actually injective by definition. If you can't deserialize it, it's not a serialization, it's just an arbitrary sequence of symbols that you maybe happen to have generated based on some non-serial structure. And actually, it's not just the safest way, it is the only way. Though it's true that the hash is not injective, it is collision resistant (based on current understanding), that is what makes it a cryptographic hash function. The only theoretical alternative to (injective) serialization would be to feed the data into a collision resistant function that takes tuple inputs, which by definition would be a cryptographic hash function, which would make it pointless to feed the result into another cryptographic hash function. The solutions you suggest are good advice, though. Also, don't forget to tag message types if you use a key for multiple purposes, so one message cannot be replayed as another type of message.

zAy0LfpBZLC8mAC 10y ago

That's what "injective" means :-) Also, I think that serialization is actually injective by definition. If you can't deserialize it, it's not a serialization, it's just an arbitrary sequence of symbols that you maybe happen to have generated based on some non-serial structure. And actually, it's not just the safest way, it is the only way. Though it's true that the hash is not injective, it is collision resistant (based on current understanding), that is what makes it a cryptographic hash function. The only theoretical alternative to (injective) serialization would be to feed the data into a collision resistant function that takes tuple inputs, which by definition would be a cryptographic hash function, which would make it pointless to feed the result into another cryptographic hash function. The solutions you suggest are good advice, though. Also, don't forget to tag message types if you use a key for multiple purposes, so one message cannot be replayed as another type of message.