# Tag Info

16

These are completely different things: Man-in-the-middle is an active attack to a cryptographic protocol, where the attacker is, effectively, in between the communications of two users, and is capable of intercepting, relying, and (possibly) altering messages. In this case, the meaning of "in the middle" is direct: the attacker is in the middle of two ...

14

Short answer: Because the browser developers have long thought interoperability to be more important than security and standard compliance. Slightly longer answer: Some SSL/TLS server implementations do not negotiate the protocol version correctly, but terminate the connection with a fatal alert if the client attempts to negotiate a protocol version that ...

11

The solution is called onion routing; the gist of it is that there are a number of anonymising servers; when Alice wants to send a message to Bob, she picks a random route through a number of the servers; she then repeatedly encrypts the message for each hop, and sends the encrypted message (which states only the first hop in the clear) to the first server. ...

11

For P2P authentication, you can go for web of trust concept. Simply this means, if someone is trusted by people you can trust, you can also trust that unknown person. In OpenPGP, a certificate can be signed by other users who trust the association of that public key with the person or entity listed in the certificate. So trust relationships can be propagated....

10

Annex E.1 of RFC 5246 contains the following text which is a nice summary of the situation: Note: some server implementations are known to implement version negotiation incorrectly. For example, there are buggy TLS 1.0 servers that simply close the connection when the client offers a version newer than TLS 1.0. Also, it is known that some servers will ...

9

As has already been commented: The fact that you can intercept and relay all messages does not actually constitute an attack on the protocol because you do not know the shared key afterwards. If the protocol partners encrypt their traffic with that key you cannot eavesdrop on it. If this was an attack on the protocol none of the network hardware that is ...

8

Diffie-Hellman (and variants such as ECDH) protect against passive eavesdroppers, but not (at least by themselves) against active man-in-the-middle attacks. An active MITM can substitute his own keys for Alice and Bob's keys during the initial exchange, something like this: Alice -> Bob (intercepted by Mallory): Hi Bob, I'm Alice and here's my public key: [...

7

As far as I know your attack is the best attack known, unless something better has very recently been published. Please note that for DES as the basic cipher the chosen $A$ may not work, but you can choose another $A$ and try again Also, for a generic cipher with $k$ bit key, the complexity is $$2^{k+1}=2\times 2^k=O(2^k),$$ as $k$ increases.

7

He [Ed: Eve] then sends his half to Alice signed and establishes a connection. Now Alice is communicating with Eve and Eve is decrypting the message and sending to Bob. Eve can only sign with her own private key. So your attack only works if Alice accepts the signature from Eve. That means that: Eve's public verification key needs to be trusted and that ...

6

The protocol's description includes "Alice then encrypts $R_B$ with her private key". This has no standard meaning. Comments have clarified it is used an "RSA encryption scheme with proper padding" and I am taking as granted that encryption of $R_B$ using the private key half of $K_A$, denoted $K_A^-(R_B)$, is obtained by padding $R_B$ as in encryption, then ...

6

TLDR: Diffie-Hellman key exchange works differently Yes, DH is vulnerable to MitM. Long answer: Diffie-Hellman key exchange isn't about sending the public key with some kind of signature, but about negotiating the key. Quick DH explaination (note: these values are very insecure): Alice and Bob publicly agree on two values: The generator - g. Let's say ...

5

You may be interested in something like the Cryptographically Generated Address (CGA) from RFC 3972. CGA is used in Secure Neighbor Discovery Protocol (SEND) of RFC 3971 to bind a public key to an IPv6 address. The basic idea of CGA is to generate part of the IPv6 address by computing a cryptographic hash over the public key. The corresponding private key ...

5

You basically ask the following question: Is there a weakness anywhere if I encrypt the same message independently with 2 different keys? To answer this, please consider the following: The cipher text coming from a perfect encryption algorithm is indistinguishable from random data. Practical encryption algorithms have some flaws, leading to ciphertexts ...

5

It has nothing to do with information theoretic. You just need to construct an adversary and argue that it works. In this case, the adversary is simple. Let $A$ and $B$ be parties with no secret information. An adversary $C$ playing man-in-the-middle interacts with $A$ pretending to be $B$, and interacts with $B$ pretending to be $A$. At the end, $C$ ...

4

Anonymity is indeed hard. How practical does it have to be? There's a trivial solution which is to broadcast everything. That way Carol can make correlations based on the time of messages but otherwise cannot know the destination of each message. The messages can be filtered by the recipient based on an encrypted destination identity that only they can ...

4

That was a bad edit to Wikipedia. The phrase Carry-forward verification is not a standard, well-known term in the cryptographic literature. It should not have been included in Wikipedia without a reference to something more specific. But oh well, no one is perfect, sometimes these things happen. Your request for an elaborate survey of MITM defense is ...

4

A lot of modern cryptography is based on some mathematical assumptions and aims to achieve what is called Computational Security. That means that the adversary (Eve) could get some information about the plaintext with a negligible probability and the adversary is modeled as someone with bounded computational power, storage and bounded time. So all the (...

4

You need an authentic channel from Alice to Bob to get a secret channel from Bob to Alice. This assumption is missing in a), so anyone in control of the communication channel can play man in the middle on any protocol. As long you don't have a secret channel from Alice to Bob or an authentic channel from Bob to Alice, Alice will never (= for any protocol) ...

4

It is secure against private key exposure but not against replay attacks by Eve. A three-way protocol avoids this, and doesn't need to use timestamps. The description below is from Delfs and Knebl's book Introduction to Cryptography. Each user, say Alice, has a key pair $(e_A, d_A)$ for encryption and another key pair $(s_A, v_A)$ for digital signatures....

4

In a public-key infrastructure, there are two ways a public key can be trusted: either because it's signed by a certificate authority that you trust, or because you already have it in a list of trusted public keys. That's where the chain of signatures ends: in a list of pre-trusted public keys. These pre-trusted public keys are usually called “root CAs” or “...

3

Firstly, PKI makes use of a private key and a public key. The private key is known only to the user, while the public key is communicated securely via the use of certificates. To provide authentication and non-repudiation, users may sign a message with their private keys and obtain a digital signature. Any other users can verify that the signed signature is ...

3

I wouldn't consider voice or video to remain a secure means of identification for much longer. Advances in real-time video stream editing are near enough to reality that I wouldn't build a new security system on it. In the olden times in millennia past, you could have the computers on either end display a short MAC for both parties to alternate reading ...

3

No. This does not help Eve the eavesdropper. AES is secure against known-plaintext attacks, so knowing that the same plaintext (kaes1) was encrypted under two different keys (k1 and k2) does not help her to recover any of the keys or break of the traffic. Of course, it still might not be a good idea to do what you suggested: there might be other reasons ...

3

SSL offers protection against Man-in-the-Middle only if the client can make sure that what it believes to be the server's public key is, indeed, the true server's public key. X.509 certificates aim at providing this information, but this is relative that no rogue CA was involved. A "rogue CA" is here one of: An evil or gullible root CA ("subverted" CA might ...

3

Well, as it says in your link the problem is authentication. So somehow Alice and Bob must set up an authenticated channel. One way of implementing such a channel is by Alice and Bob holding each others public verification key for a signature scheme. A CA would probably not hold a secret key for Alice and Bob. However, using a CA to get an authentic copy of ...

3

The problem about Man-in-the-Middle attack on Diffie-Hellman is that both sides are not confident about other side's public key (g^a and g^b). If they were sure that they have correct public key of their's friend Man-in-the-Middle attack wouldn't be possible, because MITM attack is based on the forgery of public keys by adversary! If for instance Bob and ...

3

in diffie-hellman key exchange algorithm vulnerability's is good defined by RSA lab : "The Diffie-Hellman key exchange is vulnerable to a man-in-the-middle attack. In this attack, an opponent Carol intercepts Alice's public value and sends her own public value to Bob. When Bob transmits his public value, Carol substitutes it with her own and sends it ...

3

As far as I understood the problem, the difference between IKEv1 Aggressive and Main Mode is how the hashed PSK is sent. Of course, the PSK itself is never sent to the other side as both sides need to prove to each other that they know the PSK and if one side was sending it to the other one, of course, the other one will now know it. Instead, each side ...

3

The reason Lamport's scheme is secure against a passive attacker is that even if they see $H^{n-1}(p)$ for a given $n$, the server would require the preimage of that hash, $H^{n-2}(p)$ on the next login. The active attack, in comparison, allows Trudy to find an earlier iteration than the server is expecting. That allows calculating several login hashes by ...

3

However, Eve has a copy of Alice's key pair and intercepted the outgoing message. She uses crypto_box_open and passes in pKb and sKa, the same keys that were used to encrypt the message. This yields the plain text message. She changes the message, re-encrypts it, and sends it on to Bob. As you correctly observed, Eve having Alice's private key is insecure....

Only top voted, non community-wiki answers of a minimum length are eligible