MD5를 SHA-256으로 변환? 불가능한 이유와 올바른 해결법
이 변환을 해 준다고 광고하는 페이지는 아주 많고, 그중 일부는 실제로 동작하는 도구처럼 보이기까지 합니다. 하지만 그 페이지들이 내세우는 연산은 존재하지 않습니다. 이유를 알고 나면 대신 무엇을 해야 할지도 정리됩니다.
짧은 답: MD5를 SHA-256으로(또는 SHA-256을 MD5로) 변환할 수는 없습니다
MD5 해시를 SHA-256으로 변환하는 것은 불가능합니다. MD5 다이제스트는 128비트짜리 출력일 뿐, 그 값을 만들어 낸 입력을 담고 있지 않습니다. SHA-256은 무언가를 계산하려면 바로 그 입력이 필요합니다. 원본 데이터가 없으면 중간 단계는 계속 비어 있고, 어떤 도구나 라이브러리도 그 자리를 채워 주지 못합니다.
같은 입력을 세 알고리즘에 넣은 결과입니다.
| 알고리즘 | hello의 다이제스트 | 16진수 문자 수 | 비트 |
|---|---|---|---|
| MD5 | 5d41402abc4b2a76b9719d911017c592 | 32 | 128 |
| SHA-1 | aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d | 40 | 160 |
| SHA-256 | 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 | 64 | 256 |
세 다이제스트를 문자열로 놓고 비교해 보십시오. 공통된 접두사도 없고 겹치는 부분 문자열도 없습니다. 한쪽 값에서 다른 쪽을 끌어낼 산술적 관계도 물론 없습니다. 셋을 이어 주는 유일한 고리는 hello라는 단어인데, 정작 그 단어를 품고 있는 다이제스트는 하나도 없습니다. MD5 해시 생성기와 SHA-256 생성기로 직접 계산해 보면, 타이핑하는 동안 두 값이 서로 무관하게 따로 변하는 모습을 볼 수 있습니다.
방향을 뒤집어도 마찬가지입니다. SHA-256에서 MD5로 가는 것도 정확히 같은 이유로 실패합니다. 두 함수 모두 의도적으로 정보를 버리기 때문에, 어느 쪽 다이제스트도 상대 함수가 필요로 하는 입력으로 되돌릴 수 없습니다.
해시 이론이 궁금해서 이 검색어를 치는 사람은 없습니다. 그렇다면 원래 하려던 일은 무엇이었을까요? 현실에서는 대개 다음 네 가지 중 하나이고, 각각에는 답이 있습니다.
- 다운로드 파일 검증 또는 체크섬 비교
- 비밀번호 데이터베이스를 MD5에서 다른 방식으로 마이그레이션
- 해시 뒤에 있는 원본 입력 복구
- 같은 데이터를 다른 알고리즘으로 해싱
네 가지는 아래에서 하나씩 다룹니다. 그 전에 변환을 약속하는 페이지가 실제로 무슨 일을 하는지 알아 두면, 그런 페이지의 출력을 믿는 실수를 피할 수 있습니다.
”MD5 → SHA-256 변환기” 페이지가 실제로 하는 일
가능성은 세 가지뿐이고, 그중 변환에 해당하는 것은 하나도 없습니다.
가장 흔한 형태는 원본 텍스트를 요구하는 것입니다. 문자열을 붙여넣으면 페이지가 두 다이제스트를 모두 만들어 내고, 홍보 문구는 이를 변환이라고 부릅니다. 이름표만 잘못 붙은 해시 생성기입니다. 변환된 것은 없고, 입력이 두 번 해싱됐을 뿐입니다.
다음으로 흔한 것은 다이제스트를 조회하는 방식입니다. 이런 페이지는 단어 목록과 유출된 자격 증명 덤프에서 긁어모은 “입력–다이제스트” 쌍 테이블을 갖고 있습니다. 입력이 그 테이블에 들어 있는 MD5를 붙여넣으면 페이지가 입력을 찾아낸 뒤 SHA-256으로 해싱해 결과를 보여 줍니다. password, 123456 같은 값이나 그 밖의 짧은 문자열 상당수에는 통합니다. 그 외에는 아무 표시 없이 조용히 실패하는데, 이런 페이지가 설명 한 줄 없이 빈 결과를 반환하는 이유가 여기에 있습니다.
마지막은 아무 일도 하지 않는 경우입니다. 놀랄 만큼 많은 페이지가 그저 입력을 그대로 다시 보여 주거나, 붙여넣은 16진수 문자열의 SHA-256을 내놓으면서 그것이 원본 데이터의 SHA-256인 양 굴기도 합니다. 두 값은 서로 다르며, 아래 이중 해싱 절에서 얼마나 다른지 정확히 확인할 수 있습니다.
확인은 금방 끝납니다. 32자짜리 16진수 문자열만 던져 주고, 이 페이지가 입력을 알아낼 방법이 있는지 자문해 보십시오. 그런데도 64자짜리 결과를 내놓고 그것을 변환이라고 부른다면, 조회 테이블을 뒤지고 있거나 거짓말을 하고 있는 것입니다. 원본 데이터를 한 번도 묻지 않는 해시 변환기가 정답을 낼 수 있는 길은 우연밖에 없습니다. 그런데도 이 표현이 살아남는 이유는, 실제로 동작하는 다른 작업과 비슷하게 들리기 때문입니다.
해싱, 인코딩, 암호화: 셋 중 되돌릴 수 있는 것은 둘뿐
개발자는 이 셋을 같은 주에 마주치고는 머릿속 같은 서랍에 넣어 둡니다. 하지만 동작 방식은 완전히 다릅니다.
| 연산 | 예시 | 되돌릴 수 있나? | 필요한 것 |
|---|---|---|---|
| 인코딩 | Base64, 16진수, URL 인코딩 | 언제나 가능 | 아무것도 필요 없음 |
| 암호화 | AES, RSA | 가능 | 키 |
| 해싱 | MD5, SHA-1, SHA-256 | 불가능 | 무엇으로도 안 됨 |
잘못된 직관을 심어 주는 쪽은 Base64입니다. 누구나 키도 권한도 없이 Base64 문자열을 디코딩해 원래 바이트로 되돌릴 수 있고, Base64를 16진수로 변환하는 것도 지극히 정상적인 일상 작업입니다. 둘 다 같은 바이트를 다른 방식으로 적어 놓은 것에 지나지 않습니다. 그 동작을 본 적이 있다면 “MD5 → SHA-256”도 같은 부류의 표기 변환처럼 들립니다.
그렇지 않습니다. 인코딩은 입력의 모든 비트를 보존하고, 암호화는 키 뒤에 보존하며, 해싱은 그 대부분을 그냥 버립니다. MD5 다이제스트는 비밀번호를 넣든 40GB 디스크 이미지를 넣든 언제나 16바이트입니다. 그 40GB는 어딘가에 교묘하게 접혀 들어가지 않습니다. 그냥 사라집니다. 암호화와의 비교를 더 자세히 보고 싶다면 MD5 도구의 FAQ에 정리돼 있지만, 여기서는 한 줄이면 충분합니다. 키가 없으므로 복호화할 대상 자체가 없습니다.
”MD5는 깨졌다”가 “MD5는 되돌릴 수 있다”는 뜻은 아닙니다
성실하게 쓴 글에서도 이 부분은 자주 틀립니다. “MD5는 오래전에 깨졌다”에서 “그러면 이제쯤 누군가는 되돌릴 수 있겠지”로 곧장 넘어가는 식입니다.
여기에는 서로 다른 두 공격이 얽혀 있습니다.
- 충돌 공격(collision attack)은 같은 다이제스트를 내놓는 서로 다른 두 입력을 찾아냅니다. 공격자가 두 입력을 모두 고르며, 그 내용이 무엇인지는 신경 쓰지 않습니다.
- 역상 공격(preimage attack)은 다이제스트에서 출발해 그 값을 만들어 내는 입력을 복구합니다. MD5를 SHA-256으로 변환할 수 있게 해 주는 쪽은 바로 이 공격입니다. SHA-256에 넣을 입력을 되돌려주기 때문입니다.
MD5의 충돌 저항성은 2004년에 무너졌고, 오늘날에는 평범한 하드웨어에서 몇 초 만에 충돌을 만들어 낼 수 있습니다. MD5가 서명, 인증서, 그리고 공격자가 개입할 수 있는 모든 곳에 부적합한 이유가 이것입니다.
반면 MD5의 역상 저항성은 무너지지 않았습니다. 지금까지 알려진 최선의 역상 공격도 여전히 이론에 머물러 있으며, 복잡도는 2^123.4입니다(Sasaki and Aoki, 2009). 전수 탐색보다 아주 근소하게 빠를 뿐, 현실에서 실행할 수 있는 범위와는 거리가 멉니다. 임의의 MD5 다이제스트를 역산하는 사람은 2004년에도 지금도 없습니다.
그래서 두 사실은 모순 없이 나란히 성립합니다. MD5는 깨졌고, 그럼에도 여전히 되돌릴 수 없습니다. 이 글의 결론은 그 붕괴와 무관하게 그대로 유효합니다. 둘 사이를 변환하려는 것이 아니라 새 시스템에 쓸 알고리즘을 고르는 상황이라면, MD5 vs SHA-256 비교에서 그 결정을 제대로 다룹니다.
실제로 하려던 작업 네 가지와 각각의 해법
| 실제로 하려는 일 | 진짜 해법 |
|---|---|
| 다운로드 검증 또는 체크섬 비교 | 필요한 알고리즘으로 파일에서 다시 계산 |
| MD5 비밀번호 해시 마이그레이션 | bcrypt로 감싼 뒤 로그인 시점에 업그레이드 |
| 원본 입력 복구 | 변환이 아니라 크래킹이며, 엔트로피에 달려 있음 |
| 같은 데이터를 다른 알고리즘으로 다시 해싱 | 원본 바이트로 돌아갈 것 |
작업 1: 체크섬을 비교하거나 다운로드를 검증하려는 경우
변환하지 말고 다시 계산하십시오. 파일이 디스크에 그대로 있다는 것은, 다이제스트가 잃어버린 바로 그것을 갖고 있다는 뜻입니다. 필요한 알고리즘을 그 파일에 대해 실행하면 됩니다.
# GNU coreutils
md5sum ubuntu-24.04-desktop-amd64.iso
sha256sum ubuntu-24.04-desktop-amd64.iso
# macOS
md5 ubuntu-24.04-desktop-amd64.iso
shasum -a 256 ubuntu-24.04-desktop-amd64.iso
여기서 흔히 부딪히는 어긋남은, 배포자는 MD5만 올려놓았는데 사내 보안 정책은 SHA-256을 요구하는 상황입니다. 공개된 MD5를 변환하는 일이 설령 가능하더라도 아무것도 입증하지 못합니다. 다른 다이제스트에서 파생한 다이제스트는 그 파일에 대한 배포자의 진술이 아니기 때문입니다. 필요한 것은 배포자가 서명한 SHA-256입니다. 배포자 쪽에 그런 값이 없다면, SHA-256 생성기로 직접 계산한 SHA-256도 내부용으로는 여전히 안정적인 지문이 됩니다. 값을 고정해 두면 미러 사이를 비교하거나 나중에 파일이 바뀐 것을 잡아낼 수 있습니다. 다만 배포자의 보증을 대신할 수는 없습니다.
작업 2: 비밀번호 데이터베이스를 MD5에서 옮기려는 경우
걸린 것이 가장 많은 작업이고, 이미 잘 다져진 해법이 있습니다. 기존 해시를 감싼 다음, 로그인 시점에 계정을 하나씩 조용히 업그레이드하는 방식입니다. 저장된 MD5 해시 전체를 배치 작업 한 번으로 bcrypt 처리하고, 그 뒤로 로그인 경로는 입력받은 비밀번호를 먼저 MD5로 해싱한 뒤 그 값을 bcrypt 레코드와 비교합니다.
오래된 조언 중에는 이 부분을 거꾸로 말하는 것이 많습니다. MD5를 SHA-256으로 감싼다고 해서 비밀번호 저장이 안전해지지는 않습니다. SHA-256도 빠른 해시라서 MD5와 같은 범주의 문제를 안고 있습니다. GPU는 둘 다 엄청난 속도로 갈아 치웁니다. 데이터베이스에 내장된 SHA2() 함수를 해법으로 권하는 조언은 엉뚱한 문제를 풀고 있는 것입니다. 목표는 의도적으로 느리게 설계된 해시, 즉 bcrypt, scrypt, Argon2입니다. bcrypt(md5(password))를 저장하고, sha256(md5(password))는 절대 저장하지 마십시오. 셋 중 무엇을 고를지는 bcrypt vs Argon2 vs scrypt 비교에서 다루며, bcrypt 생성기로는 하나를 확정하기 전에 코스트 팩터를 시험해 볼 수 있습니다.
마이그레이션이 실제로 깨지는 지점은 따로 있습니다. “비밀번호의 MD5”라는 말이 두 가지로 읽히고, 두 해석이 서로 다른 결과를 낸다는 것입니다.
const { createHash } = require('node:crypto');
const md5Hex = createHash('md5').update('hello').digest('hex');
const md5Raw = createHash('md5').update('hello').digest(); // the same value as 16 bytes
createHash('sha256').update(md5Hex).digest('hex');
// 4914e23374bb211e3dca0df7636fefffc7fedd94f1340ae81c7d6c07b7113e9b
createHash('sha256').update(md5Raw).digest('hex');
// 88e20f0abb88153e3f0a9683668ccb5b84ed771817dc448a2b73254ed02c8d8c
createHash('sha256').update('hello').digest('hex');
// 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
셋 다 맞는 값이고, 셋 다 다릅니다. 32자 16진수 문자열을 해싱하면 한 값이 나오고, 그 문자열이 나타내는 16바이트 원시 데이터를 해싱하면 또 다른 값이 나오며, 원본 비밀번호를 해싱하면 세 번째 값이 나옵니다. 규칙을 하나 정해 문서로 남기고, 마이그레이션 스크립트와 로그인 경로에서 똑같이 적용하십시오. 여기서 틀리면 전체 사용자가 한꺼번에 로그인하지 못하게 됩니다. 게다가 증상이 bcrypt 버그처럼 보여서, 인코딩 선택을 의심하기까지 시간이 꽤 걸립니다.
bcrypt로 감쌀 때는 16진수 쪽이 더 안전한 규칙입니다. 원시 다이제스트 바이트에는 0 바이트가 들어갈 수 있는데, 일부 bcrypt 구현은 입력을 C 문자열로 취급해 거기서 읽기를 멈춥니다. 16진수를 쓰면 그 문제가 아예 생기지 않고, 32자이므로 bcrypt의 입력 길이 제한에도 한참 못 미칩니다. 대소문자도 정규화하십시오. 5D41402A...와 5d41402a...는 같은 다이제스트지만 bcrypt에게는 서로 다른 문자열입니다.
const bcrypt = require('bcrypt');
const { createHash } = require('node:crypto');
const legacyDigest = (password) =>
createHash('md5').update(password, 'utf8').digest('hex'); // lowercase hex
// Batch job, run once: wrap each stored MD5, then drop the old column.
async function wrapRow(row) {
return bcrypt.hash(row.md5_hash.toLowerCase(), 12);
}
// Login path
async function verify(password, row) {
if (row.scheme === 'bcrypt') {
return bcrypt.compare(password, row.hash);
}
const ok = await bcrypt.compare(legacyDigest(password), row.hash);
if (ok) {
const upgraded = await bcrypt.hash(password, 12);
await saveCredential(row.id, { scheme: 'bcrypt', hash: upgraded }); // your DB write
}
return ok;
}
사용자가 로그인할 때마다 해당 계정은 순수 bcrypt로 옮겨 갑니다. 끝까지 남는 계정에는 기한을 정해 두고, 기한이 지나면 비밀번호 재설정을 강제하십시오.
작업 3: 원본 입력을 복구하려는 경우
하려는 일이 무엇인지는 적어도 스스로에게 분명히 말해 두는 편이 좋습니다. 쓸 도구도 기대치도 달라지기 때문입니다. 다이제스트에서 입력을 복구하는 일은 변환이 아니라 크래킹입니다. 성공 여부는 어떤 알고리즘이 그 다이제스트를 만들었는지와 상관없이, 입력이 무엇이었는지에 달려 있습니다.
사람이 직접 고른 짧고 흔한 문자열은 금방 뚫립니다. 사전에 있는 단어, 뒤에 숫자 하나를 붙인 이름, 유출 데이터 모음에 한 번이라도 등장한 값은 조회 한 번이나 짧은 전수 탐색이면 무너집니다. 길고 무작위한 문자열은 아예 뚫리지 않으며, 두 경우의 격차는 하드웨어를 더 사서 메울 수 있는 종류가 아닙니다.
레인보우 테이블은 흔히 도는 설명보다 조건이 훨씬 좁습니다. 레인보우 테이블이 입력을 복구하는 것은 그 입력이 솔트 없이 해싱됐고 이미 테이블에 들어 있는 경우뿐입니다. 두 조건이 모두 필요합니다. 사용자별 솔트를 넣으면 미리 계산해 둔 테이블은 쓸모없어집니다. 공격자가 솔트마다 별도의 테이블을 만들어야 하기 때문입니다. 128비트 무작위 토큰을 해싱했다면 그 값을 담고 있는 테이블은 세상 어디에도 없습니다. 그 경계선이 어디쯤인지는 비밀번호 엔트로피 가이드에서 숫자로 확인할 수 있습니다.
입력이 본인 소유의 비밀번호인데 다시 만들어 낼 수 없다면, 복구는 접고 재설정으로 처리하십시오. 다른 사람의 것이라면, 하려는 일의 정확한 이름은 위에서 말한 크래킹입니다.
작업 4: 같은 데이터를 다른 알고리즘으로 해싱해야 하는 경우(“md5 to sha1 converter”)
작업 1과 같은 모양을 일반화한 것입니다. 요청에 등장하는 알고리즘 조합이 무엇이든, 답은 언제나 원본 바이트로 돌아가 다시 해싱하는 것입니다.
sha1sum payload.bin
sha256sum payload.bin
검색해서 나오는 “md5 to sha1 converter”는 하나같이 재해싱 도구이거나 조회 테이블이며, 이유는 위에서 설명한 것과 같습니다. 원본 데이터가 없다면 이 작업에는 해법이 없습니다. 더 나은 도구를 찾는다고 달라지는 문제가 아닙니다. 목표 알고리즘은 SHA 계열 비교를 보고 고르십시오. SHA-1 생성기는 아직 SHA-1을 요구하는 레거시 시스템을 위해 있는 것이고, 새로 만드는 시스템이라면 쓸 이유가 없습니다.
해시 변환기의 조회가 실제로 통하는 유일한 경우
예외가 하나 있습니다. 어떤 종류의 데이터는 한곳에 모여 있고, 흔히 쓰이는 다이제스트 전부로 동시에 색인돼 있습니다. 악성코드 샘플이 대표적입니다. VirusTotal 같은 서비스는 샘플 자체를 보관하므로 같은 바이트에서 MD5, SHA-1, SHA-256을 모두 계산해 세 값을 하나의 레코드에 함께 넣어 둡니다. 그곳에서 샘플의 MD5를 검색하면 그 샘플의 SHA-256이 돌아옵니다.
이것은 변환이 아니라 데이터베이스 조인입니다. 누군가가 원본 파일을 갖고 모든 알고리즘으로 해싱해 뒀기 때문에 동작하는 것이고, 위에서 설명한 재계산 단계를 제삼자가 미리 해 둔 것일 뿐입니다. 조건은 까다롭습니다. 대상 객체가 이미 색인에 들어 있어야 하고, 색인을 만든 주체를 신뢰해야 합니다. 위협 인텔리전스 업무는 매일 이 방식에 기대고 있습니다. 다만 이것은 임의의 MD5 다이제스트에 대해서는 아무것도 말해 주지 않으며, 직접 만든 데이터의 해시에는 결코 도움이 되지 않습니다.
메커니즘 자체는 수상한 변환기 페이지가 쓰는 것과 똑같습니다. 차이는 악성코드 저장소는 이것이 조회라고 밝히고 해당 레코드를 함께 보여 준다는 점입니다.
직접 확인해 보기
같은 입력에서 나온 두 다이제스트가 나란히 바뀌면서도 서로 아무 관계가 없다는 것은, 한 번 직접 돌려 보면 바로 감이 옵니다.
$ printf 'hello' | md5sum
5d41402abc4b2a76b9719d911017c592 -
$ printf 'hello' | sha256sum
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 -
문자 하나만 달라져도 두 출력이 완전히 달라지고, 그 달라지는 방식은 서로 아무런 연관이 없습니다. 같은 텍스트를 MD5 해시 생성기와 SHA-256 생성기에 나란히 붙여넣으면 실시간으로 확인할 수 있고, 실제로 필요한 것이 API 요청 서명을 위한 키 기반 다이제스트라면 HMAC 생성기를 쓰면 됩니다. 세 도구 모두 브라우저 안에서만 동작합니다.
FAQ
MD5를 SHA-256으로 변환할 수 있나요?
아닙니다. MD5 다이제스트에는 원본 입력이 들어 있지 않고, SHA-256은 무언가를 만들어 내려면 그 입력이 필요합니다. 변환해 준다고 주장하는 페이지는 사용자가 넣은 텍스트를 다시 해싱하고 있거나, 미리 계산된 쌍을 모아 둔 데이터베이스에서 값을 조회하고 있을 뿐입니다.
왜 그렇게 많은 사이트가 “MD5 → SHA-256 변환기”를 내세우나요?
사람들이 실제로 입력하는 검색어에서 순위를 잡기 위해서입니다. 막상 들어가 보면 페이지는 원본 텍스트를 요구하거나(그러면 변환이 아니라 재해싱입니다), 쓸모 있는 결과를 전혀 돌려주지 않습니다. 검색어가 사라지지 않는 것은 그 뒤에 깔린 오해가 그만큼 흔하기 때문입니다.
SHA-256을 MD5로 되돌릴 수 있나요?
아닙니다. 방향은 아무 상관이 없습니다. 둘 다 단방향 함수이므로, 원본 입력 없이는 어느 다이제스트도 다른 쪽으로 변환할 수 없습니다. 반대 방향을 해 준다는 도구도 똑같은 조회나 재해싱 수법을 쓰고 있습니다.
MD5가 깨졌다면 되돌릴 수도 있다는 뜻 아닌가요?
아닙니다. MD5의 충돌 저항성이 무너진 것은 2004년이고, 이는 두 입력이 같은 다이제스트를 갖도록 강제할 수 있다는 뜻입니다. 다이제스트를 되돌리는 것은 역상 공격이며, 지금까지 알려진 최선의 방법도 여전히 2^123.4번의 연산이 듭니다. 서명 용도로는 깨졌지만, 여전히 역산은 불가능합니다.
MD5 비밀번호 해시 데이터베이스를 더 안전한 방식으로 어떻게 마이그레이션하나요?
MySQL에서 UPDATE users SET password = SHA2(password, 256) 한 줄로 끝내려는 방식은 틀렸습니다. 해시되는 값이 비밀번호가 아니라 이미 저장된 MD5 다이제스트이기 때문입니다. bcrypt(md5(password))를 저장하고 같은 래퍼를 거쳐 검증하면서, 각 레코드를 다음번 로그인 성공 시점에 업그레이드하십시오. MD5를 SHA-256으로 감싸는 것은 도움이 되지 않습니다. 둘 다 빠른 해시이고, GPU는 어느 쪽이든 똑같이 가혹한 속도로 처리하기 때문입니다.
이중 해싱 결과가 예상과 다르게 나온 이유는 무엇인가요?
MD5 16진수 문자열을 해싱한 결과와 그 값의 원시 16바이트를 해싱한 결과는 서로 다른 SHA-256 출력이 됩니다. 둘 다 유효하며, 단지 입력이 다를 뿐입니다. 규칙을 하나 정해 마이그레이션 스크립트와 로그인 경로에 똑같이 적용하십시오.
레인보우 테이블로 MD5 해시 뒤의 입력을 복구할 수 있나요?
입력에 솔트가 없고 이미 테이블에 들어 있는 경우에만 가능합니다. 실제로는 짧거나 흔한 문자열이라는 뜻입니다. 길고 무작위한 입력은 이 방식으로 복구되지 않으며, 사용자별 솔트를 넣으면 미리 계산해 둔 테이블은 완전히 무력해집니다.
MD5 → SHA-1 변환기는 있나요?
없습니다. MD5에서 SHA-1로 갈 때도 SHA-256과 똑같은 단방향성이 가로막기 때문에, 변환기를 자처하는 페이지는 재해싱 도구이거나 조회 테이블입니다. 원본 입력이 남아 있다면 SHA-1 생성기로 다시 계산하면 되고, 없다면 어떤 도구로도 되지 않습니다.