# Tag Info

## New answers tagged ecdsa

3

First to explain you, why you get 512-bit outputs from a 256-bit curve: The output is basically a point (x-coordinate is enough) and a message-dependant value, with the x-coordinate being expressed as integer. You can verify the signature by checking for a specific relationship between the point and the message-dependant value and the public key point. In ...

1

From what you say, I assume that you are talking about the Crypto 3 challenge from HackingWeek. As Ruggero explained, the curve is vulnerable to both the MOV attack and the older FR attack that works similarily, using Weil or Tate pairings (respectivly). A simple sage code for the FR-attack would be: q = 134747661567386867366256408824228742802669457 Zq = ...

3

In your particular case the order of the point divides $p-1$, this means that the embedding degree of your curve is 1. You should be able to apply the MOV attack to transfer your instance of ECDLP into an instance of DLP over $\mathbb{F}_{p}^*$. This would allow you to use the Index Calculus to solve your problem. As the Index Calculus is subexponential, ...

1

In ECDSA, the message is never encoded as a point in the elliptic curve. Signing in ECDSA loosely works like this: \begin{align*} k &= \text{random}(0, n) \\ (x, \_) &= k \cdot G \\ r &= x \bmod n \\ s &= k^{-1}(H(m) + r \alpha) \bmod n \end{align*} $r$ and $s$ are the signature, and as you can see $H(m)$ is only ever used as an ...

Top 50 recent answers are included