하드웨어 가속에 기대지 않는 두 번째 AEAD입니다. AES-GCM과 실패 방식이 다른 선택지를 하나 더 둡니다.
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에서도 상수 시간으로 동작합니다.
표준 문서에 실린 테스트 벡터를 그대로 넣어 같은 값이 나오는지 확인합니다.
Poly1305 태그는 GCM 태그와 같은 역할을 합니다. 한 비트만 바꿔도 열리지 않습니다. 접두사가 알고리즘을 고정하므로 AES 형식과 ChaCha 형식을 섞어 열려는 시도는 형식 검사 단계에서 막힙니다.
막아야 할 입력을 실제로 넣고 거부되는지 확인합니다.
규격 원문을 먼저 실었습니다. 사례는 이 분야에서 실제로 보안이 뚫린 일을 다룬 자료입니다.
ChaCha20-Poly1305의 원문입니다. §2.8.2의 AEAD 벡터를 증명에서 재현합니다.
TLS가 이 알고리즘을 AES-GCM과 나란히 두는 이유를 설명합니다.
테이블 기반 AES 구현이 타이밍 공격에 약한 이유를 밝힌 원논문입니다.
다음 단계
가속이 없는 실행 환경에서 AES-GCM과 처리량을 실측해, 소비 시스템이 기본으로 쓸 알고리즘의 기준을 정합니다.