# Tag Info

## Hot answers tagged key-exchange

10

I recommend avoiding Diffie-Hellman parameter generation. Instead, use a standardized DH group with a sufficiently large modulus (2048-bit or larger). For example, group #14 or #15 from RFC3526 (see sections 3 and 4) would be a good choice. Alternatively, switch to the elliptic curve variant of Diffie-Hellman and use Curve25519. The article you linked to ...

6

Yes, there are a few reasons to prefer ECDH over RSA: ECDH will perform much better; ECDH can provide forward security when used with ephemeral key pairs without a large performance overhead for creating those key pairs; ECDH should be impervious to most oracle attacks, i.e. timing based padding oracle attacks on OAEP. For the forward secrecy you require ...

6

It does not; the equation holds for any element $g$. The fact that $g$ is a generator means only that every element of the group can be obtained a key. This is not at all necessary for the protocol.

4

So is 2 the private key here ? No, it's referred to as a "shared secret" (because it is shared between Alice and Bob, and is secret to everyone else). If there were 'private' and 'public' keys (which is not the standard terminology with DH), then Alice's private key would be $a=6$, and the public key would be $g^a = 8$. In this case, the 'private key' ...

4

This is exactly where automatic protocol analysis tools can help you. For example, using the Scyther tool, the protocol description using symmetric encryption is: /* * Protocol description for Scyther * * Note we use 'K' to model 'k' since Scyther assumes 'k(.,.)' refers * to pre-shared keys between two agents. */ // The protocol description with ...

3

RFC 2945 By Tom Wu the SRP inventor uses x = H(s, H(I, ":", p)) where I is the username demonstrating that can do anything you like to the stretch the password such as prefixing the username then hashing it. So stretching the user entered password before putting it into function using PBKDF2 would increase the time taken for a dictionary attack with no ...

3

Simple solution (with symmetric encryption): Assign each device an ID (probably already present) Store a master key on the server Use a KDF on the master key and the device ID to generate the key for the device. Then you only need the device ID on the device, and the server can re-create that key as required with the master key and the device ID. Of course ...

3

Douglas Stebila published: We demonstrate the practicality of post-quantum key exchange by constructing ciphersuites for the Transport Layer Security (TLS) protocol that provide key exchange based on the ring learning with errors (R-LWE) problem There is also a patch implementing it for OpenSSL 1.0.1f.

3

Sounds like a description of ECIES to me. ECIES is a hybrid cryptosystem that builds upon ECDH. Basically: the static public key of the receiver is used together with an ephemeral key pair generated at the sender. The public key of the receiver and ephemeral private key of the sender are used to generate a "shared secret" using ECDH. This shared secret is ...

3

I think I found an answer in this thread: http://www.gossamer-threads.com/lists/gnupg/users/65236 In short: There is a packet which looks like a key revocation but it could be forged. If an OpenPGP application downloads the key from the server then it does a signature check.

3

Some background on formal key-exchange models The goal of a key-exchange (KE) is to establish a session key between two parties. Naively, we could say that a KE is secure if no adversary will be able to figure out the session key (in full) established between two honest parties. However, in formal security models we take this a bit further and insist that ...

3

I have never heard of this reason, and I don't quite understand it. In general, the security of Diffie-Hellman key exchange is reduced to the DDH assumption. According to this assumption, the result of the key exchange is a group element that is computationally indistinguishable from a random/uniformly distributed element in the group. However, what is ...

3

Yes, if you are using 3rd party key exchange, the 3rd party can read the messages. If that is not the security feature you want, use something else. There are many legitimate scenarios where users are fine with trusting the third party, however. For example, a system setup by my employer to allow encrypted chat between myself and our clients. My employer has ...

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

3

This answer to most of my own question is largely based on information I received from Professor Simon R. Blackburn, one of the author of the recent attack. The method used to generate parameters is not public, e.g. for the matrix $m\in GL(n,\mathbb F)$ which careful choice was acknowledged critical to defeat an earlier version of the attack. The authors of ...

2

$s$ is a shared secret key. It's known to both Alice and Bob. You could call is a private key, but the usual terminology is “secret key” here, for no deep reason. Alice has a private/public key pair: $a$ is her private key, $A$ is her public key. Ditto with $b$ and $B$ for Bob. These values are not useful in isolation though; in normal use, the only point ...

2

I think you're confusing some things here. The usual TLS-handshake with ECDHE (which you really should use, unless you have very good reasons) has two public keys. One of them is signed by the CA, the other one is generated on-the-fly. And before proceeding, please note: (Perfect) Forward secrecy (PFS, not security usually) only means that you don't ...

2

The protocol seems secure. Some comments below. Bob computes the DH shared secret X using his private key and Alice's static public key, and then K(X), the result of applying an appropriate key derivation function (KDF) to the combination of A, B, and X. The DH secret X already depends on both key-pairs. Including the public keys in key ...

2

Well PBKDF is for deriving keys from passwords, you don't need it if your master keys are already safe, just use something like HKDF. (faster) ECDH and DH are certainly the most secure options you have for negotiating session keys. Of course, as you do have a pre-shared master secret you have some interesting new options. Your usage of the HMAC sounds ...

2

PBKDF2 is an acronym for Password Based Key Derivation Function, #2. As you already have a key you need a Key Based Key Derivation Function or KBKDF instead. Currently the most up to date one is probably HKDF, which was - very quickly - also recognized by NIST. There are other KDF's such as KDF1 and KDF2 which are easier to construct (not many libraries ...

2

The usage of the r key forces both parties to "fix" the public DH keys. So Alice doesn't know Bob's public DH key before she's generating her own one. And Bob can not make the choice of the public key dependant on Alice's choice and vice versa. This forces both parties to be honest and to generate both public keys at random as there is no opportunity to ...

2

One real problem is that lack of authentication between the two sides. Here's one possible problem: Alice generates an RSA keypair (we assume Alice is using proper random numbers) Alice sends the public key as plain text to Bob. Eve intercepts this message, and forwards on a message to Bob with her public key Bob generates a 3DES session key: ...

2

This is a very difficult question. But first the standard information: Don't roll your own crypto if anyhow possible. (which isn't the case here) No protocol should be considered secure until formally proven secure. (TLSv1.2 is) That being said I can still provide "ad-hoc" security argumentations why it's likely that your handshake is (in)secure.I can't ...

2

Fkraiem's answer is correct: this is not necessary. From your comment on his answer it seems however you don't understand why Alice and Bob retrieve the same key. This, again, doesn't rely on $g$ being a generator. Recall from your high school math classes that $(g^a)^b = g^{ab} = g^{ba} = (g^b)^a$. This is basically the trick that is being used here. Since ...

2

That's a bit of a strange question. ECDH is a key agreement protool. ECC does not have a direct form of encryption as RSA has. ECIES is basically ECDH used to derive a symmetric key, which is then used to encrypt the plaintext. You can see it as a delayed form of key agreement. So your question is if ECIES can be used to encrypt session keys. That would ...

1

Your scheme is not a good approach -- it is not safe. Your scheme is vulnerable to rollback attacks. Ideally, the security property we'd like is that this will select the best (highest) version that both client and server support. However, that security property is not achieved. A man-in-the-middle can force both parties to end up using the worst ...

1

The key exchange should also be authenticated. $\:$ GCM mode would mostly do that; however, you should authenticate an indication of which message is for Diffie-Hellman. (For example, you could use associated_data = 1 for the Diffie-Hellman messages and associated_data = 0 || application's_associated_data for application-level messages.)

1

Taking a stab at answering my own question. First, this is very similar to STS (Station to Station) protocol and the KEA+ (Key Exchange Algorithm), which I had not seen before. I've refined the algorithm above and changed a few variable names for clarity (w, y become a, b; v, h become X, Z). Changes from the earlier version include removing the $kh$ and ...

1

Note: Until told otherwise this answer will assume the following things: The "Master-Key" is secure. (unextractable, 128-bit+ entropy) Ephermal (EC-) Diffie-Hellman is available and secure (keys unextractable, 2048 bit DH / 256 bit ECDH available) The random number generator used is secure. (i.e. not just relies on the time, e.g. it's a cryptographically ...

1

Key stretching usually means using a Password-Based Key Derivation Function (PBKDF), these are designed to be more resource intense than standard hashing, which is designed to be as fast as possible. A salt is used to prevent that two derived keys are differentely so that you'd need to brute-force each password independentely. Usually you derive a key from ...

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