"Cryptography is hard, a single character difference will result in a completely different value."
HMAC is designed to guarantee the integrity of the message. If a single character difference didn't result in a completely different value, the whole method would be completely flawed.
"snake case your header names (yes this is bad form) before presenting them to your code as the list of header names."
From RFC 2616, "Hypertext Transfer Protocol -- HTTP/1.1", §4.2, "Message Headers":
Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive.
Yes what I should have said was repeatable signatures are hard across large strings.
Having just worked on this with a few people implementing independent implementations everyone got at least one character wrong, and therefore a complete missmatch of signature.
Right, it's not really a disadvantage. But I wouldn't say that it's a requirement, either. A hash where each input character only affects certain output characters is less than ideal, but it's not a critical flaw. You could make one at least as good as md5 if you had the desire to.
@Dylan16807 Maybe not a requirement, but this could cause information leakage in some scenarios. I'm also pretty confident I couldn't come up with a hashing scheme as good as MD5. I'll leave that to the crypto pros.
Well it depends on what your criteria are for 'better'. If you have three bcrypts glued together that each get character%3, there are no blatant flaws, it's just going to give you an oversized hash for the security level you get. And each character will affect only one third of the hash.
Comments
I don't understand why this is a downside
"Cryptography is hard, a single character difference will result in a completely different value."
HMAC is designed to guarantee the integrity of the message. If a single character difference didn't result in a completely different value, the whole method would be completely flawed.
"snake case your header names (yes this is bad form) before presenting them to your code as the list of header names."
From RFC 2616, "Hypertext Transfer Protocol -- HTTP/1.1", §4.2, "Message Headers": Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive.
"Use content MD5 at both ends of the conversation." Yeah.. no: https://bugzilla.mozilla.org/show_bug.cgi?id=232030
Yes what I should have said was repeatable signatures are hard across large strings.
Having just worked on this with a few people implementing independent implementations everyone got at least one character wrong, and therefore a complete missmatch of signature.
For those involved this was pretty frustrating.
Right, it's not really a disadvantage. But I wouldn't say that it's a requirement, either. A hash where each input character only affects certain output characters is less than ideal, but it's not a critical flaw. You could make one at least as good as md5 if you had the desire to.
@Dylan16807 Maybe not a requirement, but this could cause information leakage in some scenarios. I'm also pretty confident I couldn't come up with a hashing scheme as good as MD5. I'll leave that to the crypto pros.
Well it depends on what your criteria are for 'better'. If you have three bcrypts glued together that each get character%3, there are no blatant flaws, it's just going to give you an oversized hash for the security level you get. And each character will affect only one third of the hash.