🔐 파일 해시 계산 · 대조 (SHA-256 / MD5 / SHA-1)
브라우저에 파일을 드롭하기만 하면 MD5, SHA-1, SHA-256을 즉시 계산합니다. 다운로드한 파일의 변조 감지와 무결성 확인에 활용하세요.
계산 중...
✅ 예상값과 비교 (체커 모드)
벤더 사이트의 SHA-256 / MD5 / SHA-1 값을 붙여넣으면 위에서 계산된 값과 일치하는지 자동 판정합니다. 불일치 = 파일이 손상되었거나 변조되었습니다.
📖 자주 걸리는 지점
파일을 드롭하면 MD5 / SHA-1 / SHA-256 을 Web Crypto API 로 계산하고, 기대값을 붙이면 일치하는지 판정합니다. 파일은 브라우저 밖으로 나가지 않습니다. 여기서 확인할 수 있는 것은 「내 손의 바이트열이 공개된 값과 일치하는가」뿐입니다 — 그 파일이 안전한지도, 공개된 값 자체를 믿을 수 있는지도 해시로는 알 수 없습니다. 해시는 「동일성」의 도구이지 「정당성」의 도구가 아닙니다. 이 둘을 혼동한 채 운용하면 검증하고 있다는 기분만 들고 실제로는 아무것도 검증하지 않은 상태가 됩니다.
| 사례 | 무슨 일이 일어나는가 | 어떻게 하면 되는가 |
|---|---|---|
| 해시가 일치해도 변조되지 않았다는 보장은 없다 | 공개된 해시 값이 다운로드처와 같은 서버에 놓여 있다면 양쪽 모두 바꿔치기할 수 있습니다. 공격자가 파일을 바꿔치기할 수 있는 위치에 있다면 바로 옆에 있는 해시 값도 바꿔치기할 수 있습니다 — 그리고 일치하므로 당신의 검증은 성공합니다. 이 구도에서 지킬 수 있는 것은 「전송 중의 손상」과 「미러의 착오」뿐이며 침해된 서버에서의 다운로드에는 아무런 효과가 없습니다. 실제로 몇몇 오픈소스 프로젝트가 배포 서버를 침해당해 바이너리와 체크섬 양쪽이 바뀐 사례가 있습니다. 「체크섬을 확인했습니다」는 그것만으로는 보안상의 주장이 되지 않습니다. | 해시 값은 파일과는 다른 경로에서 가져오세요. 배포 사이트가 미러라면 해시 값은 본가의 릴리스 노트나 GitHub 의 Releases 페이지에서 가져옵니다. 더 확실한 것은 서명의 검증으로, GPG·minisign·OS 의 코드 서명은 비밀 키가 없으면 만들 수 없으므로 서버를 침해당한 것만으로는 위조할 수 없습니다 — gpg --verify file.sig file 한 줄이면 됩니다. 다만 「키를 어디서 입수했는가」가 문제가 됩니다 — 같은 침해된 사이트에서 키를 내려받았다면 원점으로 돌아갑니다. 패키지 매니저 (apt / dnf / winget / Homebrew) 를 쓸 수 있다면 그것이 최선의 선택입니다 — 키의 배포와 검증이 구조로 내장되어 있어 당신이 절차를 틀릴 여지가 없습니다. |
| MD5 와 SHA-1 은 이제 변조 검출에 쓸 수 없다 | MD5 의 충돌은 노트북으로 몇 초면 만들 수 있습니다 — 같은 MD5 값을 갖는 「무해한 문서」와 「악의적인 실행 파일」을 의도적으로 생성할 수 있다는 뜻입니다. SHA-1 도 2017 년에 실제 충돌이 공개되었고 2020 년에는 임의의 접두어로 충돌을 만드는 기법까지 제시되었습니다. 이것이 뜻하는 바는 「MD5 가 일치하니 같은 파일이다」라는 추론이 성립하지 않게 되었다는 것입니다. 다만 용도에 따라서는 지금도 유효합니다 — 우연한 손상 (전송 오류·디스크 불량) 을 검출할 목적이라면 MD5 로도 충분히 기능합니다. 공격자가 없다는 전제에서만 쓸 수 있다고 정리하세요. | 보안 목적이라면 SHA-256 을 쓰세요. 이 페이지는 셋을 동시에 계산하므로 기대값이 MD5 로만 공개되어 있어도 SHA-256 을 적어 두면 다음부터는 강한 비교를 할 수 있습니다. 배포하는 쪽이라면 SHA-256 을 공개하세요 — sha256sum file (Linux), shasum -a 256 file (macOS), certutil -hashfile file SHA256 (Windows) 로 생성할 수 있습니다. 이미 MD5 로 운용 중인 시스템을 고칠 때의 우선순위는 분명합니다: 서명 검증이나 인증에 쓰고 있다면 최우선으로 교체하고, 파일의 중복 판정이나 캐시 키로만 쓰고 있다면 서두를 필요가 없습니다 — 후자는 공격자가 끼어들 경로가 없기 때문입니다. 비밀번호 저장에 MD5 나 SHA-256 을 쓰고 있다면 그것은 다른 종류의 문제입니다 — bcrypt / Argon2 로 바꾸세요. |
| 일치하지 않는 원인의 대부분은 변조가 아니다 | 값이 어긋났을 때 먼저 의심할 것은 절차의 어긋남입니다. 빈도가 높은 순으로: 다운로드가 도중에 끊겼다 (크기를 보면 한눈에 압니다), 해시를 뜨는 대상이 다르다 (배포 페이지의 값은 .iso 것인데 당신은 .zip 을 계산하고 있다), 기대값의 복사에 불필요한 공백이나 줄바꿈이 섞였다, 대소문자의 차이 (이것은 무시되므로 문제가 되지 않습니다). 그리고 놓치기 쉬운 것이 Git 을 거쳐 받은 텍스트 파일입니다 — core.autocrlf 가 켜진 Windows 에서는 체크아웃 때 줄바꿈이 CRLF 로 변환되므로 바이트열이 바뀌고 해시도 바뀝니다. 파일의 내용은 「같은데」 해시는 다르다는 상태가 정당하게 일어납니다. |
먼저 파일 크기를 비교하세요. 배포 페이지에는 보통 바이트 수가 적혀 있습니다 — 크기가 다르면 해시를 계산할 것도 없이 다른 파일이거나 불완전한 다운로드입니다. 재다운로드는 브라우저가 아니라 curl -L -O 나 wget -c 로 하면 도중에 끊기기 어렵고 끊겨도 검출할 수 있습니다. 텍스트 파일을 검증한다면 줄바꿈 코드를 맞춘 뒤 비교하세요 (줄바꿈 코드 변환). 그리고 가장 중요한 원칙: 일치하지 않은 파일은 원인을 특정할 때까지 실행하지 마세요. 「아마 다운로드 실패겠지」라고 생각하고 실행하는 것은 검증하지 않은 것과 같습니다 — 다시 받아서 다시 확인하면 그만입니다. |
해시를 개인정보의 익명화에 쓰지 마세요. 메일 주소나 전화번호처럼 취할 수 있는 값이 사실상 유한한 것은 전수 조사로 되돌릴 수 있습니다 — 한 나라의 휴대전화 번호는 10 억 가지 정도밖에 없으므로 전부 해시화해 대조표를 만드는 데 몇 분도 걸리지 않습니다. 해시화한 개인정보는 많은 법역에서 여전히 개인정보입니다. 정말 필요하다면 솔트가 아니라 비밀 키를 쓰는 HMAC 로 하거나 애초에 가역적인 암호화로 하고 키를 관리하세요. 또 하나 실무적인 주의로, 「같은 파일」의 정의는 포맷에 따라 다릅니다 — ZIP 은 타임스탬프를 포함하므로 같은 내용을 다시 압축하면 해시가 바뀝니다. Docker 이미지나 tar 도 마찬가지이며 빌드할 때마다 다른 해시가 되는 것은 정상입니다. 재현 가능한 해시가 필요하다면 타임스탬프를 고정하는 재현 가능 빌드의 구조가 필요합니다.
📖 사용법
-
1
파일 드래그 & 드롭검증하려는 파일을 드롭 영역에 드래그하세요.
-
2
해시 자동 계산MD5 / SHA-1 / SHA-256가 병렬로 계산됩니다.
-
3
공식 값과 비교벤더 사이트의 해시를 붙여넣으면 일치 여부가 표시됩니다.
❓ 자주 묻는 질문
SHA-3 / BLAKE2도 지원하나요?
파일이 서버로 업로드되나요?
다운로드한 파일의 무결성을 확인하려면?
MD5는 여전히 안전한가요?
🐛 이 도구에서 문제가 발생했나요?
무료 · 가입 불필요. 재현 절차만이라도 도움이 됩니다. 보고는 운영자에게 직접 전달되어 개선에 사용됩니다.
보고 감사합니다!
운영자에게 전달되었습니다. 개선에 사용됩니다.