“blue”를 “Blue”로 바꾸면 전혀 관련 없어 보이는 새 숫자열이 나타난다.
문장은 거의 달라지지 않았지만 파일의 지문은 크게 바뀐다. 암호학적 해시의 매력은 여기에 있다. 모든 바이트를 직접 들여다보는 대신 작은 결과값을 비교할 수 있다. 다만 이 비교에는 조용한 전제가 숨어 있다. 비교 기준으로 삼는 지문을 믿을 이유가 있어야 한다.
체크섬은 일치를 확인할 수 있다. 보낸 사람을 소개해 주지는 못한다.
파일 지문이란 무엇인가
SHA-256은 바이트를 받아 256비트 다이제스트를 만든다. 보통 64개의 16진수 문자로 표시한다. 같은 바이트는 같은 결과를 낸다. 파일 이름은 내용에 포함되지 않으므로 이름만 바꾸면 내용 해시는 달라지지 않는다. 실제 저장된 바이트를 바꾸면 눈에 보이지 않는 변화라도 보통 해시가 달라진다.
다이제스트는 다시 펼쳐 원래 파일로 복구할 수 있는 압축본이 아니다. 가능한 입력은 유한한 출력 공간보다 많으므로 이론적으로 충돌, 즉 서로 다른 입력이 같은 결과를 내는 경우는 존재한다. SHA-256은 그런 충돌을 찾는 일이 계산상 실행 불가능하도록 설계됐다. 일치는 내용이 같다는 강한 실용적 근거이지, 모든 가능한 입력이 일대일 대응한다는 수학적 증명은 아니다.
주전자 하나, 대문자 하나, 약간의 공백
무해한 문장 “The kettle is blue.” 뒤에 줄바꿈 LF를 붙여 저장했다. 파일 크기는 20바이트다. 이어 b를 B로 바꾼 것, 줄바꿈 앞에 공백 하나를 넣은 것, 줄 끝을 CRLF로 바꾼 것, 마지막 줄바꿈을 없앤 것까지 네 가지 변형을 만들었다. 각 파일은 실제로 디스크에 쓰고 다시 읽었다.
수정된 네 파일은 모두 서로 다른 SHA-256 다이제스트를 냈다. 소문자에서 대문자로 바꾸면 입력에서는 실제로 단 한 비트만 뒤집히지만 다이제스트의 256비트 중 120비트가 달라진다. 공백 추가는 129비트, 다른 줄 끝 형식은 128비트, 줄바꿈 제거는 125비트를 바꿨다. 이 수치는 이 특정 파일들에서 측정한 결과다.
해시에게는 공백도 정보다
사람은 줄 끝 형식만 다른 두 파일을 같은 문장이라고 볼 수 있다. 바이트 비교는 다르게 본다. 편집기, 내보내기 도구, 전송 과정은 뚜렷한 시각적 변화 없이 줄 끝이나 인코딩을 바꿀 수 있다. 체크섬이 맞지 않으면 먼저 같은 버전의 정확한 파일을 비교했는지 확인하자. 복사한 텍스트나 다시 생성한 파일을 비교한 것은 아닌지도 살펴야 한다.
다른 다이제스트 비트 수를 수정량 점수로 읽지는 말자. 공백을 하나 더한 문서가 대문자를 하나 바꾼 문서보다 사람에게 의미 있는 방식으로 “더 다르다”는 뜻은 아니다. 해시 출력은 애초에 이런 유사성을 보존하지 않는다. 패턴은 변화에 대한 민감성을 보여 줄 뿐, 의미나 피해를 재는 자가 아니다.
잘못된 파일에도 맞는 체크섬을 붙일 수 있다
파일과 예상 체크섬을 모두 한 곳의 믿을 수 없는 출처에서 받았다고 해 보자. 누군가 파일을 바꾸고 그 파일의 체크섬을 새로 계산하면 비교는 여전히 통과한다. 무해한 대문자 버전에 그 자신의 다이제스트를 붙여 이 계산을 확인했다. 암호 기술을 깨뜨릴 필요가 없다. 기준값 자체가 바뀌었기 때문이다.
파일을 내려받을 때는 믿을 만한 근거가 있는 출처에서 예상 다이제스트를 얻고, 같은 알고리즘으로 16진수 문자 64개 전체를 비교해야 한다. 다운로드 옆에 적힌 다이제스트는 우발적인 손상을 찾는 데 도움이 된다. 그러나 침해된 출처 한 곳이 파일과 다이제스트를 모두 바꿀 수 있다면 그 둘만으로 배포자의 신원을 확인할 수는 없다.
서명은 다른 종류의 근거를 더한다
디지털 서명은 파일을 서명 키와 연결하고 서명 이후의 수정을 드러낼 수 있다. 그다음 꼭 물어야 할 것은 검증 키가 정말 의도한 배포자의 것인지다. 모르는 키로 검증에 성공했다는 사실만으로는 부족하다. 신뢰 관계를 즉석에서 만들어 내기보다 배포자가 문서화한 검증 절차나 신뢰하는 배포 경로를 이용하자.
진짜 서명이 있는 파일도 무해하거나 결함이 없거나 최신이거나 내 기기에 적합하다고 보장되지는 않는다. 무결성, 진위, 안전성은 관련 있지만 다른 검사다. 체크섬 도구는 악성코드 검사기가 아니다. 이번 텍스트 실험은 서명, 서명 키, 실행 파일, 다운로드 서비스의 보안을 시험하지 않았다.
비교 기준에 맥락을 붙여 두자
파일을 복사하거나 전송하거나 보관한 뒤에도 그대로 남아 있어야 할 때 체크섬은 특히 유용하다. 알고리즘, 정확한 파일 버전, 신뢰할 수 있는 기준 다이제스트를 함께 기록하자. 나중에 사본이 다르다면 억지로 맞추거나 곧바로 공격이라고 단정하지 말고 잠시 멈춰 원인을 살핀다.
믿을 수 있는 기준이 없어도 지금 계산한 해시는 앞으로 비교할 기준선이 될 수 있다. 다만 현재 파일이 처음 어디서 왔는지를 소급해 증명하지는 못한다. 이 작은 구분 덕분에 도구를 더 잘 쓸 수 있다. 어떤 불확실성은 사라졌고 어떤 질문은 여전히 남았는지 알게 되기 때문이다.
더 읽어 보기
NIST: Secure Hash Standard, FIPS 180-4 ↗Python: hashlib ↗NIST: Digital Signature Standard, FIPS 186-5 ↗공식 문서와 함께 읽으면 좋은 자료입니다.