"해시 → 서명"과 "서명 → 해시"는 디지털 서명 시스템에서 처리 순서에 따라 의미와 보안성이 크게 달라집니다.
✅ 결론부터 말하면:
✅ "해시 → 서명", 즉 평문을 먼저 해싱한 뒤 해시값에 서명을 하는 방식이 표준이며 가장 많이 사용됩니다.
🔒 이것이 RSA, ECDSA, EdDSA 등 모든 주요 전자서명 알고리즘의 기본 방식입니다.
✅ 두 방식 비교
방식설명사용 사례보안성성능
① [해시 → 서명] Hash → Sign |
평문을 해싱하고, 그 해시값에 서명 | ✅ 일반적 / 표준 RSA, ECDSA, TLS, PGP 등 |
✅ 안전 (표준 알고리즘에 적합) | ✅ 빠름 |
② [서명 → 해시] Sign → Hash |
평문에 직접 서명한 후 해시를 계산 | ❌ 일반적이지 않음 암호학적으로 권장되지 않음 |
❌ 위험 (서명 알고리즘에 따라 오류) | ❌ 비효율적 |
✅ ① 해시 후 서명 (Hash → Sign)이 표준인 이유
🔹 이유 1. 속도 (성능)
- 평문이 매우 클 경우, 전부에 서명하려면 시간과 계산량이 큼.
- → **해시값(고정된 크기)**만 서명하면 훨씬 빠르고 효율적임.
🔹 이유 2. 보안 설계에 맞음
- RSA, ECDSA, EdDSA 등은 고정된 길이의 입력값에만 서명을 할 수 있도록 설계되어 있음.
- 해시 함수는 임의 길이의 메시지를 고정된 크기(예: SHA-256은 256비트)로 줄여줌.
- 서명은 이 고정된 해시값에만 적용해야 제대로 작동함.
🔹 이유 3. 일관성과 재현성
- 동일한 평문은 항상 동일한 해시값을 갖기 때문에, 수신자가 서명을 검증하기 쉬움.
❌ ② 서명 후 해시 (Sign → Hash)의 문제점
- 이 방식은 디지털 서명 알고리즘의 정의와 맞지 않음.
- 예: RSA는 "서명 = 해시값을 private key로 암호화"로 정의됨. 즉, 입력이 해시여야 함.
- 평문 전체에 서명을 걸고 그 서명값만 해시로 보호한다면, 보안 의미가 바뀌고, 서명 검증도 표준에 따라 불가능해짐.
✅ 실제 사용 예
프로토콜 / 표준해시 후 서명 사용 여부
TLS/SSL | ✅ 예 (ClientHello 메시지 등에 해시 후 서명 사용) |
PGP / GPG | ✅ 예 |
전자세금계산서, 금융 전자서명 | ✅ 예 |
JWT (JSON Web Token, RS256 등) | ✅ 예 |
블록체인 (Bitcoin, Ethereum 등) | ✅ 예 |
✅ 요약
항목해시 후 서명 (✅ 권장)서명 후 해시 (❌ 일반적 아님)
사용 여부 | 대부분의 표준, 현실 구현에서 사용 | 일반적으로 사용하지 않음 |
보안성 | 높음 (디지털 서명 알고리즘 설계에 부합) | 불명확하거나 위험함 |
성능 | 효율적 (고정된 입력) | 비효율적 (메시지 크기 문제) |
표준 호환 | RFC 3447, X.509, TLS 등 대부분 준수 | 표준 미준수 |
✅ 결론
🔐 디지털 서명은 반드시 평문 → 해시 → 서명 순서로 처리하는 것이 표준이며 안전합니다.
📦 "서명 후 해시"는 디지털 서명의 정의와 맞지 않으며, 보안상 권장되지 않습니다.
👉 그러므로 "해시 후 서명"이 압도적으로 많이 쓰이고, 알고리즘/성능/보안 모든 면에서 표준입니다.
'보안' 카테고리의 다른 글
PKI, 표준인증서 형식 X.509 (0) | 2025.05.09 |
---|---|
전자서명 (1) | 2025.02.07 |
128bit가 가 32개 hexstring인 이유 (0) | 2025.01.22 |
KEK (Key Encryption Key) (1) | 2024.12.18 |
데이터 기밀성 (1) | 2024.12.11 |