Skip to content

note.md

Latest commit

 

History

History
18 lines (15 loc) · 1.71 KB

note.md

File metadata and controls

18 lines (15 loc) · 1.71 KB

Proj#6 ECDSA

개인키 d는 mod q 상에서 구한다. 하지만 d = 0인 경우 공개키 dG = 0이 되어버리기 때문에, 공개키만으로 개인키를 추정할 수 있게 된다. 따라서 d는 [1, q-1] 범위에서 고른다.

  • 질문: 그렇다면 [1, q-1] 범위에 있는 어떤 수를 G에 곱하더라도 0이 나오지 않는가?
    • 답변: 그렇다. 왜냐하면 G를 고를 때, qG = 0이며 q가 이를 만족하는 가장 작은 양의 정수가 되도록 정했기 때문이다.
p:  FFFFFFFF00000001000000000000000000000000FFFFFFFFFFFFFFFFFFFFFFFF
n:  FFFFFFFF00000000FFFFFFFFFFFFFFFFBCE6FAADA7179E84F3B9CAC2FC632551
Gx: 6b17d1f2e12c4247f8bce6e563a440f277037d812deb33a0f4a13945d898c296
Gy: 4fe342e2fe1a7f9b8ee7eb4a7c0f9e162bce33576b315ececbb6406837bf51f5

p, n, Gx, Gy는 모두 256비트(32바이트)이다.

  • 질문: Gx, Gy는 256비트가 아니지 않은가? Gx의 최상위 바이트가 01101011b이기 때문이다. 또한 Gy도 최상위 바이트가 01001111b이다. 다시말해 둘은 각각 255비트 아닌가?
    • 답변: 맞다. Curve P-256상에서의 ECDSA에서 엄밀하게 256비트 길이인 변수는 모듈러인 p와 차수 n 뿐이다.

mpz_export할 때 출력 버퍼에 왼쪽부터 채워지는 문제가 있다. 예를 들어, 0x012345를 값으로 갖는 mpz_t 변수를 32바이트 버퍼에 mpz_export를 하게되면, 버퍼의 가장 왼쪽 3바이트만 0x012345로 채워지고 나머지 29바이트는 이전 값을 갖는다. 우리가 기대하는 동작은 가장 오른쪽 3바이트에 0x012345가 채워지고, 나머지 29바이트는 0x00으로 채워지는 것인데 그렇게 동작하지 않는다.