AES-GCM과 ChaCha20-Poly1305: VPN 데이터 암호 선택하기

두 이름 모두 AEAD 구성입니다. 둘 다 표준화되었고, 현재의 x86 서버에서는 어느 쪽이든 눈에 띄는 수고 없이 기가비트 회선을 채웁니다. 선택이 임의적이지 않게 되는 것은 그 서버를 떠날 때입니다. 값싼 공유기, 오래된 휴대폰, 가상 어플라이언스에는 AES 가속이 없는 경우가 많고 거기서 차이가 큽니다. 그래서 비교는 어느 암호가 더 빠른가가 아니라, 이 끝점 집합에서 어느 암호가 잘 돌아가며 프로토콜이 애초에 선택지를 주는가입니다.

같은 일, 다른 코어

두 구성 모두 한 번에 기밀성과 무결성을 제공하고 연관 데이터를 인증하므로 VPN 프로토콜이 데이터 채널에 이것들을 씁니다. 차이는 안쪽에 있습니다. AES-GCM은 카운터 모드의 AES 블록 암호에 GF(2^128) 위의 다항식 인증기를 붙인 것이고, ChaCha20-Poly1305는 256비트 키의 스트림 암호에 별도의 일회용 인증기를 붙인 것입니다.

운영상 중요한 점은 공통입니다. 둘 다 nonce 재사용에서 치명적으로 무너지고, 둘 다 키마다 nonce 공간을 관리해야 하며, 둘 다 잘못된 것을 인증하는 상대를 고쳐 주지 않습니다. AES-256-GCM라고 적힌 프로필이 CHACHA20-POLY1305라고 적힌 것보다 안전한 것이 아니며, 구현이 올바르면 둘 다 강합니다.

AES-GCM이 이기는 곳

AES는 대부분의 현대 CPU에 전용 명령이 있습니다. x86의 AES-NI, ARMv8의 암호 확장, 최근 POWER와 RISC-V 설계의 동등한 기능입니다. 이것이 있으면 GCM은 사이클당 여러 블록을 병렬로 처리하고 소프트웨어 구현은 무의미해집니다. 서버, 데스크톱, 현재의 휴대폰에서 흔한 경우이며, 데이터센터에서 AES를 쓰라는 조언이 합리적인 기본값인 이유입니다.

문제는 두 번째 경우입니다. 전용 명령이 없으면 소프트웨어 AES는 느리고, 테이블 기반 소프트웨어 구현은 캐시 타이밍 문제의 긴 역사를 가진 것들입니다. 호스트가 게스트에게 AES 플래그를 노출하지 않는 가상 머신에서 도는 VPN 집선 장치가 바로 이 경우이며, 호스트 CPU에는 기능이 있어서 놓치기 쉽습니다.

CPU가 무엇을 지원하는지가 아니라 프로세스가 실제로 무엇을 보는지 확인하십시오. Linux에서는 grep -o aes /proc/cpuinfo | head -1, 또는 하이퍼바이저의 CPU 모델에서 동등한 기능 플래그입니다.

ChaCha20-Poly1305가 이기는 곳

ChaCha20은 이식성 있는 소프트웨어에서 빠릅니다. 덧셈, 회전, XOR만 쓰고, 구현이 설계상 비밀에 의존하는 테이블 조회를 피하기 때문입니다. AES 가속이 없는 기기에서는 실질적인 이점이고, WireGuard가 이것을 고른 이유이기도 합니다. WireGuard 프로토콜 설명은 ChaCha20-Poly1305를 대안 없는 데이터 암호로 적고 있습니다.

그 하나의 선택은 유용한 것을 말해 줍니다. AES가 가속되는 하드웨어에서 WireGuard는 AES-GCM에 비해 처리량을 조금 포기하며, 저자들은 휴대폰, 가정용 공유기, 컨테이너 호스트에서 예측 가능한 동작을 얻는 대가로 그것을 받아들였습니다. 당신의 무리가 주로 작은 ARM 상자라면 그 교환은 당신에게 유리합니다.

반대 경우는 바쁜 x86 집선 장치입니다. 거기서는 AES-NI가 있는 AES-GCM이 더 빠르고 더 잘 지원되는 길이며, ChaCha20은 기가비트마다 측정 가능한 CPU를 씁니다. 어느 구성도 약점이 아닙니다. 문제는 당신의 하드웨어가 어느 쪽을 싸게 실행하는가입니다.

프로토콜이 실제로 선택하게 해 주는 것

OpenVPN의 분할을 보십시오. 제어 채널과 데이터 채널은 따로 협상됩니다. 그래서 TLS에서 보는 스위트는 당신의 페이로드를 보호하는 암호에 대해 아무것도 말하지 않습니다. 세션 요약은 둘 다 보고하며, 둘 중 하나만 읽는 것은 흔한 혼란의 원인입니다.

OpenVPN에서 데이터 채널의 암호는 양쪽 끝의 data-ciphers 목록에서 옵니다. 서버 목록과 클라이언트 목록이 교집합을 이루지 못하면 연결은 data-ciphers-fallback가 허용하는 것으로 후퇴하거나 완전히 실패하며, 그 실패는 보통 잘못된 계층의 탓으로 돌려집니다. 양쪽에 같은 목록을 두고, 목록 순서가 지켜졌다고 가정하는 대신 협상된 결과를 로그에서 확인하십시오.

배포에 관한 세 가지 사실로 결정하기

첫째, 끝점에 AES 가속이 있는가. 모든 상대에 있다면 AES-GCM이 더 싼 선택이고 유지되는 대부분의 구성에서 기본값입니다. 상당 부분이 작은 공유기나 오래된 휴대폰이라면 ChaCha20-Poly1305가 무리의 꼬리가 용량 한계가 되지 않게 합니다.

둘째, 프로토콜이 애초에 선택지를 주는가. WireGuard에서는 결정이 이미 당신 대신 내려졌고, 유용한 일은 그 주변 도구가 조용히 다른 것을 끼워 넣지 않는지 확인하는 것입니다. OpenVPN과 IPsec에서는 답이 설정 한 줄과 기록해야 할 협상 결과입니다.

셋째, 양쪽 끝이 합의할 수 있는가. 한 상대가 구현하지 않는 암호는 성능 결정이 아니라 장애입니다. 그래서 상대 목록이 어떤 벤치마크보다 중요합니다. 혼합된 무리에는 능력의 교집합이 필요하고, 가장 빠른 기계의 선호가 아닙니다.

측정한다면 기기, 끝점, 부하를 같게 두고 한 가지만 바꾸십시오. 다른 지역의 두 서버를 비교하는 시험은 경로를 재는 것이지 암호를 재는 것이 아니며, 노트북 벤치마크는 CPU 플래그가 가려진 컨테이너 호스트에 대해 아무것도 말해 주지 않습니다. 비교하고 나서 실제로 어떤 암호가 협상되었는지 적어 두십시오. 그 기록이 벤치마크보다 값집니다.