Ed25519의 개인 키는 32바이트 난수이고, 이를 SHA-512로 해시한 앞 32바이트를 가지치기해 비밀 스칼라를 만듭니다. 공개 키는 기준점에 이 스칼라를 곱한 점의 32바이트 인코딩이며 서명은 R과 S 각 32바이트입니다. 이 글은 2026-10-27에 연 RFC 8032(Informational, 2017년 1월)로 확인한 범위만 다룹니다.
확인 기준일 2026-10-27 · 다음 확인 예정 2026-11-26
공개 키는 어떻게 만들어질까?
32바이트 개인 키를 SHA-512로 해시해 64바이트를 얻고 앞 32바이트만 공개 키 계산에 씁니다. 가지치기는 첫 바이트의 낮은 3비트를 지우고, 마지막 바이트의 최상위 비트를 지우며, 그 다음 상위 비트를 세웁니다. 이 값을 리틀엔디언 정수 s로 읽어 [s]B를 계산합니다. 인코딩은 y좌표를 32바이트 리틀엔디언으로 쓰고 x좌표의 최하위 비트를 마지막 바이트의 최상위 비트에 복사합니다.
| 항목 | 원문 값 |
|---|---|
| p | 2^255 − 19 |
| b | 256 |
| H(x) | SHA-512(dom2(phflag, context) || x) |
| 군 위수 L | 2^252 + 27742317777372353535851937790883648493 |
| a | −1 |
| 공개 키·서명 크기 | 공개 키 32바이트, 서명 R 32바이트 + S 32바이트 |
서명은 무엇을 해시할까?
해시의 뒤쪽 절반을 prefix로 두고 SHA-512(prefix || 메시지)를 정수 r로 읽어 점 R=[r]B를 만듭니다. 이어 SHA-512(R || A || 메시지)를 정수 k로 읽고 S=(r+k·s) mod L을 계산합니다. 서명은 R과 S의 리틀엔디언 인코딩을 이은 것입니다. Ed25519에서는 dom2가 빈 문자열이라 context를 쓸 수 없고, 먼저 해시한 뒤 서명하는 Ed25519ph와 context를 받는 Ed25519ctx는 별도 변형입니다.
검증에서 S 범위를 왜 확인할까?
원문은 디코딩한 S가 L보다 작은지 확인하기 때문에 서명이 가변적이지 않다고 설명합니다. 이 확인이 없으면 S에 L의 배수를 더해도 통과하는 다른 서명이 만들어집니다. 다른 곡선 서명의 가변성 이야기는 EVM ecrecover 서명 가변성 글에 있습니다.
검증식은 왜 8을 곱할까?
검증은 [8][S]B = [8]R + [8][k]A’를 확인하며 인수 8은 곡선 상수(cofactor)입니다. 원문은 곱하지 않아도 보안상 필수는 아니라고 하면서, 구현마다 유효한 서명 집합이 달라지는 것을 피하려는 응용이 있다고 설명합니다. 원문은 EdDSA를 Schnorr 서명 체계의 변형으로 소개합니다. 비트코인의 Schnorr 서명은 비트코인 Schnorr 서명 글에서 따로 다루며 이 명세와 같은 규격은 아닙니다.
자주 묻는 질문
개인 키가 32바이트인데 해시는 왜 64바이트인가요?
SHA-512 출력이 64바이트이고, 앞 절반은 비밀 스칼라에, 뒤 절반은 서명 때 쓰는 prefix에 씁니다.
Ed25519ph와 Ed25519ctx는 무엇인가요?
Ed25519ph는 입력을 SHA-512로 먼저 해시한 뒤 서명하고, Ed25519ctx는 최대 255바이트의 context를 받으며 비워 두지 않도록 권고합니다. 일반 Ed25519는 context가 비어 있어야 합니다.
보안 강도는 얼마로 적혀 있나요?
Ed25519와 Ed25519ph는 명목상 128비트이고, Ed448 계열은 224비트라고 원문이 적습니다.
