Tag Info

2

The fact is that the discrete logarithm problem (DLP) is solved using different algorithms in the cases of multiplicative groups (where normal DH applies) and elliptic curves (where ECDH applies). The behavior of these algorithms is quite different. For multiplicative groups, where the NFS for logarithm is used, a huge part of the computation depends only ...

1

As a add on to the above answer, it would be insecure to use $g^{x+y}$ as key , because both $g^x$ and $g^y$ will be transmitted publicly and by simply eavesdropping one can easily find the required key i.e $g^{x+y}$.

2

I'm led to believe the use of SHA-1 for the ECDHE parameters is not due to misconfiguration, but is rather the intended (albeit not ideal) behaviour of server-side Schannel. This behavior seems to be present in versions up to Windows Server 2012 R2 and even continues with Windows Server 2016 Technical Preview 3. I've captured handshakes with many, many ...

1

Short answer: No, it is not vulnerable to man-in-the-middle attacks, assuming that Alice and Bob each have the right signature verification key of the other party. Yet, the man-in-the-middle attack could have taken place at the moment of exchanging the signature verification key. So if $sig_{X}$ is party X's signature key, the attack on the exchange itself ...

1

Here is how it can be Vulnerable. Alice: $x$ Bob $y$ Eve $z$ Alice$\rightarrow$ $g^x$ $\rightarrow$ Eve->$g^z$->Bob Bob$\rightarrow$ $g^y$$\rightarrowEve\rightarrow g^z$$\rightarrow$Alice What Alice thinks key is $g^{(xz)}$ what Bob thinks the key is $g^{(zy)}$ Eve can compute both of these values $(g^x)^z$ and $(g^y)^z$ This is why we need ...

3

It is secure against private key exposure but not against replay attacks by Eve. A three-way protocol avoids this, and doesn't need to use timestamps. The description below is from Delfs and Knebl's book Introduction to Cryptography. Each user, say Alice, has a key pair $(e_A, d_A)$ for encryption and another key pair $(s_A, v_A)$ for digital ...

1

On the server, the certificate is stored in a certificate store, that includes a link to the private key. That link really is the name of a CSP (Cryptographic Service Provider) and the name of a container in that CSP. CSP relate to CryptoAPI, the old cryptographic API that is unfortunately hostile to hash functions other than MD5 and SHA-1. Chances are that ...

0

Given the diagram, yes they are randomly selected keys, $P$ is a fixed plaintext and the projection of the output to the keyspace gives you the next input as key to the cipher, thus creating a pseudorandom walk through the keyspace.

1

I want to answer the third question, as all other questions are brilliantly answered. In TLS handshake as in diagram: In DH/ECDH, the "ServerKeyExchange" message will be empty since the value g^x is already present in certificate. This can save server a lot of computation. This will be a advantage in servers with heavy load and save time in CPU ...

3

This feels like homework, and so I won't give you the answer; I'll give you hints: If F(x) = x^e mod n, and (n, e) pair is public, will the first 1024 bits of both plaintext and ciphertext be enough for Eve to read the entire message? If Eve knows the first plaintext $M_0$, and the ciphertext $M_0 \oplus (r^e \bmod n)$, how can Eve recover $r^e \bmod n ... 0 If you don't know, original OTR signs only its own$g^x$. The paper here 0 Typical signatures start by hashing the message. Thus including more data in a signature doesn't increase the size of the signature, if the recipient knows what you signed (in this case, remembered what they sent in step 1). You need to hash more data if you include$g^x\$, but the cost of hashing a public key is quite low. If you didn't include some kind ...

Top 50 recent answers are included