fingerprint 파일 체크섬 검증기 star

소프트웨어 배포자가 체크섬을 공개하는 이유

리눅스 ISO, 오픈소스 바이너리, 서명된 설치 프로그램을 다운로드하면 다운로드 페이지에는 보통 파일 옆에 a94a8fe5ccb19ba61c4c0873d391e987982fbbd와 같은 짧은 체크섬 문자열이 함께 표시됩니다. 이 문자열은 파일의 모든 바이트에 대해 암호화 해시 함수를 실행한 결과입니다. 파일 어딘가의 단 하나의 비트만 바뀌어도 해시는 완전히 다르게 나옵니다. 배포자가 이를 공개하는 이유는, 파일을 다운로드한 뒤 사용자가 직접 같은 해시 함수를 실행해 그 결과를 배포자가 공개한 값과 비교할 수 있도록 하기 위해서입니다. 두 문자열이 정확히 일치한다면, 디스크에 있는 사본이 배포자가 빌드하고 업로드한 바이트와 정확히 같은 것을 담고 있다고 확신할 수 있습니다 — 추가된 것도, 빠진 것도, 바뀐 것도 없습니다.

체크섬은 서로 완전히 다른 두 가지 문제를 잡아냅니다. 첫 번째는 흔한 문제입니다: 네트워크 연결이 전송 도중 끊기거나, 프록시가 큰 파일을 잘라내거나, 디스크가 이따금 불량 섹터에 기록하는 경우 등이 있는데, 이런 상황 어느 것이든 완전해 보이는(크기도 맞고 눈에 띄는 오류 없이 열리는) 파일이 실제로는 원본과 몇 바이트가 손상되어 다를 수 있으며, 이는 종종 설치 프로그램을 멈추게 하거나 나중에 데이터를 조용히 손상시키기에 충분합니다. 두 번째는 악의적인 경우입니다: 공격자가 미러 서버를 침해하거나 전송 중인 다운로드를 가로채 악성코드가 포함된 변조된 바이너리로 바꿔치기했다면, 신뢰할 수 있는 공식 페이지에 게시된 값과 체크섬을 비교하는 것이 이를 실제로 잡아낼 수 있는 몇 안 되는 검사 중 하나입니다 — 파일 이름과 크기는 쉽게 위조할 수 있지만, 정확히 같은 해시를 재현하려면 원본과 완전히 동일한 바이트를 가지고 있어야 하기 때문입니다.

체크섬은 암호화가 아닙니다

체크섬이 정확히 무엇을 검증하는지는 짚고 넘어갈 가치가 있습니다. 용어가 자주 혼동되기 때문입니다. 해싱은 단방향의, 되돌릴 수 없는 연산입니다: SHA-256은 파일을 고정된 64자리 16진수 문자열로 바꾸지만, 그 문자열을 다시 파일로 되돌리는 연산은 존재하지 않습니다. 이 사실만으로도 이것이 암호화가 아님을 알 수 있습니다 — 암호화는 올바른 키가 있으면 되돌릴 수 있도록 설계되지만, 해싱은 애초에 절대 되돌릴 수 없도록 설계됩니다. 체크섬은 기밀성이 아니라 무결성을 검증합니다: 가지고 있는 바이트가 해시된 바이트와 같다는 것을 확인해 줄 뿐입니다. 파일에 접근할 수 있는 사람이라면 누구나 그 내용을 있는 그대로 읽을 수 있으며, 해싱은 내용을 숨기는 데 아무런 역할도 하지 않습니다. 해싱이 보장하는 것은, 고의든 실수든 단 하나의 바이트라도 바뀌면 계산한 해시가 더 이상 공개된 값과 일치하지 않게 되어 무언가 달라졌다는 것을 즉시 알 수 있다는 점입니다.

이 구분은 알고리즘 선택에도 중요합니다. SHA-1은 2017년 구글과 CWI 암스테르담의 연구자들이 "SHAttered" 공격을 발표하면서 암호학적 보안 측면에서 공식적으로 깨졌습니다: 동일한 SHA-1 해시를 만들어내도록 설계된 두 개의 서로 다른 PDF 파일을 통해, 충분히 의지가 있는 공격자라면 정상 파일과 같은 체크섬을 가지는 악성 파일을 만들 수 있음이 증명되었습니다. 이 결과로 SHA-1은 TLS 인증서, 디지털 서명, 고의로 충돌을 설계하는 공격자를 막는 용도 등 보안이 중요한 모든 곳에서 퇴출되었습니다. 하지만 이 도구가 다루는 훨씬 더 흔한 상황 — 불안정한 연결로 인해 다운로드가 손상되지 않았는지 확인하는 것 — 에서는 SHA-1이 실제로는 여전히 잘 작동합니다. 특정 대상 해시와 일치하도록 손상된 다운로드를 의도적으로 설계하는 사람은 없기 때문입니다. 우연한 손상은 무작위 비트 반전이지 의도적인 충돌 설계가 아닙니다. 그럼에도 배포자가 선택지를 제공한다면, SHA-256은 계산 비용이 전혀 추가되지 않으면서 이 문제를 완전히 없애 주므로 더 안전한 기본값입니다.