4

Hydra is a secretive organization. It is comprised of several Directors at the top, and many Agents underneath them.

A Director sends Agents on secret missions. During these missions, communication is spotty and unreliable. Agents rely on untrusted messengers to deliver messages back to the Directors. Messages include the # of the agent (33, etc.). The content of these messages are not secret, but it is crucial that they are not faked.

Before the Agent leaves, the Director issues him secret key that Agent "signs" his messages with to verify authenticity. Agents have different keys, and should not be able to fake messages as other Agents. These keys are good for six months. Directors reject any messages signed with a key issued more than 6 months ago.

Directors maintain very minimal communication among each other. They do not know when the others issue keys to Agents, though they each must be able to independently verify the authenticity of messages received from these Agents.

Directors share a top-secret key that they can use to create keys for the Agents.

I need to implement this system.

Are there certain terms for what is happening?

What cryptographic primitives should be used, and how and where are they applied?

I believe I will be using an HMAC, but the multiple levels of keys in play makes things less clear to me.

Improve this question
5
  • 1
    is this a homework question?
    – schroeder ♦
    Apr 3, 2015 at 4:16
  • 1
    @schroeder, no. It's a real problem, with servers and clients and signed URLs and such. I tried to abstract all the details I could, as with Bob/Alice. Maybe it wound up being distracting instead.
    – Paul Draper
    Apr 3, 2015 at 5:06
  • @cybermike, Alice and Bob aren't computers. But you can substitute for computers if you'd like. In any case, I thought I made the trust clear. Apologies. Directors and Agents are trusted. The Agents' messengers are untrusted.
    – Paul Draper
    Apr 3, 2015 at 15:19
  • 2
    Are you working for SPECTRE?
    – Deer Hunter
    Apr 3, 2015 at 18:28
  • I'm voting to close this question as off-topic because it should be moved to Crypto.
    – Eric G
    Apr 7, 2015 at 1:07

1 Answer 1

Reset to default
2

When a Director sends an Agent with id (A) on a mission, he generates a timestamp (B) and an HMAC of A and B (C), using his secret key.

He gives B, and C to the Agent. C becomes the secret key of the Agent.

When an Agent sends a message, he calculates an HMAC of it (D) using C and includes it in the message. He also includes A and B. C is of course secret and not transmitted.

When a Director receives the message, he verifies that the timestamp B is less than 6 months old. Then he recalculates C by taking an HMAC (using his own secret) of A and B. He then uses C to calculate an HMAC of the message, and verify that it matches D.

Improve this answer
4
  • You could use a KBKDF to create the agent keys instead of just a HMAC. That way the director only needs to keep the master key, the other keys can be generated when required (based on an identifier assigned to the agent, just a timestamp seems a weird identifier).
    – Maarten Bodewes
    Apr 3, 2015 at 16:44
  • So after 6 months, what will happen?
    – Maarten Bodewes
    Apr 3, 2015 at 16:49
  • @MaartenBodewes, I haven't heard of KBKDF. Any message delivered more than 6 months later will be rejected by the Directors. The Agents would have to manage to get a new key before that happens.
    – Paul Draper
    Apr 3, 2015 at 21:02
  • 1
    A KBKDF is a Key Based Key Derivation Function. It does what you are trying to achieve with the HMAC. I'm not saying that the HMAC construction is not secure, but KBKDF's have been specifically designed to perform key derivation. The most modern one is arguably HKDF. It's also based on a HMAC.
    – Maarten Bodewes
    Apr 3, 2015 at 21:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .