해시는 임의 길이의 데이터를 고정 길이의 짧은 값으로 압축하는 단방향 함수입니다. 같은 입력은 언제나 같은 해시를 내놓고, 한 글자만 바뀌어도 결과는 완전히 달라집니다. 이 성질 덕분에 파일이 전송 중 손상됐는지 확인하거나, 두 데이터가 같은지 내용을 비교하지 않고도 판단할 수 있습니다.
이 도구는 MD5, SHA-1, SHA-256, SHA-384, SHA-512, CRC32를 한 번에 계산합니다. SHA 계열과 HMAC은 브라우저에 내장된 Web Crypto를 쓰므로 네이티브 속도로 동작하고, Web Crypto가 지원하지 않는 MD5와 CRC32만 직접 구현했습니다. 파일을 넣어도 브라우저 안에서만 읽으므로 서버로 올라가지 않습니다.
사용 방법
- 텍스트 또는 파일 선택 — 상단에서 텍스트와 파일을 고릅니다. 텍스트는 입력하는 즉시 여섯 가지 해시가 계산되고, 파일은 선택하는 순간 전체를 읽어 계산합니다. 파일은 네트워크로 전송되지 않고 브라우저 메모리에서만 처리됩니다.
- 표기 형식 맞추기 — 대문자로와 콜론으로 구분 옵션으로 표기를 맞춥니다. 인증서 지문이나 네트워크 장비 설정은
AA:BB:CC형태로 대문자·콜론 표기를 쓰는 경우가 많아, 붙여넣어 비교하기 전에 형식을 맞춰 두면 편합니다. - 받은 체크섬과 대조하기 — 기대값과 대조에 배포처에서 제공한 체크섬을 붙여넣으면 일치하는 알고리즘 줄에 '일치' 배지가 붙습니다. 대소문자와 콜론, 공백은 무시하고 비교하므로 형식을 맞추지 않고 그대로 붙여넣어도 됩니다.
- HMAC 서명 만들기 — 맨 아래 HMAC 영역에 시크릿 키를 넣으면 서명 값이 계산됩니다. 웹훅 서명을 검증하거나 API 요청에 서명을 붙일 때 값을 직접 확인해 볼 수 있습니다. 시크릿 역시 브라우저를 벗어나지 않습니다.
자주 묻는 질문
비밀번호를 해시해서 저장해도 되나요?
안 됩니다. SHA-256을 포함해 여기 있는 알고리즘은 전부 빠르게 계산되도록 설계되어 있고, 비밀번호 저장에는 그 빠름이 치명적입니다. 요즘 GPU는 SHA-256을 초당 수십억 번 계산하므로, 유출된 해시 목록에서 흔한 비밀번호를 찾아내는 데 몇 분이면 충분합니다.
비밀번호는 bcrypt, scrypt, Argon2처럼 의도적으로 느리고 메모리를 많이 쓰도록 설계된 알고리즘을 써야 합니다. 이런 함수들은 사용자별 솔트를 자동으로 처리하고, 하드웨어가 빨라지면 비용 계수를 올려 대응할 수 있습니다.
MD5는 왜 '보안 용도 부적합'으로 표시되나요?
같은 해시 값을 갖는 서로 다른 두 데이터를 실제로 만들어 낼 수 있기 때문입니다. 2004년에 이론이 나왔고 지금은 일반 노트북에서 몇 초 만에 충돌을 생성할 수 있습니다. SHA-1도 2017년에 실제 충돌이 공개되면서 같은 처지가 됐습니다.
다만 '깨졌다'는 것이 모든 용도에서 쓸모없다는 뜻은 아닙니다. 파일이 전송 중 우연히 손상됐는지 확인하거나, 캐시 키를 만들거나, 중복 파일을 찾는 것처럼 공격자가 개입하지 않는 상황에서는 여전히 쓸 만합니다. 서명 검증이나 무결성 보장처럼 누군가 위조를 시도할 수 있는 곳에서만 피하면 됩니다.
같은 파일인데 다운로드한 사이트의 해시와 다릅니다.
먼저 어떤 알고리즘의 값인지 확인하세요. 배포 페이지에 적힌 것이 SHA-256인데 MD5 값과 비교하고 있으면 당연히 다릅니다.
알고리즘이 맞는데도 다르다면 파일이 실제로 다른 것입니다. 다운로드가 중간에 끊겼거나, 압축이 풀린 상태로 받아졌거나, 다른 버전을 받았을 가능성이 있습니다. 특히 브라우저가 자동으로 gzip을 풀어 저장하는 경우가 있으니 파일 크기부터 비교해 보세요. 크기가 다르면 내용이 다른 것이 확실합니다.
CRC32는 왜 다른 값들보다 짧은가요?
CRC32는 해시가 아니라 체크섬이고, 결과가 32비트(16진수 8자리)뿐입니다. 전송 중 발생하는 우연한 비트 오류를 잡아내려고 만든 것이지 서로 다른 데이터를 구분하려고 만든 것이 아닙니다.
값의 범위가 약 43억 개뿐이라 우연한 충돌도 쉽게 일어납니다. zip 파일이나 PNG 내부에서 무결성 확인용으로 쓰이는 이유가 그 정도 용도에는 충분하고 계산이 매우 빠르기 때문입니다. 파일을 식별하거나 비교하는 목적이라면 SHA-256을 쓰세요.
알아두면 좋은 개념
해시 충돌과 생일 역설
SHA-256은 2^256가지 값을 만들 수 있습니다. 우주의 원자 수보다 큰 수라 우연한 충돌은 사실상 일어나지 않습니다. 하지만 '충돌을 찾는 난이도'는 직관보다 훨씬 낮습니다.
생일 역설 때문입니다. 방에 23명만 있어도 생일이 같은 쌍이 있을 확률이 50%를 넘듯이, n비트 해시에서 충돌을 찾는 데 필요한 시도 횟수는 2^n이 아니라 2^(n/2)입니다. SHA-256이라면 2^128번이라 여전히 불가능하지만, 128비트 해시라면 2^64로 떨어져 현실적인 공격 범위에 들어옵니다. 해시 길이를 고를 때 절반으로 계산해야 하는 이유입니다.
HMAC이 단순 해시보다 안전한 이유
메시지에 시크릿을 그냥 이어 붙여 해시하는 방식(hash(secret + message))은 길이 확장 공격에 취약합니다. SHA-256 같은 머클-담고르 구조의 해시는 중간 상태를 이어받아 계산을 계속할 수 있어서, 공격자가 시크릿을 몰라도 원래 메시지 뒤에 내용을 덧붙인 유효한 서명을 만들어 낼 수 있습니다.
HMAC은 시크릿을 두 번, 서로 다른 패딩과 함께 사용하는 구조(hash(key⊕opad + hash(key⊕ipad + message)))로 이 문제를 막습니다. 웹훅 서명이나 API 인증에서 HMAC을 쓰라고 하는 이유가 여기에 있습니다. 직접 sha256(secret + body) 같은 방식을 만들어 쓰지 마세요.
해시 비교는 상수 시간으로
서버에서 서명을 검증할 때 if (computed === received) 같은 일반 문자열 비교를 쓰면 타이밍 공격에 노출됩니다. 대부분의 문자열 비교는 다른 문자를 만나는 즉시 중단하므로, 앞부분이 더 많이 일치할수록 비교에 걸리는 시간이 미세하게 길어집니다.
공격자는 이 시간 차이를 반복 측정해 한 글자씩 올바른 값을 알아낼 수 있습니다. 그래서 서명 검증에는 Node.js의 crypto.timingSafeEqual 이나 파이썬의 hmac.compare_digest 처럼 길이에 관계없이 항상 같은 시간이 걸리는 비교 함수를 써야 합니다. 이 도구의 대조 기능은 브라우저에서 눈으로 확인하는 용도이므로 해당하지 않습니다.