Hacker News Reader

Comment by tracker1 | Hacker News Reader

If you treat the original UTF8 as bytes, then you still have that as bytes... this is part of why JWT uses base64 around the JSON string's bytes. In any case, you don't create a signature on a string per se, you create it on bytes, even if those bytes are derived from a string. Also, you don't validate a signature by re-creating the bytes in question... that's a flawed approach, and not the approach for example JWT takes.

View on HN

> In any case, you don't create a signature on a string per se, you create it on bytes, even if those bytes are derived from a string.

Everyone is on the same page that at some point bytes go into a hash function. That's not the problem.

You mention JWT, but JWT only does external signing, which doesn't trigger the problematic case several people are describing to you. Perhaps an example would be more useful. If you start with a JSON like:

    {"a": 1}

how do you build a JSON like:

    {"a": 1, "tag": "deadbeefdeadbeefdeadbeef"}

with a signing and verification algorithm that works?

> Also, you don't validate a signature by re-creating the bytes in question... that's a flawed approach, and not the approach for example JWT takes.

Can you describe an HMAC validation process that doesn't involve recreating the bytes in the HMAC tag?

You don't... you could create one like...

    {"body":"base64-json","tag":"hash"}

It seems to me that trying to do what you're saying is a flawed approach.

That is literally the first thing suggested in the post. You can say the other thing is a "flawed approach" but that's the design problem being solved, so your answer is simply not responsive to the question.

Don't worry, multiple people (including me) have told the community in question that it's a flawed approach. Doesn't seem to have done much to fix it though... :shrug:

Reply on news.ycombinator.com