암호화된 VPN 패킷이 생각보다 적게 드는 이유

같은 게이트웨이에서 두 프로필을 측정한다, 하나는 암호화를 켜고 하나는 끈 상태이며, 암호화된 쪽이 더 느리지 않다. 때로는 더 빠르기까지 하는데, 그러면 보통 테스트가 제대로 수행되었는지를 두고 긴 논쟁이 벌어진다. 결과는 그럴 만하다, 패킷의 비용은 설정 파일에 적힌 암호 용어의 개수가 아니기 때문이다. 구현이 실행하는 연산의 집합이며, 가진 하드웨어 위에서, 선택한 버퍼 배치에 따라 결정된다.

증상: 느린 쪽은 암호화된 프로필이 아니다

과거의 테스트가 AEAD 암호를 „암호화 없음“ 모드와 비교한다고 하자, 그 모드는 여전히 패킷마다 별도의 인증 코드를 계산한다. 두 번째 프로필은 페이로드 내용을 숨기지만 패킷별 해시는 유지하며, 그 해시에 대한 가속이 없는 프로세서에서는 이겨야 했던 통합 구성보다 더 비쌀 수 있다.

설정의 레이블은 „암호화“라고 말하고, 대부분의 비교는 그 레이블만 본다. 패킷 경로는 다른 것을 말한다, 한 프로필은 CPU에 명령이 있는 결합 연산을 수행하고 다른 쪽은 명령이 없는 별도 연산을 수행한다. 설정 파일만 읽어서는 그 차이가 결코 드러나지 않는다, 두 항목 모두 한 줄처럼 보이기 때문이다. 결과를 설명하는 것은 협상된 모드와 그 뒤의 코드 경로뿐이다.

그것이 설명의 전부이며, 어느 프리미티브가 보편적으로 더 빠른지에 대한 주장은 필요하지 않다. 둘 다 빠를 수 있고 둘 다 느릴 수 있으며, 순서는 기계와 코드에 달려 있다.

레이블이 아니라 연산을 세라

AEAD 구성은 RFC 5116이 기술하듯 암호문과 태그를 함께 반환하는 단일 인터페이스를 구현에 제공한다. AES-GCM이 한 예로, 카운터 모드 암호화와 Galois 인증기를 결합한 것이다. 그 인터페이스가 무결성을 공짜로 만들어 주지는 않고, 결합을 잘 정의된 것으로 만들어, 구현이 두 요소를 하나의 단위로 최적화할 수 있게 한다.

Separate authentication path:
  payload -> independent HMAC -> framed packet

AEAD path:
  payload -> authenticated encryption with tag -> framed packet

이것은 처리 흐름의 스케치이며 설정 조언이 아니다. 첫 번째는 기밀성이 없지만 여전히 인증에 CPU를 쓴다, „암호화를 끈다“가 „암호 작업을 끈다“와 동의어가 아닌 이유가 바로 여기에 있다.

두 번째가 더 저렴할 수 있는 것은 프로세서가 양쪽 절반에 대한 명령을 제공하기 때문이다, AES 라운드와 Galois 필드가 쓰는 캐리 없는 곱셈이다. 라이브러리는 독립적인 버퍼도 병렬로 처리하므로, 그 명령들이 메모리를 기다리는 대신 계속 바쁘게 유지된다.

협상된 모드가 실제로 가능하게 하는 것

Community OpenVPN에서 AEAD 데이터 암호를 쓰면 auth 옵션이 더 이상 자체적인 별도 데이터 채널 HMAC을 제공하지 않는다. 암호화 옵션 참조 문서가 그 범위를 설명하며, 텍스트 파일에서 비슷해 보이는 두 설정이 패킷당 작업에서 달라질 수 있는 이유가 여기에 있다.

희망 목록이 아니라 협상된 모드를 읽으라. 허용된 암호 목록과 TLS 스위트 이름은 페이로드에서 어떤 연산이 도는지 알려 주지 않으며, 오래된 cipher 줄은 현재 연결이 고른 것을 기술하지 않을 수 있다.

openvpn --show-ciphers | head -20
sudo grep -E 'cipher|auth' /etc/openvpn/server.conf

첫 번째 명령은 바이너리가 지원하는 암호를 나열하며, 이는 기능 목록이지 협상된 결과가 아니다. 두 번째는 서버가 실제로 요구하는 것을 보여 준다. 최종 선택을 확인할 곳은 연결 로그다, 클라이언트는 서버가 허용하지만 아무도 의도하지 않은 무언가로 되돌아갈 수 있다.

실제로 돌리는 부하를 측정하라

암호 마이크로벤치마크는 프리미티브를 그 자체의 조건에서 측정한다. VPN 전송은 버퍼를 복사하고, 스레드나 인터럽트를 스케줄링하고, 정책을 검사하고, 네트워크를 건넌다. 이런 부분이 흔히 지배적이므로, 더 빠른 프리미티브가 항상 더 빠른 터널을 만들지는 않는다.

openssl speed -evp aes-256-gcm
openssl speed -evp sha1

그 두 명령은 앞에 있는 기계에서 프리미티브를 대략적으로 로컬 비교한 것이며, 스스로 마이크로벤치마크임을 인정한다. 터널의 처리량에 대해서는 아무것도 말하지 않으며, 그렇게 인용되어서는 안 된다.

그다음에는 중요한 부하를 측정하라, 나머지는 모두 고정하고, 같은 엔드포인트, 같은 패킷 크기, 같은 전송 방식, 같은 압축 정책으로 둔다. 프로필 변경이 전송 방식이나 처리 위치까지 바꿨다면, 결과는 암호가 아니라 그 묶음을 설명한다.

목표도 시야에 두어야 한다. 암호 용량이 남아도는 데이터 경로라도 애플리케이션이 왕복을 기다리기 때문에 지연에 묶일 수 있으며, 대량 용량의 이득은 수다스러운 프로토콜을 고치지 못한다. 지원되고 정책이 승인한 설정을 전체로 측정하고, „상자가 적으면 더 빨라야 한다“는 주장을 그것이 지닌 가설로 다루라. 유용한 질문은 암호화에 비용이 있느냐가 아니라, 그 비용이 정말 중요하게 여기는 측정에 나타나느냐이다.