Tag Info

Hot answers tagged

9

ECDSA is a digial signature algorithm ECIES is an Intergrated Encryption scheme ECDH is a key secure key exchange algorithm. First you should understand what are the purpose of these algorithms. Digital signature algorithms are used to authenticate a digital content.A valid digital signature gives a recipient reason to believe that the message was created ...


7

ElGamal appears to be used instead of Diffie-Hellman (or IES) in OpenPGP mostly because when that format was put together, there were some unresolved intellectual property issues surrounding both RSA and Diffie-Hellman, while ElGamal was unproblematic. This trend for ElGamal seems to stick around, mostly by force of habit, e.g. when switching to ...


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

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

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

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


4

The major thing missing from Diffie-Hellman is that it provides no protection from someone running a man-in-the-middle attack. Your changes don't actually do anything to prevent that. That is, suppose Eve was between Alice and Bob; when Alice sends the first message to Bob, Eve intercepts the message, and performs the exchange with Alice. At the same ...


4

That was a bad edit to Wikipedia. The phrase "Carry-forward verification" is not a standard, well-known term in the cryptographic literature. It should not have been included in Wikipedia without a reference to something more specific. But oh well, no one is perfect, sometimes these things happen. Your request for an elaborate survey of MITM defence is ...


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

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

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

A possible deficiency is that if the use made of any $K_j$ allows it to leak, all later security is lost. That makes $K_j$ plain unsuitable in some uses, e.g. directly as keystream for short messages. The $K_j$ must be wide enough that it is extremely unlikely that a cycle is ever reached in deriving them. For plausible parameters that translates to ...


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

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

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

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

If the attacker M is impersonating both A and S, then he obviously doesn't have to bother sending the third message in the protocol to himself. Thus, the protocol reduces to: M(A) → B: A, Na B → M(S): B, {A, Na, Tb}Kbs, Nb M(A) → B: {A, Kab, Tb}Kbs, {Nb}Kab where M(A) and M(S) denote M impersonating A and S respectively. By itself, this is not a ...


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

What you are describing is known as the Photon Number Splitting Attack (PNS), described for the first time (I think) by Brassard, Lütkenhaus, Mor ans Sanders in this 1999 paper. Several countermeasures have been invented since (single photon sources, robust protocols, decoy states), but detailing them would stray away from of your question. If one sends 2 ...


2

Disclaimer: I am not familiar with Identity-Based Key Exchange, know only the most basic Identity-Based Encryption setup, and restrict to that. For other than trivialities, I refer to Ricky Demer's answer. The defining property of Identity-Based Encryption is: a user's ID and the KGC's public key is all it takes to encipher; and a user gets from a Key ...


2

There are plenty of papers on forward-secure IBE, one could just google that term. Here, I will focus on IBE with a property that I would call "key forgetting", and work toward a candidate construction for depth-O(1) HIBE with that property. One could apply either of the sections "Random Oracles, depth-O(1) adaptive-ID security, and (lack of) ...


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

Your proposal is theoretically sound. If an attacker gets $K_5$ the only way to get previous keys would be to "rollback" the hash. If the hash function is secure, this should not be feasible. You could probably even prove it using the random oracle model, for example.


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



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