더 긴 Blowfish 키가 64비트 블록을 고칠 수 없는 이유

어떤 VPN 프로필은 448비트 키의 Blowfish를 제공하며, 누군가는 암호를 유지하기 위해 가장 긴 키를 쓰자고 제안합니다. 키 길이는 사실이지만 최적화할 숫자는 그것이 아닙니다. Blowfish는 키가 아무리 길어도 64비트 블록을 변환하며, 키 하나가 안전하게 보호할 수 있는 트래픽 양을 제한하는 것은 블록 폭입니다. 뒤 단계가 앞 단계를 고칠 수는 없으므로, 아래 점검을 순서대로 수행하고 서비스의 혐의를 벗겨 주는 첫 점검에서 멈추세요.

상대가 실제로 무엇을 협상하는지 확인하세요

데이터 채널의 암호를 배포하려던 프로필이 아니라 양쪽 끝에서 읽으세요. 클라이언트 설정은 여러 암호를 나열할 수 있고, 선택되는 것은 두 구현과 그 버전 사이의 협상 결과입니다. 테스트 연결에서 로그 상세 수준을 높이고, 실제로 초기화된 암호와 키 크기를 밝히는 데이터 채널 줄을 읽으세요.

협상된 암호가 AES-GCM 또는 ChaCha20-Poly1305라면 여기서 멈추세요. 그 구성은 128비트 블록을 사용하고 페이로드를 인증하므로, 아래의 64비트 충돌 논리는 해당되지 않습니다.

키 길이와 블록 폭을 분리하세요

Blowfish는 32에서 448비트까지의 키를 받아들이고, 알고리즘 저자의 문서는 두 숫자를 따로 제시합니다. 키는 비밀이고 블록은 변환의 단위입니다. 비밀을 길게 하면 추측은 어려워지지만 암호가 처리하는 블록 폭에는 아무 영향이 없습니다.

CBC 모드에서 암호는 고정 폭 블록에 적용되고, 이전 암호문 블록과 연결되며 끝에서 패딩됩니다. Blowfish에서 그 폭은 64비트, 즉 여덟 바이트입니다. 키 스케줄은 아무리 커도 되지만 체인은 한 번에 여덟 바이트씩 나아갑니다.

그래서 키를 길게 하는 것은 완화책이 아닙니다. 그것은 키에 대한 무차별 대입을 다루는 것이고, 아래의 충돌 위험은 블록 폭과 모드의 성질입니다.

생일 산술을 블록 크기에 적용하세요

64비트 블록의 생일 기준은 하나의 키로 암호화되는 약 2^32 블록에서 충돌이 현실화됩니다. 각 블록은 여덟 바이트를 나르므로 같은 기준은 약 2^35바이트, 즉 키 하나당 32 GiB의 데이터입니다.

이것을 할당량이 아니라 기준으로 보세요. 충돌은 확률적이며, 무언가가 유출되는지는 모드, 트래픽 형태, 그리고 공격자가 주변 평문을 인식하거나 영향을 줄 수 있는지에 달려 있습니다. 32 GiB를 넘은 첫 바이트가 복호화 사건은 아니고, 처음 32 GiB도 안전하다고 인증된 것이 아닙니다.

Sweet32 연구자들은 2016년에 관찰과 트래픽 생성이 필요한 조건에서 OpenVPN 시나리오를 포함한 64비트 블록 암호에 대한 실용적 공격을 시연했습니다. 그들이 공개한 기본값과 소프트웨어 버전은 역사적 배경이며, 당신의 배포에 대한 설명이 아닙니다.

CBC 재사용이 여기서 중요한지 판단하세요

CBC에서 암호문 블록이 반복된다는 것은 체인 XOR이 상쇄되므로 두 평문 블록이 알려진 관계로 다르다는 뜻입니다. 암호문을 관찰할 수 있고 평문 중 하나를 알거나 영향을 줄 수 있는 공격자는 다른 하나에 대한 정보를 복구할 수 있습니다. 이를 위해 Blowfish 키는 결코 필요하지 않습니다.

따라서 관련 질문은 키가 얼마나 오래 서비스되는지, 그 아래로 얼마나 많은 트래픽이 지나가는지, 누군가 그 트래픽을 관찰하고 유도할 수 있는지입니다. 키 갱신은 키당 블록 수를 줄이지만 시간 간격은 바이트 한도가 아니므로, 같은 한 시간에 바쁜 터널은 유휴 터널보다 훨씬 많은 데이터를 옮길 수 있습니다. 오래된 암호를 유지한다면 한도는 구조와 실제 양에서 도출하고, 깔끔한 숫자에서 가져오지 마세요.

키당 측정된 양이 생일 기준보다 훨씬 낮다면 노출은 더 작습니다. 그래도 영은 아니며, 걱정을 그만두는 대신 이전을 계획할 이유가 됩니다.

키가 아니라 암호를 교체하세요

서비스를 지원되는 AEAD 암호로 옮기고, 양쪽 피어와 그 버전, 그리고 각자의 암호 백엔드가 그것을 협상할 수 있는지 확인하세요. 더 긴 Blowfish 키는 중요한 무엇도 바꾸지 않으며, 한 클라이언트에서 새 지시문을 추측하는 것이 작동하는 터널을 망가뜨리는 방법입니다. 나머지 함대를 건드리기 전에 클라이언트 하나와 서버 하나에서 변경을 시험하세요. 새 암호가 전체 연결 주기를 통과할 때까지 이전 프로필을 롤백용으로 남겨 두세요.

변경하는 동안 인증서 검증과 계정 인증을 유지하세요. 이것들은 다른 질문에 답합니다: 성공한 로그인은 블록을 넓힐 수 없고, 더 나은 데이터 암호가 잘못된 서버를 신뢰할 이유가 되지는 않습니다.

새 연결에서 협상된 암호를 다시 읽고 이전 암호가 더 이상 받아들여지지 않는지 확인하여 점검을 마치세요. 상대가 여전히 그것을 제공한다면, 반대편 프로필이 무엇이라 하든 이전은 끝나지 않았습니다.