# Tag Info

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

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

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

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

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

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

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

The client generates a random symmetric key and encrypts it with the public key. This public key needs to be trusted. Make sure you use a good padding mode, OAEP should do it. Send to server, server decrypts it with the private key. Eh, that's it. No forward security though, the session can be decrypted if the RSA scheme is broken or if the private key is ...

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

Guess the catch in the video is in how the participants exchange details 'publicly'. If the Man-In-The-Middle can intercept and manipulate what is being 'publicly' shared, then the attempt to eavesdrop would still be successful.

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

1

The fact that $g$ is a generator (or not) of the group of inverse elements $G={\bf F}_p^{*}$, indeed does not affect the relation you wrote. But, if you want to apply Diffie-Hellman in a secure way, the order of $g$ has to be large. Say you choose a large prime $p$ (at least $1024$ bits). If $g$ is not a generator of $G$ then the order of $g$ shall divide ...

1

In cases where Alice and Bob are guaranteed to arrive at the same key, this is impossible: the function that takes Alice and Bob's private info as input, and produces the public transcript as output, must be a one-way function if the scheme is to be secure and if it always negotiates a shared key. If it sometimes fails, then you don't necessarily get a OWF; ...

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