Me and my colleague are trying to come up with a way around preventing a theoretical man in the middle attack.

The scenario is:

Communication is only through one channel and either sides isn't aware of what is going to be said.

Alice and Bob want to communicate with each other.

Eve is the "man in the middle". All communication from the start goes through her first.

If Alice publishes her public key Eve can intercept this and send her own public key to Bob. When Eve intercepts a message from Bob she uses her private key and decrypts the message, does what she wants with it and encrypts it with Alice's public key and sends it to Alice.

As Eve has intercepted the first message and the two unknowing parties haven't pre exchanged any keys or certificates is there any way that they can communicate without Eve reading the messages?

I cannot see any conceivable way as Eve has intercepted Alice's public key first so Bob has no genuine way of checking to see if the message is from Alice at all.


[...] is there any way that they can communicate without Eve reading the messages?

Nope. Against an active Man in the Middle attack (active adversary traditionally named "Mallory") like this one, you're out of luck.

Against a purely passive MITM (passive eavesdropper, traditionally named "Eve") this would have worked.

  • 2
    I didn't realize there were sub categories for it and Eve was one and Mallory the other. Thank you. – Softey May 25 '15 at 14:43
  • 10
    Yep. It's a whole little family. -> Wikipedia: Alice and Bob: Cast of characters – StackzOfZtuff May 25 '15 at 16:18
  • What if Alice were to transmit information in randomised segments such that Eve and Bob would have to store them for them to make any sense? It seems to me that when you don't trust your carrier it's best to make the carrier work harder by doing something that the carrier wouldn't normally be doing. It doesn't make it completely safe, but gets you further away from the likelihood of being intercepted. Think expanding key sizes as an example of this. – tu-Reinstate Monica-dor duh May 26 '15 at 3:32
  • @tudor - The trick is that anything Bob can do, Eve can do. So eventually, you'll have to tell Bob how to assemble the message, and if Eve can spy on that, you haven't accomplished anything. You also can't make Eve work any harder than you make Bob work, assuming the cost of transmitting information is 0 (and Bob+trans if not). All that assumes that Eve sees everything, of course. – Bobson May 26 '15 at 4:34
  • @bobson I agree. It's definitely true when Bob's capability = Eve's capability. But if Eve is crippled in some way compared to Bob (such as less time or memory), then we may eventually get a message through that Eve won't have the time/ability to process. This is why we keep lengthening keys. Longer ones (theoretically) take more resources (processing time,storage) to break but the resources and techniques available to break them keeps improving. – tu-Reinstate Monica-dor duh May 26 '15 at 6:09

The presented case is the prime example why a self-signed certificate provides almost no security at all: it can encrypt the data but is impossible to authenticate it. Anyone can create any certificate in name of anything and have it encrypt data.

That's why there is the certification chains in HTTPS and key signing on PGP keys, for example.

In this case, Alice and Bob cannot make sure they are talking to each other. If both know a certain trustworthy John, and John signs their keys, Bob and Alice can know for sure that the key is valid.

  • 12
    @moebius_eye the problem is verification: If Alice does not already have Bob's certificate ahead of time, via a secure and trusted channel, there would be no way of verifying that it IS Bob's certificate. That's where 3rd party signing comes in: I might not have Bob's certificate ahead of time, but I do have Chad's certificate, and he is the one that signed Bob's cert. This allows me to verify any certificate, for any user, as long as it was signed by a trusted 3rd party. – AviD May 25 '15 at 14:51
  • 5
    self-signed certificates certainly handle half of the security which they are intended to provide, that is to bootstrap encryption. The other half (ensuring the identity of the involved parties) is indeed not handled. This is far from "almost no security at all". The trustworthy John you mention is actually an evil Mallory in the scenario described by OP ("All communication from the start goes through her first.") – WoJ May 25 '15 at 15:20
  • 1
    @moebius_eye The problem here is not the encryption part, is the authentication part. In this case, a 512-bit CA certificate is usable and a 4096-bit self signed is useless. – ThoriumBR May 25 '15 at 18:37
  • 1
    please, the cast names are traditionally important (as pointed out by the other answer), so for active attacks "Mallory" and for trusted 3rd parties "Trent" – SEJPM May 25 '15 at 20:15
  • 1
    Self-signed certificates are useful if, and only if, you can meaningfully verify the certificate against data from a trusted source. For instance, if Alice and Bob meet for coffee and exchange PGP fingerprints, they can use those to authenticate each others' PGP keys without any issues. – cpast May 25 '15 at 22:40

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