3 ms·
I'd agree. An HMAC allows A and B to send messages to each other, through C, without C being able to change or modify the message in flight. A and B just need
by kmowery 12y ago
I'd agree. An HMAC allows A and B to send messages to each other, through C, without C being able to change or modify the message in flight.
A and B just need to share the HMAC key. Handling (and changing) this key can be tricky; if an attacker acquires it, the entire scheme falls over.
- mangeletti 12y agoThanks. Is there a specific reason why handling the key is tricky? Or, is this just a matter of keeping it secret?
- kmowery 12y agoYeah, 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.
- mangeletti 12y agoAh, 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.