암호화 · 키 관리
하드웨어 가속에 기대지 않는 두 번째 AEAD로 실패 방식이 다른 선택지를 갖습니다.
규격 재현과 공격 거부를 이 페이지에서 직접 실행해 확인할 수 있습니다.
ChaCha20-Poly1305은 AES-GCM과 같은 보장을 제공하는 인증 암호화이지만 내부 구조가 다릅니다. 덧셈·XOR·회전만 사용해 룩업 테이블이 없으므로 하드웨어 가속이 없는 환경에서도 상수 시간으로 동작합니다. 두 알고리즘은 성능이 아니라 실패 방식이 다르며, 그래서 TLS는 둘을 나란히 표준으로 둡니다.
메모리 룩업 없이 산술 연산만 사용해 캐시 타이밍으로 키가 새는 경로를 없앱니다.
envelope 접두사에 알고리즘을 기록해 두 형식이 섞이거나 잘못된 키로 열리지 않게 합니다.
Poly1305도 키당 nonce 재사용에 무너지므로 nonce를 호출자가 정하지 못하게 합니다.
AES-NI가 있는 서버 CPU에서 AES-GCM은 압도적으로 빠릅니다. 문제는 가속이 없는 곳입니다. 소프트웨어 AES는 보통 룩업 테이블을 쓰는데, 테이블 접근 패턴이 캐시에 흔적을 남겨 키를 복원당할 수 있습니다(Bernstein, 2005). ChaCha20은 테이블이 없어 이 경로 자체가 존재하지 않습니다. 모바일·임베디드·오래된 서버가 대상이라면 ChaCha20-Poly1305가 더 안전하면서 더 빠른 경우가 많습니다.
둘 다 AEAD이고 12바이트 nonce, 16바이트 인증 태그, AAD 결속을 제공합니다. 계약이 같으므로 이 모듈의 envelope 구조도 aead.v1과 동일한 규율을 따릅니다. 다른 것은 내부 구조와 nonce 재사용 시의 붕괴 방식뿐이며, 재사용이 치명적이라는 사실 자체는 양쪽 모두 같습니다.
아래 증명은 설명이 아니라 실제 실행입니다. 버튼을 누르면 이 서버에서 지금 계산합니다.
AES-GCM과 같은 보장을 다른 내부 구조로 제공한다 — 규격이 인쇄한 키·nonce·AAD·평문을 넣으면 인쇄된 114바이트 암호문과 태그가 바이트 단위로 나온다. 룩업 테이블이 없어 가속 없는 CPU에서도 상수 시간으로 돈다.
표준이 고정한 test vector 를 그대로 실행합니다.
Poly1305 태그는 GCM 태그와 같은 일을 한다 — 한 비트만 손대도 열리지 않는다. 그리고 접두사가 알고리즘을 못박으므로 AES 형식과 ChaCha 형식을 섞어 열려는 시도는 형식 단계에서 끊긴다.
막아야 할 입력을 실제로 넣고 거부되는지 확인합니다.
규격 원문을 우선합니다. 사례는 이 주제가 실제로 어떻게 뚫렸는지를 다룬 자료입니다.
원문. §2.8.2의 AEAD 벡터를 증명에서 재현한다.
TLS가 AES-GCM과 나란히 두는 이유.
테이블 기반 AES 구현이 왜 타이밍에 취약한지의 원논문.
Next step
가속 없는 실행 환경에서 AES-GCM과 처리량을 실측해 소비 시스템의 기본 알고리즘 기준을 정합니다.