Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Suppose there's systems A, B and C.

A has an trusted relationship* with B and B has one with C. How can B intermediate a request from A to C while still providing both A and C the guarantee that they are talking to each other?

Some options I have considered:

  • A can share a passkey with C and that key can be used to encrypt messages before they are sent to B and decrypted when they reach C.

*=Meaning they they are connected via an unspecified trustworthy connection.

share|improve this question

First of all, when saying X and Y have a trusted relationship, it usually implies that X trusts Y and vice versa. This is not necessarily to do with the quality or guarantees of the link between them. I'm not just saying this to correct your definition, but because this trust relationship is important.

If in your case, A trusts B, and C also trusts B, then both A and C should trust that B delivers the messages that they sent without modification. There are many cryptographic examples that use a trusted 3rd party for exactly those kind of things.

If however, there's no trust in B. Only a trust in the security of the links to/from B, then it's a different story.

Encryption is probably not what you need here, or not ONLY what you need. If A and C share a key and encrypt messages between each other (via B), B won't be able to read the messages, but nothing stops it from changing the messages. Some times it's possible to make changes to encrypted message. For example, if I encrypt a message "I owe you $1000", it might be possible that B adds stuff to the message so after decryption it looks like "I owe you $10000", or change it to "I owe you $9000" (e.g. bit flipping attack). I wrote a little blog post describing this misconception in a little more detail, in case you're interested.

If you want to protect the message against modification, you should consider using some kind of a Message Authentication Code (MAC). Typically, you'd probably want to use HMAC - which uses a secure hash function to generate the MAC. This is like a signature on the message. Even the smallest modification will invalidate this signature, so it can be detected. Without knowing the key between A and C, B cannot forge this signature either.

Now nothing stops you from using Encryption + Signature. This will ensure both that those messages cannot be read nor modified.

With all that in mind, I'd still urge you not to develop/build your own solution, but rather find a suitable protocol or at the very least a library/package that provides those kind of mechanisms.

share|improve this answer
+1, but why HMAC instead of a proper digital signature (based on asymmetric encryption)? – AviD Feb 23 '12 at 22:46
Good point, it's definitely something to consider as well, but if it's really only two parties sharing a key, as the question indicated, it's usually much easier (and faster) to use HMAC. – Yoav Aner Feb 24 '12 at 7:24
Ah, but dont forget they're sharing a key, via a 3rd party - which makes pre-sharing a key difficult. DH could possibly make things simpler here, though. – AviD Feb 24 '12 at 8:06
I think it's implied that the shared key would have to be communicated/exchanged securely between A and C (not via B if it's not trusted). Otherwise, even if you have a public-key solution, B can act as MITM and replace the public keys A,C exchange with its own (i.e. you'd need a way to guarantee the authenticity of the public key, which brings you back to square one in terms of either having a trusted channel or a trusted 3rd party) – Yoav Aner Feb 24 '12 at 8:16

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.