사용 방법
- 텍스트를 입력하거나 붙여넣습니다. 원시 바이트를 입력하려면 ‘입력 형식’을 ‘16진수’로 바꾸고, 파일 내용의 체크섬을 구하려면 파일을 엽니다.
- ZIP, gzip, PNG와 호환되는 체크섬을 구하려면 CRC-32를 그대로 두고, iSCSI, ext4, Btrfs 또는 Google Cloud Storage에서 사용하는 체크섬을 구하려면 ‘알고리즘’ 선택 상자에서 CRC-32C를 선택합니다.
- ‘출력 형식’에서 ‘16진수(소문자)’, ‘16진수(대문자)’, ‘10진수’, ‘Base64’ 중 하나를 고릅니다.
- 검증하려면 예상 체크섬을 ‘비교 대상’에 붙여넣습니다. 0x를 뺀 16진수, 10진수, Base64 모두 사용할 수 있습니다.
CRC32 체크섬이란
순환 중복 검사(CRC)는 입력을 하나의 긴 이진 다항식으로 보고, 고정된 생성 다항식으로 나눈 뒤 나머지를 취합니다. CRC-32에서 나머지는 32비트이며, 보통 16진수 8자리나 0부터 4,294,967,295까지의 부호 없는 정수로 표기합니다. 데이터가 조금이라도 바뀌면 거의 예외 없이 나머지도 바뀝니다.
CRC는 실제 케이블, 무선 통신, 디스크에서 생기는 오류를 잡도록 설계되었습니다. CRC-32는 길이 32비트 이하의 연속된 비트 오류(버스트 오류)를 모두 감지하며, 무작위 손상을 놓칠 확률은 약 43억 분의 1에 불과합니다. 계산도 매우 빨라서 ZIP, gzip, PNG, 이더넷 프레임에 내장되어 있습니다.
CRC-32와 CRC-32C
| CRC-32 | CRC-32C(Castagnoli) | |
|---|---|---|
| 다항식 | 0x04C11DB7, 반사형 0xEDB88320 | 0x1EDC6F41, 반사형 0x82F63B78 |
123456789의 검사 값 | cbf43926 | e3069283 |
| 사용처 | ZIP, gzip, PNG, 이더넷 | iSCSI, SCTP, ext4 메타데이터, Btrfs, Google Cloud Storage |
| 하드웨어 지원 | ARMv8 CRC32 명령어 | x86 SSE4.2 crc32 명령어, ARMv8 |
두 방식 모두 0xFFFFFFFF에서 시작해 각 바이트의 비트를 최하위 비트부터 처리하고 최종 값을 반전합니다. 다른 점은 다항식뿐이지만, 같은 데이터라도 서로 무관한 두 결과가 나옵니다. 대부분의 도구가 "CRC32"라고 부르는 것은 CRC-32이며, CRC-32/ISO-HDLC라는 이름으로 분류되어 있습니다. CRC-32C는 오류 검출 능력이 더 뛰어나서 나중에 스토리지와 네트워크 프로토콜에 채택되었습니다. Google Cloud Storage는 CRC-32C를, Amazon S3는 두 변형 중 하나를 4바이트 빅 엔디언 순서의 Base64로 보고하는데, 이것이 바로 Base64 출력에 표시되는 값입니다.
보안 검사가 아닌 체크섬
CRC는 우발적인 손상을 잡아낼 뿐 공격은 막지 못합니다. 선형 함수이므로 누구나 파일을 수정한 뒤 4바이트만 조정해 CRC-32를 그대로 유지할 수 있습니다. 따라서 CRC가 일치한다고 해서 의도적인 변조가 없었다는 증거가 되지는 않습니다. 다운로드한 파일을 확인하려면 신뢰할 수 있는 출처의 SHA-256 해시와 비교하고, 메시지를 보낸 사람을 증명하려면 HMAC을 사용하십시오.
32비트는 데이터를 식별하기에도 너무 짧습니다. 무작위 파일이 약 77,000개만 되어도 두 파일의 CRC-32가 같을 확률이 이미 50%에 이르므로, 고유 ID나 중복 제거 키로 사용하지 마십시오. 공격자가 관여하지 않는 상황이라면 MD5나 SHA-256이 훨씬 나은 지문이 됩니다.
코드에서 CRC32 계산하기
# Python: Python 3의 zlib.crc32는 부호 없는 값을 반환하므로
# "& 0xffffffff"는 Python 2에서만 필요
import zlib
format(zlib.crc32(b'123456789'), '08x') # 'cbf43926'
// Node.js 20.15+ 및 22.2+
require('zlib').crc32('123456789').toString(16).padStart(8, '0') // 'cbf43926'
// Go (import "hash/crc32")
crc32.ChecksumIEEE(data) // CRC-32
crc32.Checksum(data, crc32.MakeTable(crc32.Castagnoli)) // CRC-32C
// Java: java.util.zip.CRC32, Java 9부터는 java.util.zip.CRC32C도 제공
// PHP
sprintf('%08x', crc32('123456789')); // 'cbf43926'
hash('crc32b', '123456789'); // 'cbf43926', 같은 CRC-32
hash('crc32c', '123456789'); // 'e3069283'
hash('crc32', '123456789'); // '181989fc', 다른 CRC
PHP에서는 이름에 주의하십시오. crc32라는 해시 알고리즘은 ZIP 체크섬이 아니라 bzip2가 사용하는 CRC이며, 바이트 순서를 뒤집어 출력합니다. ZIP, gzip, 그리고 이 도구와 같은 값을 얻으려면 crc32b나 crc32() 함수를 사용하십시오. Unix cksum 명령은 파일 길이까지 섞어 넣는 또 다른 변형을 사용하므로, 그 값은 어느 쪽과도 일치하지 않습니다.
예시
| 입력 (UTF-8) | CRC-32 |
|---|---|
Hello, World! | ec4ac3d0 |
Base64.is | 915d7207 |
你好 | 50a2b841 |
자주 묻는 질문
"123456789"의 CRC32는 얼마입니까?
cbf43926(10진수로 3421780262), CRC-32C는 e3069283입니다. 직접 구현한 코드가 이 값을 반환한다면 이 도구와 같은 매개변수를 사용하는 것입니다.내 CRC32가 다른 도구의 결과와 다른 이유는 무엇입니까?
cksum은 모두 결과가 다름), 입력 바이트(줄 끝, 끝에 붙은 줄 바꿈 문자, 문자 인코딩), 숫자 형식(일부 언어는 부호 있는 32비트 정수를 반환하므로 큰 값이 음수가 됨), 그리고 바이트 순서입니다.ZIP이나 gzip 파일 안에서 CRC 바이트가 뒤집혀 있는 이유는 무엇입니까?
unzip -v를 비롯한 대부분의 프로그램은 최상위 바이트를 먼저 출력합니다.큰 파일의 CRC32도 계산할 수 있습니까?
예. ‘파일 열기’를 클릭하면 파일을 업로드하지 않고 사용자의 기기에서 파일의 바이트로 체크섬을 계산합니다. 브라우저가 메모리에 담을 수 있는 파일이라면 무엇이든 가능합니다. 그런 다음 결과를 SFV 파일이나 ZIP 목록의 값과 비교할 수 있습니다.
CRC32는 해시 함수입니까?
임의 길이의 데이터를 고정된 32비트 값으로 대응시키기 때문에 해시와 함께 소개되는 경우가 많지만, CRC32는 체크섬입니다. 우발적인 오류는 감지하지만, 누군가 의도적으로 데이터를 바꾸는 것은 전혀 막지 못합니다. 더 강력한 지문이 필요하다면 결과 아래의 ‘모든 알고리즘’ 표에서 같은 입력의 MD5와 SHA 계열 해시를 확인하십시오.