# Tag Info

15

It is an open standard by IETF.org We can find the details in the mail archive of IETF, D. J. Bernstein's response; It has become increasingly common for "Curve25519" to refer to an elliptic curve, while the original paper defined "Curve25519" as an X-coordinate DH system using that curve. "Ed25519" unambiguously refers to an ...

4

First of all, generally, the shared secret is split in half because it consists of an X and Y coordinate. It is after all the point resulting in multiplying a public key point with a private key / vector, resulting in another point on the curve. Now the X and Y coordinate are related, so generally, only the X coordinate is used as a shared secret. Currently, ...

4

Is X25519 and Ed25519 the same curve? No. X25519 isn't a curve, it's an Elliptic-Curve Diffie-Hellman (ECDH) protocol using the x coordinate of the curve Curve25519. Ed25519 is an Edwards Digital Signature Algorithm using a curve which is birationally equivalent to Curve25519. Is X25519 used by ECDSA? No. It's not a curve, it's an ECDH protocol. What does ...

3

You can. Low-embedding degree may be bad due to the MOV attack, but pairing-friendly curves are particularly chosen so that the embedding degree is low but still enough to not decrease security. So any elliptic curve algorithm should be safe on the curve, not only pairing-based ones. Some observations: ECDSA if often used with NIST curves with cofactor 1. ...

3

A pretty good answer to the question can be found here I try to give a shorter and more precise answer: The Curve25519-standard uses a pretty specific modulo-algorithm. A pseudocode of the algorithm looks like this: def fastModulo(num, prime): # Basecase: if num < prime: return num if num < 2*prime: return num-prime # Split number in ...

3

To be DHKE group, there are five properties to be held, This is true; however, to be a secure DHKE group, there has to be an additional property: The "discrete log problem" needs to be hard; that is, given a public value $xG$ (where $G$ is the public group identifier, $x$ is your private value, and $xG$ is the generator acted upon itself $x$ ...

3

TLS_ECDHE_ECDSA_with_AES_128_CCM ECDHE: Key exchange with Ephemeral Elliptic Curve Diffie-Hellman ECDSA: Signature with Elliptic Curve Digital Signature Algorithm AES_128 : 128-bit Encryption with Advanced Encryption Standard CCM: Mode of Operation with Counter with CBC-MAC which is an authenticated encryption algorithm designed to provide both ...

2

Am I right in thinking they should've piped the whole shared secret through the KDF to "compress" the 256 bits to 128 bits to retain 128-bit security? Using only 128 bits would not be the best practice, but does not open to attack as far as I know, for standard KDFs (which use all the entropy in their input). There's still effectively 128-bit ...

1

Reasoned it through just now. Given the ultimate generator of the elliptic curve group $G'$ Shor $G$ element-wise to obtain an MI $H$ such that $G=H * (G')$, where $*$ is element-wise multiplication. Shor $P$ element-wise against $(G')$ to obtain an MI $J$ Calculate $J\over H$ using Gaussian elimination to obtain $v$ Yeah! I defeated myself in a ...

1

Ignoring the case of $R$ being the point at infinity, I have found a patent that seems to describe the system you outline to a T: US 7,512,232 B2, which also makes me suspect that your "commercial" system ends up being Microsoft's in particular. It specifically notes that taking the square root modulo $\ell$ is a requirement. In other words, no, ...

1

Just for information, you might be interested in following this work that aims at compressing certificates significantly and according to the Expected Certificate Sizes might be appropriate for you. Note that it is far from being completed at this time.

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