평문 서명은 해롭다
Source: Hacker News
번역할 텍스트가 제공되지 않았습니다. 번역이 필요한 본문을 알려주시면 한국어로 번역해 드리겠습니다.
PGP의 클리어텍스트 서명 – 함정과 검증
1990년대 초반 최초의 PGP 버전부터, PGP(및 이를 기반으로 한 모든 구현)는 클리어텍스트 서명이라는 기능을 지원해 왔습니다. 오늘날에도 이러한 서명을 만나게 될 것입니다. 아래는 클리어사인된 메시지의 예시입니다:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Far out in the uncharted backwaters of the unfashionable end of
the western spiral arm of the Galaxy lies a small unregarded
yellow sun.
-----BEGIN PGP SIGNATURE-----
iJEEARYKADkWIQSHd0YfKgdOvEgNNZQZzByeCFsQegUCaU5mGhsUgAAAAAAEAA5t
YW51MiwyLjUrMS4xMSwyLDIACgkQGcwcnghbEHq27gEAqE+Cw1FmIlDXyzc1+5K8
3e60/3TjpqpFmkmuot8ZROMBAIrQXMhfN3gr7jdsxLuV1L7+IzHSRyUMlelZSnAs
k+AL
=kCuN
-----END PGP SIGNATURE-----클리어텍스트 서명이 오해를 불러일으킬 수 있는 이유
- 서명된 텍스트는 바로 읽을 수 있지만 올바르게 검증하려면 PGP 도구가 필요합니다. 터미널에 표시된 내용만 보고서는 충분하지 않습니다. 그 이유는 다음과 같습니다:
- 대시(
-)로 시작하거나 문자열From로 시작하는 라인은 이스케이프됩니다. - 많은 터미널 에뮬레이터가 색상이나 커서 이동 시퀀스와 같은 이스케이프 코드를 해석해, 실제와 다른 모습을 보여줄 수 있습니다.
- 대시(
- 실제로 서명된 내용을 확실히 알 수 있는 유일한 방법은 PGP 구현이 전체 메시지를 처리하고 정규화된 서명 텍스트를 출력하도록 하는 것입니다.
GnuPG로 클리어사인된 메시지 검증하기
# gpg 사용 (상태를 출력하고 서명된 텍스트를 signed.txt에 저장)
gpg --verify -o signed.txt message.asc
# gpgv 사용 (스크립트용; trustedkeys.*에 있는 키만 신뢰)
gpgv -o signed.txt message.ascTypical output:
gpg: Signature made Fri 26 Dec 2025 11:40:26 AM CET
gpg: using EDDSA key 8777461F2A074EBC480D359419CC1C9E085B107A
gpg: Good signature from "wk@gnupg.org" [ultimate]
...진단 결과가 신뢰하는 키로부터 좋은 서명임을 보여주면 signed.txt의 내용을 안전하게 사용할 수 있습니다.
여러 키가 같은 메시지를 검증한다면, 모두 동일한 텍스트에 서명한 것입니다.
Note: gpgv는 자동화된 스크립트에서 선호됩니다. 이는 trustedkeys.gpg(또는 trustedkeys.kbx)에 명시된 키로 만든 서명만 허용하기 때문입니다. gpg의 --assert-signer 옵션을 대안으로 사용할 수 있습니다.
권장 사항: 분리 서명(또는 PGP/MIME) 사용
클리어텍스트 서명은 읽기 쉽지만 올바르게 다루기 어렵습니다. 핵심은 정확히 어떤 내용이 검증되었는지를 알아야 한다는 점입니다. 새 메시지를 만들 때는 다음을 권장합니다:
-
분리 서명을 선호:
# 분리 서명 검증 gpg --verify message.sig message.txt gpgv message.sig message.txt(여기서는
-o/--output옵션을 사용하지 마세요; 빈 파일이 생성됩니다.) -
또는 이메일의 경우 PGP/MIME 사용 (서명 또는 암호화된 메일을 위한 현대적 표준 형식).
역사적 배경
1990년대 초반, 인터넷은 아직 보편화되지 않았고 대부분의 통신은 다이얼업 BBS에서 이루어졌습니다. Phil Zimmermann은 수신자가 아직 PGP를 설치하지 않았더라도 ASCII‑인코딩된 메시지를 교환할 수 있도록 PGP를 설계했습니다.
이후 이메일이 BBS를 대체했지만, MIME이 널리 쓰이기까지는 시간이 걸렸습니다. 1996년 Michael Elkins는 Mutt 메일 클라이언트를 위해 PGP/MIME(RFC 2015)을 도입했으며, 점차 클리어텍스트 서명·암호화 메일을 대체했습니다. 오늘날 PGP/MIME은 서명·암호화된 메시지의 사실상 표준이지만, 일부 클라이언트는 아직도 옛 클리어텍스트 형식을 지원합니다.
클리어텍스트 서명이 안전하지 않은 이유
- 아머 라인 조작 –
-----BEGIN PGP …헤더를 대시 수를 줄이거나 비슷한 유니코드 문자로 위조하면, 사용자는 서명된 텍스트가 실제보다 일찍 시작한다고 착각할 수 있습니다. - 주석 라인 – 사용자는
Hash:와 같은 주석 라인이 서명된 텍스트에 포함되지 않는다는 점을 알지 못합니다. 추가 주석 라인을 삽입하면 서명되지 않은 내용이 삽입될 수 있습니다. - 빈 줄 트릭 – 아머 헤더와 서명된 텍스트 사이를 구분하는 빈 줄을 터미널 제어 문자나 기타 특수 문자로 대체하면, 서명 범위가 의도와 다르게 변조될 수 있습니다.
(이하 내용은 다음 파트에서 계속됩니다.)
TF‑8 문자, 보는 이를 혼동시킴.
- 과도하게 긴 줄 – 표시 또는 파싱 이상을 일으킬 수 있음.
이와 같은 다양한 변형들이 지난 30 년간 입증되어 PGP/MIME이 널리 채택되었습니다.
Bottom line
새 데이터에 대해 평문 서명을 피하십시오. 대신 분리 서명이나 PGP/MIME을 사용하고, 화면에 보이는 텍스트가 서명된 그대로라고 절대 가정하지 마세요.