# Tag Info

21

The SSL and TLS protocols (on which HTTPS is based) are designed in a way that no attacker (neither a passive nor an active one) can read anything of the encrypted part (if the cryptographic assumptions hold - and if you don't use the NONE cipher, which does no encryption). Of course, the attacker can read the negotiation part. But this part will not ...

15

The security of Diffie-Hellman depends upon the group in which DH is used, but not upon which generator is used for this group. See note 3.53 (chapter 3, page 103) of the Handbook of Applied Cryptography. In more details: for DH, we use a subgroup of size $q$ of the integers modulo $p$ (a big prime) with the multiplication as group operation. $q$ should be ...

13

Both RSA and Diffie-Hellman work with modular exponentiation. But they work in a different way: In RSA, there are two exponentiations which invert each other, i.e. we have $e$ and $d$ such that $(x^e)^d \equiv x$ for all $x$. E.g. if $\square^e$ is the encryption, $\square^d$ is the corresponding decryption. To create this pair of $e$ and $d$ (or derive one ...

13

I assume you're talking about SSL/TLS or a similar protocol. In these protocols there are two reasons to use Diffie-Hellman: Your certificate only supports signing Either it is an RSA certificate restricted to signing, or it uses an algorithm that doesn't support encryption, such as DSA or ECDSA. Forward security - What happens if the server's private key ...

12

Say you encrypt a message with a key $k$. With symmetric encryption (ie. symmetric ciphers), $k$ must be secret. The sender and recipient must agree (somehow) on $k$. No-one else can be allowed to find out $k$. Anyone else who finds out $k$, can decrypt all the messages encrypted with $k$. For that reason, symmetric ciphers are often called "secret key" ...

10

The really great thing about Diffie-Hellman is how light it is, network-wise: both parties send each other a single message; neither has to wait for the message from the peer before beginning to computing his own message. If you can tolerate something heavier, you can have a look at what @Paŭlo describes; with $n$ participants, it requires $n-1$ messaging ...

10

The standard Diffie-Hellman key exchange algorithm (or family of algorithms) works in an cyclic group with generator $g$, and relies on $${y_A}^{x_B} = (g^{x_A})^{x_B} = (g^{x_B})^{x_A} = {y_B}^{x_A},$$ where $y_A$ and $y_B$ are publicly transmitted, while $x_A$ and $x_B$ remain private. With three parties, we still have ((g^{x_A})^{x_B})^{x_C} = ...

8

Well, the advantages of static-ephemeral ECDH (and, they apply to DH as well): You get one-way authentication for free. That is, if Bob has Alice's public ECDH key, and uses it to talk to someone, Bob knows that that someone is Alice, without doing any further checks. Now, Alice has no idea who she's talking to; on the other hand, for some scenarios, ...

8

You can do key agreement with asymmetric encryption. Any asymmetric encryption algorithm (post-quantum or not) can be used for key agreement: just choose a random key and encrypt it. Password Authenticated Key Exchange looks harder, because it cannot be applied on just any key exchange or asymmetric encryption scheme. The IPAKE framework can be applied on ...

8

Well, it depends on the which protocol is being used. For WEP and WPA, the keys used are derived directly from the pre-shared keys; that means that as long as you know the pre-shared keys, you can immediately decrypt packets as well. On the other hand, WPA2 is somewhat stronger; the two sides exchange nonces to derive the keys. Hence, unless you listen ...

6

Yes, it is. Because of the way public key crypto works, they wouldn't be able to decrypt it. First, realize that something encrypted with a public key can only be decrypted with the corresponding private key (or, depending on the algorithm, vice-versa). So lets say everyone (including the sniffer) has the server's public key. You encrypt something with it, ...

6

The check $y_b^q = 1 \mod p$ is there to prevent two possible weaknesses: Suppose someone gave us (either because of a programmer error or deliberate attack) gave us a $y_b$ value of small order. If so, then someone listening in can guess the shared secret you derive. Suppose an attacker gave us a $y_b$ value with an order with a small factor $r$. Then, ...

6

An attack would be trivial if the seed of the RNG was only 32 bits; just enumerate the seeds, and test which matches the intercepted messages. That's easy. However the default Java Random class uses a 48-bit state and seed (which would still be attackable, though $2^{16}$ times less easily), and there are safe subclasses, thus use of Random does not imply ...

6

CRAM-MD5 is a protocol to demonstrate knowledge of a password. In the context of email, it is sometime used by an email client to authenticate to a POP, IMAP, or/and SMTP server. Basically, the password is used as the key of HMAC-MD5 in a challenge-response protocol. Among positive things there are to say about CRAM-MD5: The password is not exchanged in ...

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

5

For authenticated/mutually authenticated key exchange, you can use that piece of TLS. TLS requires public key encryption and a key derivation function for the key exchange (plus a signature algorithm for the PKI, if necessary). There are many post-quantum encryption functions and KDFs are typically based on hashes or MACs, which are also post-quantum. There ...

5

The standard answer in the research literature is to use information-theoretically secure message authentication codes, typically universal hashing (aka Carter-Wegman authenticators). Of course, you could use computationally-secure message authentication codes, like CMAC or HMAC, if you wanted, though that would partly defeat one of the reasons for using ...

5

There is nothing related to passwords in AES. AES uses 128-bit keys, i.e. sequences of 128 bits. How you come up with such a key is out of scope of AES. In some contexts, you want to generate these 128 bits in a deterministic way from a password (and possibly some publicly known contextual data, like a "salt"); this is a job for password hashing. In other ...

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

4

"Is to be encrypted" is not a ultimate goal. You do not encrypt data for the sake of it; you encrypt data as a way to ensure a given security property, e.g. transmitting some data between two machines, without compromising the data confidentiality with regards to attackers who may spy on the transmission line (or even alter data in transit). If: your ...

4

Answering myself... There is now a very analogous alternative to Diffie-Hellman in post-quantum cryptography: Towards quantum-resistant cryptosystems from supersingular elliptic curve isogenies The research paper is very new, but if the results turn out to be secure, this is a very competitive key agreement scheme for post-quantum cryptography.

4

To use a symmetric algorithm for encryption or key-exchange in a way that is secure (i.e. no observer can read the data), both parties (i.e. Alice and Bob) need to have some pre-existing common secret which is not known to any other party (i.e. Eve). There are such pre-shared key algorithms, and they can be used with SSL. But they are not useful for the ...

4

Almost all cryptographic algorithms which use groups actually work in subgroups generated by a conventional element; even if the group as a whole is non-abelian, the subgroup is cyclic, thus abelian. The Anshel-Anshel-Goldfeld protocol tries to use non-commutativity itself, and relies on "how much non-abelian" the group is. All asymmetric cryptographic ...

4

Yes, you can and use a slow hashing function when constructing the verifier. I would recommend using PBKDF2, as it is designed for this purpose. In fact, Wikipedia says: $v$ is the host's password verifier, $v = g^x$, $x = H(s,p)$. Using of functions like PBKDF2 instead of $H$ for password hashing is highly recommended. Thus, you could use ...

4

Think about this, say my public key is 9821347676528476512348612390874073765227653408545634205496835 (note this is not a valid public key, just randomish typing). What does that mean? Big or little endian? Hex or decimal? Specifically for RSA, where is $e$, where is $N$? What is this public key authorized to do (encrypt, sign, etc)? Who has signed this ...

4

Fair exchange protocols aren't new by any means, but there is a lack of layman-friendly material out there, unfortunately. I think the high prevalence of theoretical cryptography in fair exchange protocols may be partially responsible for that. At any rate, here is the basic idea behind a fair exchange protocol. Suppose you have two parties, Alice and Bob, ...

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

3

For your example protocol with RSA-exchange in both directions, combining both keys to one protects against some weaknesses: By combining the random numbers from both sides, the result is really random, even if one of them has a weak or compromised randomness source. If one of the private keys is compromised, in your protocol the attacker can read all the ...

3

The "proper" way to do EKE on a generic group (be it an elliptic curve or any other group) is to do the encryption part by "adding" a group element which is a hash of the password (actually, a hash of a structure containing the password and the names of the two entities involved in the operation, so as to avoid issues with attackers trying to play with ...

3

Doing EKE over an EC group is a tricky (and is something that RFC6124 avoids). The problem, as you note, is preventing an attacker from being able to determine whether a possible decryption is impossible (and hence he can remove that potential password from the list); that turns about to be considerably more involved than you would expect. Even if you skip ...

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