# 암호문 확장 (Ciphertext Expansion)

암호문 확장은 암호화한 결과(암호문)가 원래 평문보다 길어지는 현상으로, 초기화 벡터·논스, 패딩, 인증 태그 같은 추가 데이터 때문에 생깁니다.

## 자세히 알아보기

안전한 암호화는 같은 평문을 같은 키로 두 번 암호화해도 다른 결과가 나와야 합니다. 그렇지 않으면 공격자가 "같은 메시지가 다시 왔다"는 사실을 알아채거나, 자주 나오는 블록을 사전처럼 모아 두는 코드북 공격을 할 수 있습니다. 이를 막으려면 매번 달라지는 값(초기화 벡터 IV 또는 논스)을 섞어야 하고, 복호화하는 쪽도 그 값을 알아야 하므로 암호문에 함께 붙여 보냅니다. 이것이 확장의 가장 흔한 원인입니다.

그 밖의 원인은 다음과 같습니다.

- **패딩**: CBC 같은 블록 암호 모드는 평문을 블록 크기(AES는 16바이트)의 배수로 맞추기 위해 1~16바이트를 덧붙입니다. CTR·GCM 같은 스트림 방식 모드는 패딩이 필요 없습니다.
- **인증 태그**: 현대 권장 방식인 인증 암호(AEAD)는 위변조 검출용 태그를 붙입니다. AES-GCM은 보통 12바이트 논스와 16바이트 태그를 써서 메시지마다 약 28바이트가 늘어납니다. ChaCha20-Poly1305도 태그가 16바이트입니다.
- **공개 키 암호**: RSA나 ECIES는 짧은 메시지도 키 크기 단위의 블록이나 임시 공개 키를 포함하므로 상대적으로 확장이 큽니다.

확장을 아예 없애는 방법도 있습니다. 디스크 섹터처럼 길이를 바꿀 수 없는 경우에는 섹터 번호를 트윅으로 쓰는 XTS 모드처럼 길이 보존 암호화를 씁니다. 다만 이런 방식은 위변조 검출이 없고 같은 위치에 같은 데이터를 쓰면 같은 암호문이 나오는 한계를 감수합니다. 일반 통신에서는 몇십 바이트의 확장보다 무결성과 기밀성이 훨씬 중요하므로, AEAD를 쓰는 것이 기본입니다.

## 블록체인·암호화폐에서는

이더리움의 키스토어 파일(v3)은 개인 키를 AES-128-CTR로 암호화하고 IV와 MAC 값을 따로 저장합니다. 노드 간 통신 프로토콜이나 지갑 백업 암호화에서도 IV·태그만큼의 확장이 생깁니다.

### 확장 크기 계산 예

평문 100바이트를 암호화한다고 가정해 보겠습니다.

- AES-CBC + PKCS#7 패딩: 패딩 12바이트로 112바이트, 여기에 IV 16바이트를 더해 128바이트가 됩니다. 무결성 확인을 위해 HMAC을 따로 붙이면 더 늘어납니다.
- AES-GCM: 암호문 100바이트 + 논스 12바이트 + 태그 16바이트 = 128바이트입니다.
- AES-CTR(인증 없음): 100바이트 + 논스 16바이트 = 116바이트로 가장 작지만, 위변조를 감지할 수 없어 단독으로 쓰면 안 됩니다.

이처럼 확장의 크기는 모드 선택에 따라 달라지며, 몇십 바이트를 아끼려고 인증을 빼는 것은 바람직하지 않습니다.

## 쉽게 말하면

편지를 금고 상자에 넣어 보내면 상자와 봉인 스티커 무게만큼 소포가 무거워지는 것과 같습니다.

---
출처: https://achivx.kr/glossary/ciphertext-expansion-%EC%95%94%ED%98%B8%EB%AC%B8-%ED%8C%BD%EC%B0%BD/ · ACHIVX 용어 사전 · 수정일 2026-10-20