ChaCha20-Poly1305 암호 (RFC 8439)

카운터 0이 Poly1305 키를 만드는 데 쓰이기 때문입니다. 이 AEAD는 카운터 0으로 ChaCha20 블록 함수를 한 번 호출해 그 블록의 앞 32바이트를 일회용 인증 키로 삼고, 평문은 카운터 1부터 시작하는 스트림으로 암호화합니다. 데이터를 0에서 시작하는 구현은 자기끼리는 맞지만 그 무엇과도 호환되지 않습니다.

같은 키·논스로 메시지 둘을 보내면 공격자는 평문들의 XOR을 얻고, 그것만으로 충분한 경우가 많습니다. 더 나쁜 것은 두 메시지가 같은 일회용 Poly1305 키를 공유한다는 점입니다. 그 키 하나로 유효한 태그 둘을 보면 키를 복구할 수 있고, 그 뒤엔 원하는 메시지의 태그를 위조할 수 있습니다. 성능 저하가 아니라 파괴이고, 그래서 툴이 경고합니다.

길이가 없으면 추가 데이터와 암호문의 경계가 모호해지고, 공격자가 태그를 유효하게 유지한 채 바이트를 한쪽에서 다른 쪽으로 옮길 수 있습니다. 이 구성은 두 부분을 각각 16의 배수로 패딩한 뒤 AAD 길이와 암호문 길이를 64비트 리틀엔디언 정수로 덧붙이는데, 정확히 그 경계를 못 박기 위한 것입니다.

둘 다 16바이트 태그와 12바이트 논스를 쓰는 AEAD이고, 둘 다 논스 재사용에 치명적으로 무너집니다. AES-GCM은 AES 명령이 있는 곳에서 더 빠르고 없는 곳에서는 더 느리며 부채널에 더 취약합니다. ChaCha20-Poly1305은 소프트웨어에서 고르게 빠르고 테이블 조회가 없습니다. GCM은 태그를 잘라 쓰면 안전성이 떨어지지만 Poly1305는 태그 길이가 하나뿐입니다. 새 프로토콜이라면 둘 다 변호할 수 있고, 모바일·임베디드에서는 보통 ChaCha20-Poly1305가 이깁니다.

산술은 RFC 8439의 모든 테스트 벡터와 별도 구현으로 검증했지만, 그것은 배포해도 안전하다는 뜻이 아닙니다. 브라우저 탭 안 자바스크립트에서 돌고, 상수 시간 보장이 없으며, 키는 텍스트 필드와 이 페이지의 로컬 스토리지에 들어 있습니다. 구현을 확인하거나 구성을 이해하는 데 쓰고, 중요한 것에는 검토된 라이브러리를 쓰세요.