p384 — NIST P-384 곡선과 ECDSA 검증
곡선 y² = x³ − 3x + b(소수 p = 2^384 − 2^128 − 2^96 + 2^32 − 1) 위의 ECDSA 서명 검증이다. TLS 1.3 의 ecdsa_secp384r1_sha384 가 이 곡선을 쓴다. 공개 웹의 여러 중간 인증기관과 그 뿌리가 P-384 로 서명하므로, 인증서 체인을 끝까지 확인하려면 이 곡선이 있어야 한다.
무엇을 약속하고 무엇을 하지 않나
왜 p256 을 고쳐 쓰지 않고 따로 두나. p256 은 조각 수 16 을 루프 상한과 작업 공간 자리마다 박아 두었고, 검산이 끝난 채 여러 모듈이 쓰고 있다. 그것을 조각 수로 매개변수화하면 검산이 끝난 코드를 건드리게 된다. 그래서 곡선마다 제 모듈을 두는 규율을 따랐다 — 이 파일은 p256 을 16 조각에서 24 조각으로 옮긴 것이고 식은 한 글자도 다르지 않다. 다른 것은 자리 수뿐이다.
| 자리 | p256 | p384 |
|---|---|---|
| 수 하나(16비트 조각) | 16 | 24 |
| 점 하나(야코비 좌표 X · Y · Z) | 48 | 72 |
| 몽고메리 임시 | 18 | 26 |
| 지수 비트 | 256 | 384 |
표 50.1 — p256 과 p384 는 자리 수만 다르다
| op | 하는 일 |
|---|---|
ecdsa_ok | 서명 (r, s) 가 해시 e 와 공개키 pub 에 맞는가 — ok 1 맞다 · ok 0 아니다 · error short_workspace 작업 공간이 모자라다 |
표 50.2 — p384 의 op
ecdsa_ok 는 곡선 상수(p · n · Gx · Gy)를 호출자에게서 받고, 공개키는 아핀 좌표 x ‖ y(48 조각), 작업 공간 w 는 1364 조각 이상이어야 한다(p256 의 924 를 1.5 배 한 자리). 모자라면 실패로 말한다 — 예전에는 «자리가 모자람» 과 «서명이 틀림» 이 둘 다 0 이었고, 작업 공간을 잘못 준 프로그램이 «서명이 틀렸다» 로 보였다.
검증 계산은 이렇다. r 과 s 가 1 … n−1 안에 있는지를 먼저 보고, 그다음
w = s⁻¹ mod n
u1 = e·w mod n , u2 = r·w mod n
R = u1·G + u2·Q (Q = 공개키 점)
R.x ≡ r (mod n) 이면 참모듈러 곱은 bigint 의 몽고메리 곱을 그대로 쓴다 — p 와 n 이 둘 다 홀수라 조건이 맞고, 새 산술을 또 짓지 않는다. 좌표는 p256 과 같은 까닭으로 야코비 좌표다(역원을 맨 끝 한 번으로 미룬다).
확인하는 것 — 우리가 지은 것이 아닌 오라클 둘에 맞댄다. ① openssl(secp384r1 · SHA-384)이 짓고 openssl dgst -verify 가 맞다고 한 서명 한 벌 — 양성 하나와 음성 셋(s 한 비트 · 해시 한 비트 · s = 0). ② 진짜 인증기관이 서명한 진짜 인증서 체인(몇몇 공개 사이트의 중간 마디가 P-384 다). NIST CAVP 시험 벡터는 아직 돌리지 않았다 — 그 파일이 저장소에 없다. 이 모듈의 소비자는 verify 다.