CFB1·CFB8·CFB128의 차이는 키 길이가 아니라 피드백 크기

AES-256-CFB1 같은 이름에는 숫자가 두 개 있고, 그 둘은 서로 다른 질문에 답합니다. 256은 AES 키 길이입니다. 1은 CFB 피드백, 즉 세그먼트 크기로, 모드가 자기 상태를 어떻게 진행시키는지를 나타내는 속성입니다. 1을 키 길이로 읽으면 그 이름은 치명적인 잘못된 설정처럼 보입니다. 그래서 이 질문이 계속 되돌아옵니다.

이름을 판단하기 전에 키 크기, 블록 크기, 세그먼트 크기 중 무엇을 보고 있는지 먼저 정하십시오. 통상적인 의미의 보안 매개변수는 첫 번째뿐입니다.

세 개의 숫자, 세 가지 양

AES는 128, 192, 256비트 키를 받아들이고, 어느 것을 고르든 128비트 블록을 씁니다. 블록 크기는 모드가 아니라 AES에 속합니다. CFB 접미사는 세 번째 양으로, 모드가 한 단계마다 소비하고 되먹이는 데이터의 양입니다. OpenSSL AES 문서는 CFB 변형들에 대해 그 시프트 크기를 명시적으로 나열합니다.

CFB1은 한 번에 한 비트, CFB8은 한 바이트, CFB128은 블록 전체를 되먹입니다. 셋 모두 내부적으로 같은 128비트 블록 암호를 쓰며, 달라지는 것은 연산마다 계산된 블록에서 몇 비트를 쓰는가입니다. 그래서 접미사는 키 강도가 아니라 비용과 버퍼링 동작을 바꿉니다.

블록 크기가 절대 바뀌지 않는 이유

AES는 고정된 128비트 블록을 가진 블록 암호이고, 모드는 그 둘레에 세워진 구성입니다. 어느 것도 세그먼트 크기에 맞추어 블록을 줄이지 않습니다. CFB1 구현도 여전히 AES 블록 전체를 계산하고 결과에서 한 비트만 취합니다. 나머지 비트는 그 단계에서 버려지며, 효율 비용은 바로 여기에 있습니다.

따라서 한 비트 피드백이 한 비트 키를 뜻하지 않고, 이름을 접미사로 줄 세울 수도 없습니다. CFB128이 CFB32보다 네 배 강한 것이 아니라, 더 큰 세그먼트를 처리할 뿐입니다.

세그먼트 크기가 실제로 바꾸는 것

세그먼트 크기는 한 단계마다 되먹이는 암호문의 양과 각 단계가 나를 수 있는 평문의 양을 바꿉니다. 오류 전파와 버퍼링 동작도 바꾸며, 이는 스트림 같은 사용에서 중요합니다. 바이트 지향 세그먼트는 버퍼와 맞아떨어지고, 비트 지향 세그먼트는 그렇지 않습니다.

실제로 모드를 고르는 것은 프로토콜이지 운영자가 아닙니다. VPN 데이터 채널은 자기 프로토콜이 규정한 구성을 쓰며 자체 무결성 보호를 갖습니다. 라이브러리 목록은 어떤 이름이 존재하는지만 알려 줍니다.

한정어 없는 CFB 표기를 읽는 법

한정어 없는 CFB 표기에는 구현 맥락이 필요합니다. OpenSSL 1.0.2 헤더에서 EVP_aes_128_cfb는 EVP_aes_128_cfb128의 매크로이며, 192와 256비트 키에 대해서도 대응하는 별칭이 있습니다. 그것은 한 브랜치의 API 이름 규칙일 뿐, 모든 라이브러리나 파일 형식, GUI가 그 약어를 같은 방식으로 확장한다는 주장이 아닙니다. 눈앞에 있는 버전의 헤더나 문서를 확인하십시오.

레거시 프로필이 CFB라고 하고 상대가 받아들인다면, 협상된 매개변수는 어딘가에 기록됩니다. 로그, 설정 덤프, API 응답입니다. 표시 문자열에서 세그먼트 크기를 추론하지 말고 그것들을 읽으십시오.

모드 이름이 알려주지 않는 것

그 이름은 암호화 동작만 설명하고 다른 것은 아무것도 설명하지 않습니다. VPN에는 여전히 무결성 보호, 키 유도, 상대 인증이 필요하고 CFB는 그중 어느 것도 제공하지 않습니다. CFB8을 CFB1로 바꾸는 것도 겉모습의 변화가 아닙니다. 회선상 동작이 달라지고 양쪽이 같은 구성을 지원해야 합니다. 라이브러리에 이름이 있다고 해서 배포된 게이트웨이가 자기 데이터 채널에 그것을 받아들인다는 증명도 아닙니다.

유지 관리되는 무엇이든 프로토콜의 완전한 보호 구성과 운영자의 정책을 따르고, 라이브러리와 게이트웨이 버전, 정확한 옵션, 협상 결과를 기록하십시오. 오래된 이름은 지금 읽고 있는 것을 설명해 줄 뿐, 그 구성을 되살릴 근거가 되지 않습니다.