보안

전자서명은 해쉬 후에 서명해야 할까? 전에 해도 될까?

MDanderson 2025. 5. 8. 22:52
 

"해시 → 서명"과 "서명 → 해시"는 디지털 서명 시스템에서 처리 순서에 따라 의미와 보안성이 크게 달라집니다.


✅ 결론부터 말하면:

"해시 → 서명", 즉 평문을 먼저 해싱한 뒤 해시값에 서명을 하는 방식표준이며 가장 많이 사용됩니다.
🔒 이것이 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