Hot answers tagged key-exchange
19
The SSL and TLS protocols (on which HTTPS is based) are designed in a way that no attacker (neither a passive nor an active one) can read anything of the encrypted part (if the cryptographic assumptions hold - and if you don't use the NONE cipher, which does no encryption).
Of course, the attacker can read the negotiation part. But this part will not ...
13
The security of Diffie-Hellman depends upon the group in which DH is used, but not upon which generator is used for this group. See note 3.53 (chapter 3, page 103) of the Handbook of Applied Cryptography.
In more details: for DH, we use a subgroup of size $q$ of the integers modulo $p$ (a big prime) with the multiplication as group operation. $q$ should be ...
13
I assume you're talking about SSL/TLS or a similar protocol. In these protocols there are two reasons to use Diffie-Hellman:
Your certificate only supports signing
Either it is an RSA certificate restricted to signing, or it uses an algorithm that doesn't support encryption, such as DSA or ECDSA.
Forward security - What happens if the server's private key ...
12
Say you encrypt a message with a key $k$.
With symmetric encryption (ie. symmetric ciphers), $k$ must be secret. The sender and recipient must agree (somehow) on $k$. No-one else can be allowed to find out $k$. Anyone else who finds out $k$, can decrypt all the messages encrypted with $k$. For that reason, symmetric ciphers are often called "secret key" ...
12
Both RSA and Diffie-Hellman work with modular exponentiation. But they work in a different way:
In RSA, there are two exponentiations which invert each other, i.e. we have $e$ and $d$ such that $(x^e)^d \equiv x$ for all $x$. E.g. if $\square^e$ is the encryption, $\square^d$ is the corresponding decryption. To create this pair of $e$ and $d$ (or derive one ...
9
The really great thing about Diffie-Hellman is how light it is, network-wise: both parties send each other a single message; neither has to wait for the message from the peer before beginning to computing his own message.
If you can tolerate something heavier, you can have a look at what @Paŭlo describes; with $n$ participants, it requires $n-1$ messaging ...
9
The standard Diffie-Hellman key exchange algorithm (or family of algorithms) works in an cyclic group with generator $g$, and relies on
$$ {y_A}^{x_B} = (g^{x_A})^{x_B} = (g^{x_B})^{x_A} = {y_B}^{x_A}, $$
where $y_A$ and $y_B$ are publicly transmitted, while $x_A$ and $x_B$ remain private.
With three parties, we still have
$$((g^{x_A})^{x_B})^{x_C} = ...
8
Well, it depends on the which protocol is being used.
For WEP and WPA, the keys used are derived directly from the pre-shared keys; that means that as long as you know the pre-shared keys, you can immediately decrypt packets as well.
On the other hand, WPA2 is somewhat stronger; the two sides exchange nonces to derive the keys. Hence, unless you listen ...
7
Well, the advantages of static-ephemeral ECDH (and, they apply to DH as well):
You get one-way authentication for free. That is, if Bob has Alice's public ECDH key, and uses it to talk to someone, Bob knows that that someone is Alice, without doing any further checks. Now, Alice has no idea who she's talking to; on the other hand, for some scenarios, ...
6
You can do key agreement with asymmetric encryption. Any asymmetric encryption algorithm (post-quantum or not) can be used for key agreement: just choose a random key and encrypt it.
Password Authenticated Key Exchange looks harder, because it cannot be applied on just any key exchange or asymmetric encryption scheme. The IPAKE framework can be applied on ...
6
The check $y_b^q = 1 \mod p$ is there to prevent two possible weaknesses:
Suppose someone gave us (either because of a programmer error or deliberate attack) gave us a $y_b$ value of small order. If so, then someone listening in can guess the shared secret you derive.
Suppose an attacker gave us a $y_b$ value with an order with a small factor $r$. Then, ...
6
An attack would be trivial if the seed of the RNG was only 32 bits; just enumerate the seeds, and test which matches the intercepted messages. That's easy.
However the default Java Random class uses a 48-bit state and seed (which would still be attackable, though $2^{16}$ times less easily), and there are safe subclasses, thus use of Random does not imply ...
5
Yes, it is. Because of the way public key crypto works, they wouldn't be able to decrypt it.
First, realize that something encrypted with a public key can only be decrypted with the corresponding private key (or, depending on the algorithm, vice-versa).
So lets say everyone (including the sniffer) has the server's public key. You encrypt something with it, ...
4
To use a symmetric algorithm for encryption or key-exchange in a way that is secure (i.e. no observer can read the data), both parties (i.e. Alice and Bob) need to have some pre-existing common secret which is not known to any other party (i.e. Eve).
There are such pre-shared key algorithms, and they can be used with SSL. But they are not useful for the ...
4
For authenticated/mutually authenticated key exchange, you can use that piece of TLS. TLS requires public key encryption and a key derivation function for the key exchange (plus a signature algorithm for the PKI, if necessary). There are many post-quantum encryption functions and KDFs are typically based on hashes or MACs, which are also post-quantum. There ...
4
Almost all cryptographic algorithms which use groups actually work in subgroups generated by a conventional element; even if the group as a whole is non-abelian, the subgroup is cyclic, thus abelian. The Anshel-Anshel-Goldfeld protocol tries to use non-commutativity itself, and relies on "how much non-abelian" the group is.
All asymmetric cryptographic ...
4
Yes, you can and use a slow hashing function when constructing the verifier. I would recommend using PBKDF2, as it is designed for this purpose.
In fact, Wikipedia says:
$v$ is the host's password verifier, $v = g^x$, $x = H(s,p)$. Using of functions like PBKDF2 instead of $H$ for password hashing is highly recommended.
Thus, you could use ...
4
Think about this, say my public key is
9821347676528476512348612390874073765227653408545634205496835 (note this is not a valid public key, just randomish typing).
What does that mean? Big or little endian? Hex or decimal? Specifically for RSA, where is $e$, where is $N$? What is this public key authorized to do (encrypt, sign, etc)? Who has signed this ...
3
Diffie-Hellman and RSA are distinct and do not use the same "trick".
In Diffie-Hellman, commutativity is used: $(g^a)^b = (g^b)^a$. Both Alice and Bob do two modular exponentiations each (Alice chooses $a$, computes $g^a$ and sends it to Bob, receives $g^b$ from Bob, and finally computes $(g^b)^a$). Security relies on the difficulty of discrete logarithm: ...
3
DH and RSA are definitely not the same. DH is a key exchange algorithm, RSA an encryption/signing algorithm.
Now as to whether are operate in the the same way in the scenario you describe. They can indeed be used for a similar purpose. However, the operate on a fundamentally different mathematical problem. DH uses DLP (discrete logarithm), trusting on the ...
3
The mathematical problems behind DH and RSA are similar but not known to be directly related. It is still an open question if an oracle breaking DH can be used to construct another oracle that breaks RSA (or vice versa). It is mostly believed that the two problems are not reducible to each other in poly time.
However, the complexity of the fastest known DH ...
3
For your example protocol with RSA-exchange in both directions, combining both keys to one protects against some weaknesses:
By combining the random numbers from both sides, the result is really random,
even if one of them has a weak or compromised randomness source.
If one of the private keys is compromised, in your protocol the attacker can
read all the ...
3
Answering myself...
There is now a very analogous alternative to Diffie-Hellman in post-quantum cryptography: Towards quantum-resistant cryptosystems from supersingular elliptic curve isogenies
The research paper is very new, but if the results turn out to be secure, this is a very competitive key agreement scheme for post-quantum cryptography.
3
The "proper" way to do EKE on a generic group (be it an elliptic curve or any other group) is to do the encryption part by "adding" a group element which is a hash of the password (actually, a hash of a structure containing the password and the names of the two entities involved in the operation, so as to avoid issues with attackers trying to play with ...
3
Doing EKE over an EC group is a tricky (and is something that RFC6124 avoids). The problem, as you note, is preventing an attacker from being able to determine whether a possible decryption is impossible (and hence he can remove that potential password from the list); that turns about to be considerably more involved than you would expect.
Even if you skip ...
3
IBE is advantageous over standard asymmetric methods in one aspect, and that doesn't appear to apply in the case you're interested in.
In both cases, IBE and asymmetric methods require an enrollment process (whether to distribute secrets, or authentication data), so there's no real difference there.
However, when Alice wants to send a message to Bob, with ...
3
Yes. Simply send the data in the clear.
Passive attacks are not possible. For a passive attack to work, the data must be intercepted by someone other than the intended recipient. But by your definition of "pre-shared information" the existence of an intended recipient would count as "pre-shared information" (since both sides would know this). So anyone who ...
3
Yes, these are key derivation functions basically deriving a shared secret from information identifying the two parties (like their respective MAC addresses) and nonces and other session communication relevant information. See e.g. the PBKDF2 derivation function.
3
The standard answer in the research literature is to use information-theoretically secure message authentication codes, typically universal hashing (aka Carter-Wegman authenticators). Of course, you could use computationally-secure message authentication codes, like CMAC or HMAC, if you wanted, though that would partly defeat one of the reasons for using ...
3
Fair exchange protocols aren't new by any means, but there is a lack of layman-friendly material out there, unfortunately. I think the high prevalence of theoretical cryptography in fair exchange protocols may be partially responsible for that.
At any rate, here is the basic idea behind a fair exchange protocol. Suppose you have two parties, Alice and Bob, ...
Only top voted, non community-wiki answers of a minimum length are eligible
