카드뉴스
CRC 일치는 데이터 동일성의 보증이 아니다
송신측은 약속한 데이터 범위로 CRC를 계산해 함께 보내고, 수신측은 같은 조건으로 다시 계산한다. 두 결과가 다르면 전송 과정에서 오류가 생겼다는 뜻이다. 값이 같을 때의 정확한 표현은 “오류가 검출되지 않았다”이다. 비트 수가 한정된 나머지를 쓰기 때문에 서로 다른 데이터가 같은 CRC를 갖는 충돌 가능성은 남아 있다.
CRC는 오류를 찾아낼 뿐 잘못된 비트를 고치지 않는다. 의도적인 위변조를 판별하는 보안 기능도 아니다. 공격자가 데이터와 CRC를 함께 바꿀 수 있는 환경이라면 키를 사용하는 MAC이나 디지털 서명처럼 목적에 맞는 인증 수단이 필요하다.
CRC 규격은 파라미터 전체를 뜻한다
“CRC-16을 사용한다”는 말만으로는 같은 결과를 만들 수 없다. width와 generator polynomial, initial value, 입력·출력 bit reflection, final XOR, 입력 바이트 순서, 계산에 포함하는 필드를 모두 맞춰야 한다. 메시지마다 CRC 레지스터를 초기화하는지, 이전 블록의 계산을 이어가는지도 결과에 영향을 준다.
반사형 구현에서는 비트 처리 방향에 맞춰 polynomial을 뒤집힌 값으로 표시하기도 한다. 문서의 16진수 하나만 비교하지 말고 RefIn·RefOut과 처리 방향을 함께 읽어야 송신측과 수신측의 설정이 같은지 판단할 수 있다.
Polynomial은 프레임 길이와 함께 고른다
CRC는 일반 정수 나눗셈이 아니라 GF(2)에서 XOR와 shift를 반복하는 다항식 나눗셈이다. 최종 나머지의 폭이 CRC 비트 수가 된다. 같은 CRC-16이라도 어떤 generator polynomial을 쓰는지, 보호할 최대 프레임이 얼마나 긴지에 따라 검출 가능한 오류 패턴과 Hamming distance가 달라진다.
따라서 polynomial은 이름이 익숙하다는 이유만으로 고르지 않는다. 사용하는 프로토콜이 값을 정했다면 그 규격을 따르고, 직접 정해야 한다면 목표 프레임 길이와 예상하는 burst·random 오류 조건에서 검출 성능을 평가해야 한다.
Software와 Hardware 결과를 테스트 벡터로 맞춘다
Software CRC는 bitwise 또는 lookup table 방식으로 계산할 수 있고, MCU의 CRC peripheral을 이용할 수도 있다. 하드웨어마다 지원 폭과 polynomial, 입력 단위, bit·byte reversal, initial value, reset과 chaining 방식이 다르므로 사용 전 기능 범위를 확인한다.
검증은 알려진 입력과 기대값을 가진 test vector로 시작한다. 예를 들어 해당 규격이 제시한 `123456789`의 check value를 먼저 맞춘 뒤, 빈 데이터와 짧은 패킷, 분할 입력, 실제 프레임을 비교한다. 알고리즘 이름만 기록하지 말고 전체 파라미터와 계산 범위, 실제 입력 바이트열까지 남겨야 구현 차이를 찾기 쉽다.
