Hacker News Reader

Thanks. Is there a specific reason why handling the key is tricky? Or, is this just a matter of keeping it secret?

Yeah, it definitely needs to be kept secret. Since you specified that A and B can have a set-up phase before C is around, the initial setup is fairly straightforward.

Depending on what the system is used for, how valuable breaking into it would be, and how long you expect it to be up, you might need to rotate the key every so often, by having A and B agree on a new key. This is a little more complicated; since B now needs to check C's HMACs against two keys (the original and the new one) until every message signed by the original key has expired.

Ah, I see - thanks for this clarification. Alpha server and Beta server can actually communicate after the initial setup, but I didn't want this to be a consideration in my scenario, since I don't want any such communication to be required during each permission message transaction (once per hour or day, etc. would of course be fine).

Perhaps, I will provide an API method for automatically expiring an HMAC and fetching a new one. During this rollover period, messages sent using the old HMAC will be allowed to fail, since they can just come get a new copy from Alpha server.

Reply on news.ycombinator.com