# Tag Info

14

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 ...

4

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: [...

3

TL;DR: Using words instead of strings / images may be a good solution for short, easy-to-verify codes and using locality / time dependent verification codes strengthens short hashes as would using password-hashes. Additionally to the improvements to comparability of the hash proposed by A. Toumantsev, I will propose three extra measures which I believe may ...

3

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 ...

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 ...

3

Any shared secret can be used. Securely distributed passwords and symmetric keys, for example. Alternatively, you can use asymmetric cryptography, such as public keys. For one example, SSH has for years authenticated servers using public key cryptography and users typically using either public keys or passwords. Only recently had SSH added support for ...

2

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 ...

2

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 to ...

2

What you observed here is a "special" and "unusual" behavior of the NaCl interface in the way it handles the crypto_box. What the crypto_box does is basically perform a static Diffie-Hellman key-exchange (using your secret and the recipient's public key) between you and the receiver and derive keys from that. So you get the same symmetric encryption key for ...

2

First - please REALLY check the certificate, download it, open and have a look into details (4096 bit, 30y validity). I don't think your government wants to be insecure themselves (so other parties will act on behalf of it). If the certificate is to be used as a root (or issuing) certificate for other nationally issued certificates, you need it to be ...

1

I'm not commenting on the security side of the solution, there are real experts here who can help with this (or turn your idea right down ;) ). However, assuming your solution (with SHA256) is acceptable and secure, your main problem seems to be that "carefully comparing all the digits of a SHA-256 hash .. takes a while". Indeed, comparing a string of 64 ...

1

Short answer: No, it is not vulnerable to man-in-the-middle attacks, assuming that Alice and Bob each have the right signature verification key of the other party. Yet, the man-in-the-middle attack could have taken place at the moment of exchanging the signature verification key. So if $sig_{X}$ is party X's signature key, the attack on the exchange itself ...

1

Here is how it can be Vulnerable. Alice: $x$ Bob $y$ Eve $z$ Alice$\rightarrow$ $g^x$ $\rightarrow$ Eve->$g^z$->Bob Bob$\rightarrow$ $g^y$$\rightarrowEve\rightarrow g^z$$\rightarrow$Alice What Alice thinks key is $g^{(xz)}$ what Bob thinks the key is $g^{(zy)}$ Eve can compute both of these values $(g^x)^z$ and $(g^y)^z$ This is why we need ...

1

When I sign a message (which has potentialy low entropy) using a private key and i send it without the original message, can the original message be retrieved from the Signaturen? It depends. If you use a signature scheme with appendix it will be impossible to recover the message using other ways than brute-force (so the answer would be "yes" for low-...

1

Saying that ECDH does not do authentication is not entirely accurate. If you use ECDH with static, known public keys and both sides prove knowledge of the shared secret, then you do get authentication. However, with ephemeral keys you need some way to authenticate the exchange of public keys. That could be ECDSA or it could be any other authentication. So ...

1

Suppose the server does not check the Client Finished value. This means that the MITM could change some handshake messages and the server would not know this (e.g., downgrade, as you mentioned). So, you could use this to fool a server that doesn't check the Client Finished value. If n bits are checked by the server, you have a 1/2^n chance of getting ...

1

No, this scheme isn't secure. As far as I understand your description you are using the hashed public key of Alice as the symmetric key to a cipher, but as you already just send this hash over the line, the attacker can simply decrypt $k$ himself and thereby $k$ isn't established as a pre-shared key. By the way, there's no way to recover $pk$ from $H(pk)$ ...

1

Simply put, there are two key-pairs for DHE_RSA instead one key-pair of RSA_RSA. For example, for AES128_CBC_SHA(long name is RSA_RSA_AES128_CBC_SHA), you have one key-pair for both key-exchange and authentication. for ECDHE_RSA_AES_CBC_SHA, you have two key-pairs. The ECC key-pair is temporary for key-exchange. The RSA key-pair from cert is used for ...

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