키 숫자가 크다고 VPN이 더 안전해지지 않는 이유

광고는 256비트라고 말하고, 다른 제품은 128비트라고 말한다. 숫자가 서로 다른 것을 설명한다는 점을 알아차리기 전까지 결론은 뻔해 보인다. 대칭 암호 키, 인증서의 공개 키, 키 교환 매개변수는 같은 척도로 재어지지 않는다. 어느 것도 클라이언트가 서버를 검증했는지 여부를 다루지 않는다. 숫자는 실제 정보이지만, 그 주변의 마케팅이 암시하는 것보다 훨씬 좁은 범위의 정보다.

무엇이든 비교하기 전에 어떤 키를 세는지, 그 키가 무엇을 보호하는지 물어야 한다.

세 가지 역할을 맡은 세 개의 키

데이터 암호는 터널의 페이로드를 암호화하며, 그 키는 세션마다 새로 유도된다. 인증서의 공개 키는 인증 과정에서 한쪽 끝점의 신원을 증명한다. 키 교환 단계는 보통 일시적인 Diffie-Hellman 변형으로, 이후 어느 쪽도 재구성할 수 없는 공유 비밀을 세운다. 각각은 고유한 강도 가정과 고유한 크기 관례를 지닌다.

그래서 256을 2048 옆에, 그 옆에 32를 두고 크기로 줄 세울 수는 없다. 그것들은 서로 다른 질문에 대한 답이다.

하나의 역할 안에서도 숫자는 사용 중인 알고리즘 계열에 상대적으로만 무언가를 말한다.

숫자가 도움이 되는 곳과 멈추는 곳

한 알고리즘 안에서는 키가 클수록 무차별 대입 탐색 비용이 올라가고, 공개된 지침은 계산 능력의 변화에 따라 인증서 키의 최솟값을 정한다. 그것은 정당하지만 좁은 비교다. AES-128과 AES-256은 모두 넓은 여유를 두고 직접 공격을 견디므로, 실무에서 그 차이가 결정적 요인이 되는 일은 드물다.

그 비교 밖에서 숫자는 구성 오류, 인증서 검증, 프로토콜 버전에 관해 아무것도 예측하지 못한다.

협상된 스위트 전체를 읽어라

연결이 실제로 사용하는 것은 스위트다. 암호 모드, 무결성 또는 인증 암호화 구성, 키 교환 그룹, 인증 방식의 조합이다. 적절한 핸드셰이크를 갖춘 현대적 AEAD 모드는 표면의 키 크기가 같더라도 별도의 MAC과 짝지은 옛 모드와는 다른 제안이다.

openvpn --show-ciphers | head -20
openvpn --show-tls | head -20
openssl x509 -in server.crt -noout -text | grep -E 'Public-Key|Signature Algorithm'
wg show

설정된 최댓값이 아니라 협상된 결과를 읽어야 한다. 강한 스위트를 제시하는 클라이언트라도 서버가 더 약한 옵션을 고르고 프로필이 그것을 허용하면 약하게 접속한다. 성능이 걱정이라면 문제의 기기와 경로에서 측정하라. 하드웨어 가속과 패킷 크기가 개입하면 키 크기는 처리량의 형편없는 예측 변수다.

숫자가 결코 재지 않는 부분

소프트웨어 유지보수가 첫 번째 누락이다. 수정을 받지 않게 된 라이브러리 위에 세운 터널은 키 크기가 시사하는 것보다 약하며, 어떤 구성 값도 그것을 고치지 못한다. 운영자의 행동이 두 번째다. 연결 기록, 계정 데이터, 지원 대응은 암호학의 완전히 바깥에 있다. 예상보다 많이 보관하는 서비스는 더 긴 키로 더 안전해지지 않는다.

상대 검증은 세 번째이자 가장 중대하다. 어떤 인증서든 받아들이는 클라이언트는 인증되지 않은 상대를 강한 암호로 감싼 것일 뿐이며, 올바르게 검증하는 소박한 암호보다 나쁘다. 숫자보다 먼저 이 세 가지를 확인하면 숫자는 제자리를 찾는다.