# Tag Info

7

What is usually meant by "group encryption" is not what you are after. Group encryption algorithms strive to achieve the following: a given message is encrypted, and may be decrypted only if sufficiently many group members collaborate. This is not what you seek; what you want is a system such that a given message can be encrypted once and every member of the ...

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

Handing keys in general is known as key management. Symmetric keys should be kept secret. Secret key is often used as a synonym for symmetric key. The establishment of symmetric keys can be performed in several ways: (Authenticated) Key Agreement (KA) Sending of an (authenticated) encrypted key, also known as key wrapping Derivation from a base key using ...

6

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

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

One observation is that if we modify the problem so that $M, A, B$ are random invertible matrices, then it is easy to prove the security of the system. In fact, we can prove that the system is informationally secure; that is, for any observed $C_1, C_2$ pair, for any possible value of $K$, there is a unique set of values of $A, B, M$ that yield that $K$ ...

5

Most likely, this 'shared secret' was actually an IKE "preshared key"; it is used to authenticate the two sides (and, for IKEv1, is stirred into the keys). It actually isn't used as a key (and hence someone learning that key cannot use it to listen in, unless they perform an active Man-in-the-Middle attack). I suspect the password is the authentication ...

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

4

Without pairings, there is no known single round tripartite key-exchange algorithm. However, it is possible to do it in two-rounds. For example, refer to the Burmester-Desmedt conference key protocol (http://www.cs.fsu.edu/~burmeste/eurocrypt_plus_proof.pdf) which in fact works for an arbitrary number of users. This being said, would it be possible to find ...

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

I will address your question below, however I have a serious concern that I want to bring up first. I glanced at the $p$ used in ngx_ssl_dhparam, and it is not immediately obvious that it was chosen correctly. Unless you know that whoever generated that value knew what they were doing, you should select a different value. The security of DH depends on, ...

3

PKCS#3 is an older standard which only defines the DH primitive itself. It contains the following information: parameter generation, the Diffie Hellman key agreement algorithm, integer/octet string conversions (as in PKCS#1, RSA) and the specification of an ASN.1 structure for the parameters. The ASN.1 structure is very limited, containing only the necessary ...

3

The key must be kept secret or it is no longer an encryption system. They key must be shared at some point, when is not important, but how is, and how determines when. You can send encrypted messages to someone, then hand them the key on a post-it note at a later point in time so they can decode it, or on a flash drive, or some other physical handoff or ...

3

Since you do not describe why TLS Handshake and IKE are appropriate in your situation, and as long as you don't describe your situation, it's hard to really help you. Also, you haven't stated if it's only IKE that's not appropriate, or if that also includes IKEv2 (which improved the IKE protocol). Therefore, I'll simply assume you meant both. As an ...

3

Given a SSL-enabled web site, the Qualys SSL tester will tell what ciphersuite would be negotiated by a bunch of different browsers if they connected to that web site. It will also tell you the list of ciphersuites supported by that server and the list of ciphersuites are supported by each of those major browsers. For example, here is the output for one ...

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

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

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

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

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

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 guess the best place to begin is with the paper that started it all: Entity authentication and key distribution, by Bellare and Rogaway. In a nutshell, they define a protocol to be a secure mutual authenticated key exchange if it fulfills the following four criteria (I will explain the term "matching conversation" below): Matching conversations ...

2

We know that traditional mathematical proofs can contain mistakes, and that these mistakes can remain undiscovered for years. Sometimes, the scheme is secure even if the proof is incorrect, e.g. RSA-OAEP. Sometimes, the scheme is mildly flawed, the flaws undiscovered because of mistakes in the proof, e.g. HMQV. And sometimes a scheme is simply insecure. We ...

2

In addition to the earlier remarks about the missing background of your question please also consider that TLS and IKEv2 are actually not just a single authentication and key exchange protocol but rather a framework that supports many different AKA protocols. Let us use TLS as an example. In TLS you have the concept of ciphersuites and they allow you to ...

2

First, understand that keys need to last only as long as you need to recover what they are protecting. If you are storing a secret in a box until next year, you have to keep the key until next year. But if we're talking on the phone, we only have to keep the key for the duration of the phone call. If Alice and Bob are going to speak securely, they don't ...

2

In an ordinary ID-based scheme, you won't get strong PFS. The center always knows a secret that can be used to recover your private key and thus can violate PFS. One approach is a hybrid scheme, such as the following. You could do a (non-ID-based) Diffie-Hellman or ECDH key exchange, with messages signed and authenticated using an ID-based signature ...

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