Tag Info

2

I believe that you misunderstand what DH is doing. DH-key-exchange was innovated to defence man-in-the-middle attack, because hackers can not pretend the one you want to communicate without correct share key? or hacker don't know the key generator that Alice and Bob pre-agreed? Well, no, defending against active attackers, that is, attackers who can ...

0

The basic DH key exchange is unauthenticated. Authentication needs a different mechanism and has nothing to do with the key exchange. Depending on the attacker model, authentication is not possible, and especially it is not save vs man in the middle (e.g. in the Dolev Yao model). The attacker can just initiate a key exchange with both Alice and Bob, and ...

3

To use the proper terminology: in TLS, cipher suites which include "some Diffie-Hellman" are: Anonymous Diffie-Hellman: DH_anon Static Diffie-Hellman: DH-RSA, DH-DSS... Ephemeral Diffie-Hellman: DHE-RSA, DHE-DSS... There is no "plain DHE" cipher suite in TLS; it is called "DH_anon". As the name indicates, with DH_anon, the server is "anonymous": you ...

2

No, DHE is secure and allows to share a common secret between two parties over an insecure channel. But you cannot know, if the one you share the secret with is the one you want (DHE is vulnerable to man in the middle attacks). So DHE-RSA uses DHE to share a common secret and signs the communication with RSA to make sure, that both persons communicate with ...

4

The problem doesn't lie with curves in Weierstrass form necessarily, but with naive implementations of elliptic curve arithmetic on such curves. Basically, if you implement an ECC scheme (ECDH, ECDSA or whatever) on a smart card using a curve in Weierstrass form in the most straightforward way possible (by writing a simple double-and-add loop for ...

0

One of the major advantages of GCM is the authenticated data input that you can pass. Think about headers of a message that you want authenticated but not encrypted. This is a great thing to have in many practical implementations where some data has to stay in clear but manipulating it by an attacker has serious consequences.

1

I guess the problem is to find the generator $g$. Denote the factors for $p-1$ to be $p_1 =2, p_2 =2,p_3 = 37, p_4 = 709$. With $p$, and the factorization of $\phi(p)$ you can find a generator in the following way: Randomly choose an element $x$ from $Z_p$ and test whether $x^{\phi(p)/p_i}$ mod $p \ne 1$ for every $i =1,2,3,4$. If this is the case, $x$ is ...

2

Unless you are absolutely sure that you don't need to and that the cost is going to be significant then I would absolutely say you should use authenticated encryption. One reason is bit-flipping attacks - flipping a few bits at the 'right' point in your encrypted message might lead well to a message that is legal (the classic example is if someone learns ...

2

A Diffie-Hellman key agreement has the following general form, presuming it is done in a group $G$ of order $q$ with generator $g$: $A$: Generate $x \in \mathbb{Z}_q$ at random. Calculate $X = g^x$ $B$: Generate $y \in \mathbb{Z}_q$ at random. Calculate $Y = g^y$ $A \to B$: $X$ $B \to A$: $Y$ $A$: Calculate $S = Y^x$ $B$: Calculate $S = X^y$ First ...

0

Add to the list FHMQV (probably covered by MQV and HMQV patents), and SM2 (Chinese standard for authenticated key agreement, patented by Chinese government, IPR terms unclear). I personally would probably use FHMQV (permissions/licensing issues aside). It is highly recommended to avoid trying to design your own. If you cannot use any of the existing ...

0

The SSL/TLS handshake consists of a series of messages which do keyexchange and (usually) authentication together. See rfc5246 or its predecessors or Wikipedia for details. The handshake actually results in one "premaster secret" and one "master secret" which is then used to derive multiple keys: an encryption key for each direction (for an algorithm that ...

Top 50 recent answers are included