Tag Info

Hot answers tagged

6

So your protocol goes like this: Alice generates a key pair $(a_{priv}, a_{pub})$ and sends $a_{pub}$ to Bob. Bob generates a key pair $(b_{priv}, b_{pub})$ and sends $b_{pub}$ to Alice. Alice generates a message $m$ and sends $Enc(Sign(m, a_{priv}), b_{pub})$ (or $Sign(Enc(m, b_{pub}), a_{priv})$, I'm not sure which of both is usually used by PGP) to Bob. ...


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


5

First, I am assuming, per https://security.stackexchange.com/questions/29172/what-changed-between-tls-and-dtls, that the client handshake protocol in DTLS is not different from that in TLS over TCP. This seems a safe bet since the client/server encrypted handshake protocol in OpenVPN's UDP implementation is the same as in standard TLS over TCP. I am not ...


5

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.


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

There are several kind of quantum key distribution (QKD) protocols as of today. Are you looking for a particular one? The best known QKD protocol goes by the name BB84 after its inventors Bennett and Brassard and the year in which they presented their work. Searching on the Internet, I found this link http://fredhenle.net/bb84/demo.php with a simulation ...


3

In TLS, the key exchange step results in a key called the master secret which is then derived into as much key material as needed with a custom key derivation function, called in TLS terminology the PRF. It is not slow -- contrary to PBKDF2, the "PRF" of TLS is not for handling password and thus has no need to be slow.


3

I assume that Alice is capable of accepting a connection while negotiating another, and let $A_2$ and $A_1$ denote her two roles. $\;\; A_1 \to M \:$ : $\:$ Alice, $nonce_1$ $\;\; M\to A_2 \:$ : $\:$ Bob, $nonce_1$ $\;\; A_2 \to M \:$ : $\:$ $nonce_2$, $E_{k_{AB}}\hspace{-0.04 in}(nonce_1||k_2)$ $\;\; M\to A_1 \:$ : $\:$ $nonce_2$, ...


3

If we assume that $E$ is just semantically secure, without providing authenticity and integrity of the encrypted message then this scheme is has a huge drawback. It would be possible for an attacker to pose himself as either A or B, or to alter any message send from A to B. So without authenticated encryption, this scheme may protect against eavesdropping, ...


3

ECDH or DH for that matter doesn't provide any authentication of a user. ECDSA as a public key scheme does provide authentication, but lacks validation. You need to certify that the exchanged public keys are indeed from Alice or Bob. So Alice and Bob must let an authority certify their own public keys such that Alice trusts the authority of Bob and Bob ...


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


2

Yes for sure you can do that. Mapping this protocol to an elliptic curve setting is just like mapping DH key exchange to ECDH key exchange. In AugPAKE you work in a prime order $q$ subgroup of $Z_p^*$ and in the EC setting you use a prime order $q$ elliptic curve group. Observe that in the EC setting a multiplication of group elements in AugPAKE is then ...


2

To make key exchange protocols (providing perfect forward-secrecy) robust against quantum computers they need to rely on assumptions that are not susceptible to quantum attacks (post-quantum crypto) like hash based, lattice based or multivariate-quadratic-equations based. Clearly, quantum key distribution is a candidate for key exchange with all the ...


2

The paper Quantum Key Distribution in the Classical Authenticated Key Exchange Framework gives a key exchange protocol for which the property you describe holds. The paper On Everlasting Security in the Hybrid Bounded Storage Model is about the possibility that your described level of security holds against adversaries whose available memory is strictly ...


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

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


2

I'll assume the obvious: Alice checks $nounce_A$ deciphered from data received at step 2 before proceeding to step 3, and Bob checks $nounce_B$ deciphered from data received at step 3 before proceeding to step 4. Including when $E$ is authenticated encryption (as stated in a comment to the question), and we suppose the origin and step number is inserted in ...


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

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

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


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.


1

Edit: Sorry, I know this is bad form, but I'm replacing my entire answer :). The proof takes place in the so-called CKS-light model, which allows the adversary only two "register honest" queries, i.e. the ability to register two identities of his choice and receive their generated public keys. In the end, he must distinguish the shared secret of these keys ...


1

You're missing that "All exponentiations are done modulo a particular 1536-bit prime". See https://docs.python.org/3.1/library/functions.html#pow.


1

Summary: The statement is ambiguous. My best guess is that the flaw thought in f) is the feasibility of the reflexion-to-different instance attack found by Ricky Demer, allowing Mallory to authenticate to Alice as Bob without involving Bob, constituting a valid attack against 1/2/3 in the Dolev-Yao model, and breaching the "bilateral authentication" goal ...


1

I'm not sure but in my point of view. Since $k_{AB}$ is used to authenticate both side. Mapped $nounce_x:E_{k_{AB}}$$(nonce_x∥k_x)$ pair on one side can be used on both side. Thus we can gather $nounce_x:E_{k_{AB}}$$(nonce_x∥k_x)$ pairs from $B$ since $B$ will happily echo $E_{k_{AB}}$$(nonce_x∥k_x)$ for every $nounce_x$ I asked. This doesn't form ...


1

No, IKEv2 has nothing analogous to 'main mode' and 'aggressive mode', and they eliminated the initial 'quick mode', When IKEv1 was originally written, they wanted a strong separation between IKE and IPSec; they had a vision where IKE might be used for things other than IPSec (other "Domains of Interpretation"). So, they completely isolated the "negotiate ...


1

…what if I only verify the signature of one end? Bob would not be able to know if he is looking at a signature by Eve, or if it’s a valid signature coming from Alice. In case if Eve is messing with the exchange, Eve would be able to inject her own (as it is handled non-authenticated) and Eve would be able to verify that it’s Bob on the other end (which ...



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