해시 생성기
텍스트나 파일의 MD5, SHA-1, SHA-2, SHA-3, BLAKE2, CRC-32 해시 값을 한 번에 계산합니다.
내 스티커
도구를 여기에 고정하세요. 이 브라우저에 저장됩니다.
도구를 고정하면 그 스티커가 여기에 붙습니다.
이 도구에 대하여
해시의 용도
해시 함수는 길이에 상관없이 입력을 고정 길이의 짧은 해시 값(다이제스트)으로 바꿉니다. 같은 입력은 항상 같은 해시 값을 내고, 이 페이지의 암호학적 해시 함수에서는 입력이 1비트만 달라져도 원래 값과 전혀 관계없어 보이는 해시 값이 나옵니다. 그래서 해시 값은 지문 역할을 합니다. 두 해시 값이 다르면 입력도 다르고, 같으면 바이트 단위로 비교하지 않아도 두 입력은 거의 확실히 동일합니다.
대표적인 용도는 배포자가 공개한 체크섬으로 다운로드한 파일을 검증하기, 중복되거나 변경된 파일 찾기, 캐시 키 만들기입니다.
어떤 알고리즘을 고를까
보안과 관련된 용도에는 SHA-256, SHA-512, SHA-3, BLAKE2를 사용하세요. MD5와 SHA-1은 해시 값이 같은 서로 다른 두 입력을 의도적으로 만들어 낼 수 있어 보안 용도로는 이미 깨졌지만, 단순한 체크섬으로는 여전히 흔히 쓰입니다. CRC-32는 암호학적 해시가 아니며 우발적인 데이터 손상만 감지합니다.
이 중 어느 것도 비밀번호 저장에는 적합하지 않습니다. 빠르게 동작하도록 설계되었기 때문입니다. 비밀번호에는 bcrypt처럼 느리고 솔트를 사용하는 함수를 쓰세요.
여기서 SHA3-256은 FIPS 202로 표준화된 함수입니다. Ethereum에서 쓰는 Keccak-256은 이 표준보다 먼저 나온 것이어서 같은 입력에도 다른 해시 값을 냅니다.
해시 값의 계산 방식과 표기
해시 값은 Go의 해시 패키지(표준 라이브러리, BLAKE2는 golang.org/x/crypto)를 WebAssembly로 컴파일해 페이지의 메인 스레드가 아닌 Web Worker에서 계산합니다. 파일은 8 MB 단위로 나누어 읽으므로 큰 파일도 메모리에 통째로 올리지 않고 해시를 계산하며, 파일은 기기 밖으로 나가지 않습니다.
해시 값은 바이트의 나열입니다. hex와 HEX는 각 바이트를 16진수 두 자리로 쓰고, base64는 같은 바이트를 Subresource Integrity 속성에서 쓰는 형식인 Base64로 씁니다. 비교 필드에는 어느 표기든 입력할 수 있으며, sha256-…이나 sha256:…처럼 앞에 알고리즘 이름이 붙어 있어도 됩니다.
자주 묻는 질문
해시를 계산할 때 파일이 업로드되나요?
아니요. 파일은 브라우저가 읽고 사용자의 기기에서 해시를 계산합니다. 이 도구는 파일을 어디로도 보내지 않으며, 사이트의 Content-Security-Policy가 페이지에서 다른 호스트로 연결하는 것을 허용하지 않습니다.
다른 도구에서 계산한 MD5와 결과가 다른 이유는 무엇인가요?
보통은 눈에 보이지 않는 입력 차이 때문입니다. 끝에 붙은 줄바꿈, Windows 줄바꿈 문자, 바이트 순서 표식(BOM), 다른 텍스트 인코딩 등이 원인입니다. 이 도구는 입력란의 문자를 UTF-8로 인코딩해 해시하며 아무것도 덧붙이지 않습니다. 입력란의 줄바꿈은 항상 LF 하나이므로, Windows 줄바꿈이 있는 텍스트의 해시를 구하려면 파일로 저장한 뒤 그 파일의 해시를 계산하세요.
해시를 되돌려 원래 텍스트를 알아낼 수 있나요?
아니요. 해시 함수는 정보를 버리므로 복호화할 대상이 없습니다. 다만 짧거나 흔한 입력은 추측한 값의 해시와 비교하는 방식으로 찾아낼 수 있습니다. 비밀번호에 느리고 솔트를 사용하는 함수가 필요한 이유입니다.
SHA-2와 SHA-3는 무엇이 다른가요?
둘 다 NIST가 표준화했지만 설계가 다릅니다. SHA-256과 SHA-512가 속한 SHA-2는 오랫동안 기본으로 쓰여 온 계열입니다. SHA-3는 Keccak 스펀지 구조를 기반으로 하며, 언젠가 SHA-2에서 약점이 발견될 경우에 대비해 설계가 다른 대안으로 표준화되었습니다. 현재는 둘 다 안전하다고 여겨집니다.