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

5

What's to guarantee authentication or message integrity (particularly when Alice and Bob are exchanging which filters were correct and so on)? A pre-authenticated classical channel is an essential requirement in addition to the quantum channel on which the quantum key exchange (QKE) is performed. This implies that Alice and Bob must share an initial ...

5

Let’s take your questions in order. Note that I’m a physicist working in quantum cryptography, so my opinion on this might be biased 1. What about authentication ? The classical channel between Alice and Bob has to be authenticated in order for the protocol to work. Formally, this is a pre-requisite for quantum key distribution (QKD), and is not part of ...

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

Are there any advantages to “1.”, especially when users must communicate the password/key through a separate channel in both cases? As the comments (1, 2) already indicated: the first option “1.” will be easier to communicate. When you talk about a “high-entropy key”, I assume you are generating that high-entropy with a cryptographically secure random ...

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

2

Well, hope that it's not late for this answer. Because it was yesterday that I encountered this problem and I'm new to this wonderful website. According to your description, and as far as I know, this protocol meets your demands very well. First, it works with RSA as you have mentioned in the second paragraph. The original version of this protocol is ...

2

I know how Diffie-Hellman Key Exchange works. Is this the main way of encrypting with PGP, ssh, ssl (https), DKIM, ...? As the name says Diffie-Hellman key exchange is a key exchange protocol, i.e., a protocol where two parties agree on a common secret without having exchanged any secret prior to that, in an interactive way, i.e., both parties are ...

2

Actually recently I found out about a complete QKD simulation toolkit that has become available, accessible online via this link, QKD simulator. It is a parameter-based simulator, so different scenarios (qubit numbers, Eve's influence, etc.) can be set up and simulated.

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

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

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

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

1

See theoretical pi-based stream cipher for why this approach is pointless. In short, you have just traded one problem for another. You still have the task of coming up with random inputs $i,j,k$ to feed to "sqrt of i, offset by j, every kth value". If those inputs aren't sufficiently random, the attacker will simply attack those values. If they are ...

1

The problem you want to make hard in Diffie-Hellman type groups is taking discrete logarithms, whereas you want exponentiation to be easy. Now when you pick a subgroup $G$ of $\mathbb Z^*_n$, the cost of exponentiation will be roughly proportional to $n$ whereas the cost of taking discrete logs will be proportional to $\sqrt{k}$ where $k$ is the order of the ...

1

You can start by reading: https://github.com/openssl/openssl/blob/master/engines/ccgost/README.gost It has examples on how to generate GOST certificates. After that I would suggest running a test SSL/TLS connection with those certificates and openssl s_client and openssl s_server utilities. If it works, you may then recompile OpenSSL and make it dump all ...

1

For a pre-shared secret, you just use a secure MAC to authenticate the key exchange, e.g. for the exchanged public ephemeral keys $A$, $B$ and the resultant shared secret $S$, one side could send $HMAC(PSK, S, A, B)$ and the other $HMAC(PSK, S, B, A)$. Each side can easily verify that the other is using the same exchanged values and shared secret, and that ...

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

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

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

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

1

For the symmetric key, you can approach this problem as a complete graph with order 1000. With the vertexes representing people and the edges representing the symmetric keys. Then each vertex would have degree 999 and, applying the Handshaking lemma, the number of edges would be: (1000 * 999)/2 = 499500 So they would need 499500 symmetric keys to have a ...

1

Can Alice obtain the session key due to the multiplicative properties of the modulus function and the basis of which RSA is built on? Essentially, yes. One way of looking why RSA works (that is, why the encryption and decryption are inverses of each other) is because of two mathematical identities: $$(M^a \bmod N)^b \bmod N = M^{a \cdot b} \bmod N$$ ...

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

Typical scenario is to run the raw shared secret through a key derivation function to generate keys for any symmetric primitives they will use.

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