3.0 정보와 암호 — 비트의 양, 변조, 도청, 신원은 다른 문제다
HTTPS 요청 하나에도 압축, 오류 검출, 암호화, 인증이 함께 작동한다. 각각의 계약을 분리해야 무엇이 깨졌고 무엇을 믿을 수 있는지 판단할 수 있다.
개발자는 매일 gzip, SHA-256, JWT, TLS를 사용한다. 그러나 이 이름들은 하나의 "보안" 기능이 아니다. gzip은 중복을 없애 전송량을 줄이고, 오류 정정 부호는 손상에 견디려고 중복을 더한다. 암호는 키가 없는 관찰자에게 구조가 보이지 않게 만들고, 인증서는 공개키를 서버 이름에 묶는다. 한 도구로 다른 문제를 대신 풀 수 없다.
이 챕터에서 답할 네 질문
1. 데이터의 실제 크기는 얼마인가
AAAAAAAA와 난수 8바이트는 같은 64비트지만 예측 가능성은 다르다. 정보량은 저장 공간의 물리적 길이만이 아니라 사건의 불확실성을 잰다. 3.1 정보 이론에서는 엔트로피가 무손실 압축의 하한을 정하는 이유와, 오류를 찾고 고치려면 왜 반대로 중복을 넣어야 하는지 살핀다.
2. 내용을 숨기는 것과 변조를 찾는 것은 어떻게 다른가
암호문을 읽지 못한다고 해서 공격자가 비트를 바꾸지 못하는 것은 아니다. 기밀성(confidentiality)과 무결성(integrity)은 별도 계약이며, 현대 API는 둘을 AEAD로 조립한다. 3.2 대칭 암호와 무결성에서는 AES 운용 모드, 해시, HMAC, KDF를 "무엇을 보장하고 어떤 오용에서 무너지는가"로 구분한다.
3. 처음 만난 상대와 어떻게 같은 키를 갖는가
대칭 암호는 양쪽이 이미 같은 비밀 키를 가졌다고 가정한다. 인터넷에서는 이 키를 전달하는 통신도 도청된다. 3.3 비대칭 암호와 키 교환에서는 Diffie–Hellman, RSA, 타원곡선, 서명이 키 분배 문제를 어떻게 나누어 푸는지 추적한다.
4. 그 공개키가 정말 상대의 것임을 누가 보증하는가
키 교환만으로는 중간자 공격을 막지 못한다. 공격자가 양쪽과 각각 키를 합의할 수 있기 때문이다. 3.4 인증서와 TLS 신뢰 사슬에서는 X.509 인증서, CA, 이름 검증이 공개키를 신원에 묶고 TLS 1.3이 앞선 프리미티브를 조립하는 방식을 분석한다.
하나의 요청에 겹친 네 계약
application data
│
├─ 압축: 예측 가능한 중복을 제거한다 ── 양
├─ AEAD: 암호화하고 인증 태그를 붙인다 ── 도청·변조
├─ TLS record/TCP/IP: 전송 단위로 나누어 보낸다
└─ 인증서 검증: 공개키와 요청한 서버 이름을 묶는다 ── 신원압축은 보통 암호화보다 먼저 한다. 좋은 암호문은 통계적 구조가 거의 보이지 않아 압축할 중복이 없기 때문이다. 그러나 압축 결과의 길이는 입력에 관한 단서가 될 수 있다. 공격자가 일부 입력을 조절하고 암호문 길이를 반복 관찰하면 비밀과의 중복 여부를 추론할 수 있다. CRIME·BREACH 계열의 구체적 HTTP 맥락은 챕터 9에 위임한다. 여기서는 "내용을 숨겨도 길이와 타이밍 같은 메타데이터까지 사라지지는 않는다"는 경계만 기억한다.
압축, 오류 정정, 암호는 중복을 다르게 다룬다
| 변환 | 중복에 하는 일 | 얻는 것 | 지불하는 비용 |
|---|---|---|---|
| 압축 | 예측 가능한 중복을 제거 | 더 적은 저장·전송량 | CPU, 지연, 길이 부채널 |
| 오류 정정 | 검증 가능한 중복을 추가 | 제한된 손상의 감지·복구 | 더 많은 비트 |
| 암호화 | 키 없이는 구조를 예측하기 어렵게 변환 | 기밀성 | 키·nonce 관리, 무결성은 별도 필요 |
| 인증 | 신원 또는 메시지와 키의 관계를 증명 | 상대·출처 판단 | 신뢰 저장소와 운영 제도 |
"랜덤해 보인다"는 표현도 목적에 따라 뜻이 다르다. 압축기에는 더 줄일 수 없는 입력이라는 뜻이고, 암호에서는 키 없는 관찰자가 평문의 패턴을 구분하기 어렵다는 뜻이다. 오류 정정기에는 오히려 허용 가능한 코드워드와 손상된 비트 사이의 구조가 필요하다.
이 챕터를 읽는 계약
각 프리미티브를 다음 세 문장으로 정리한다.
- 보장: 공격자나 오류 모델에 대해 무엇을 약속하는가.
- 가정: 키의 비밀성, nonce의 유일성, 난제의 계산 비용, 신뢰 저장소 중 무엇을 전제하는가.
- 오용: 어떤 입력·키·운영 선택이 보장을 무효화하는가.
본문의 toy 구현은 원리와 실패 모드를 관찰하기 위한 것이다. 프로덕션 암호를 직접 구현하거나 임의로 조합하지 않는다. 검증된 라이브러리의 고수준 API와 표준 프로토콜을 사용하되, 파라미터가 표현하는 계약은 직접 검토한다.
학습 경로와 산출물
엔트로피·부호화
│
├─ 허프만 압축기: 이론 하한과 실제 파일 크기 비교
▼
대칭 암호·해시·MAC ──▶ 키 분배·서명 ──▶ 인증서·TLS
│
└─ handshake 캡처 분석챕터 3 실습(exercises/ch-3/README.md)은 두 모델을 증거로 확인한다. Part A에서는 허프만 압축기를 구현하고 엔트로피, 평균 부호 길이, 헤더를 포함한 크기를 비교한다. Part B에서는 TLS handshake와 인증서 체인을 캡처해 AEAD·HKDF·키 교환·서명이 각각 어느 보장을 맡는지 설명한다.
읽기 전 점검
- 압축률이 낮을 때 알고리즘 탓과 입력 모델의 한계를 구분할 수 있는가?
- 암호화된 데이터의 한 비트가 바뀌면 수신자가 반드시 알아차린다고 확신하는가?
- JWT의 HMAC 서명과 공개키 서명에서 누가 검증할 수 있는지 설명할 수 있는가?
curl -k가 없애는 것이 암호화인지 신원 검증인지 구분할 수 있는가?
답이 모호하다면 정상이다. 이 챕터의 목적은 공식을 외우는 것이 아니라 익숙한 도구의 보장 경계를 정확한 모델로 바꾸는 데 있다.