Web Crypto가 SHA-1을 SHA-512에 제공하지만 MD5 또는 SHA-3는 제공하지 않는 이유

MD5는 어디에 있나요? — 레거시 체크섬 워크플로를 마이그레이션하는 사람의 첫 번째 질문

브라우저의 Web Crypto API는 정확히 4개의 다이제스트 알고리즘(SHA-1, SHA-256, SHA-384 및 SHA-512)을 제공합니다. MD5 또는 SHA-3를 예상하는 ToolAcre SHA 해시 계산기를 찾으면 찾을 수 없습니다. 이러한 특이성은 도구의 제한이 아닙니다. 이는 의도적인 플랫폼 선택을 반영합니다. 이 네 가지가 포함된 이유와 두 가지 인기 있는 대안이 제외된 이유를 이해하면 브라우저 API가 어떻게 설계되었는지에 대해 많은 것을 알 수 있습니다.

모든 주요 브라우저는 보안 출처에 crypto.subtle.digest를 노출합니다. JavaScript가 해당 메소드를 호출하면 플랫폼의 암호화 구현, 즉 보안 샌드박싱 및 성능 최적화로 실행되는 기본 코드로 전달됩니다. 제공되는 다이제스트 알고리즘은 W3C 웹 암호화 작업 그룹에서 기존 보안 표준과의 호환성, 암호화 라이브러리 전반에 걸쳐 사용 가능한 지원, 성숙도 및 웹 플랫폼의 실제 보안 요구 사항과 같은 특정 우선 순위를 두고 선택되었습니다.

SubtleCrypto.digest가 지원하는 네 가지 알고리즘 — SHA-1, SHA-256, SHA-384 및 SHA-512 외 다른 것은 없습니다.

ToolAcre는 DigestBytes에 의해 시행되는 동일한 4개의 식별자인 SHA-1, SHA-256, SHA-384 및 SHA-512를 허용합니다. 인식할 수 없는 이름은 Web Crypto가 호출되기 전에 거부되며, 테스트 스위트는 해당 거부를 확인하기 위해 특별히 MD5를 통과합니다. 따라서 선택기는 표준화된 모든 다이제스트에 대한 조사보다는 테스트된 제품 경계를 설명합니다.

SHA-1 해당 목록에 표시된다고 해서 4개의 동등한 권장 사항이 모두 제공되는 것은 아닙니다. 해당 결과 객체는 깨진 플래그를 전달하고 인터페이스는 레거시 경고를 반복합니다. 나머지 세 개는 사용 가능한 SHA-2 선택 사항입니다. 호환성 도구가 새로운 의존성을 장려하지 않고 이전 값을 재현할 때마다 가용성과 적합성은 별도로 유지되어야 합니다.

MD5는 이 구현 및 Web Crypto에 없습니다. 이 기사는 출처가 없는 표준 근거를 추가하지 않습니다.

MD5는 128비트 다이제스트를 생성하는 암호화 해시 함수로, SHA-256보다 더 짧고 계산 비용이 저렴합니다. 수십 년 동안 이는 체크섬 및 디지털 서명에 대한 표준 선택이었습니다. 그러나 MD5의 충돌 저항은 근본적으로 깨졌습니다. 2004에서 암호 작성자는 실제 충돌(동일한 다이제스트를 사용하는 두 개의 서로 다른 입력)을 시연했으며 알고리즘은 학문적 작업을 통해 완전히 해체되었습니다. 수학적 취약성은 절대적이며 영구적입니다.

W3C Web Crypto 사양은 MD5를 포함하지 않도록 의도적으로 선택했습니다. 이유는 간단합니다. 수백만 명의 브라우저 사용자에게 손상된 알고리즘을 제공하면 레거시 호환성 시나리오에서만 나타나야 하지만 새 애플리케이션에서 해당 알고리즘의 사용이 정상화됩니다. 애플리케이션이 기존 시스템과의 상호 운용성을 위해 실제로 MD5를 필요로 하는 경우 해당 코드는 브라우저가 아닌 요구 사항을 이해하고 감사하는 서버 측 런타임에 속합니다. 손상된 알고리즘에 편리하게 액세스할 수 있게 만들면 새로운 시스템에서 보안에 대한 기대가 높아집니다.

ToolAcre SHA 해시 계산기는 MD5 구현도 제공하지 않습니다. 사용하는 플랫폼 API와 마찬가지로 손상된 알고리즘에 편리하게 액세스할 수 있도록 하는 것을 거부합니다. 애플리케이션이 레거시 Git 시스템 외부에서는 드물게 MD5를 절대적으로 요구하는 경우 구현은 호환성 심이라는 명확한 메모와 함께 자체 코드베이스에 속합니다. 접근성은 기대를 낳고, 깨진 알고리즘은 기대할 가치가 없습니다.

SHA-3은 브라우저 API 및 도구 외부에 있습니다. 채택 내역이 저장소 증거 외부에 있습니다.

SHA-3는 오랜 공개 경쟁 끝에 2015에서 NIST에 의해 표준화되었으며 암호학적으로 견고합니다. 이는 하드웨어에 따라 흥미로운 이론적 속성과 성능 절충점을 제공하는 스폰지라고 하는 SHA-2와 근본적으로 다른 구성을 사용합니다. 최신 시스템에서는 SHA-3이 SHA-256보다 더 빠를 수 있습니다. 그러나 현재 브라우저 플랫폼에서는 이를 공개하지 않으며 이러한 지연은 플랫폼 성숙도 및 채택 속도에 대한 실질적인 결정을 반영합니다.

배송 지연 SHA-3은 현실을 반영합니다. Web Crypto는 웹과 HTTPS에서 가장 광범위하게 사용되는 알고리즘을 포괄하도록 설계되었습니다./TLS. API 최종화에서 SHA-2(256, 384, 512)는 새로운 시스템에 대한 압도적인 합의였으며 SHA-3은 MD5 또는 SHA-1에서 이동하는 것보다 훨씬 느리게 진행됩니다. 대부분의 애플리케이션에는 아직 SHA-3이 필요하지 않습니다. API를 확장하고 모든 브라우저와 플랫폼에서 테스트하는 데 드는 비용은 출시 당시의 수요에 비해 충분하지 않았습니다.

이는 영구적인 거부가 아닙니다. Web Crypto API는 발전할 수 있습니다. SHA-3 채택이 가속화되면 실무 그룹에서 이를 추가할 수 있습니다. 현재 세트는 Web Crypto가 플랫폼의 즉각적인 보안 요구 사항을 충족하는 데 필요한 성숙하고 널리 표준화된 알고리즘을 나타냅니다. 브라우저 API는 안정적이고 신중하게 유지관리되어야 합니다. 광범위한 요구가 있기 전에 서둘러 기능을 추가하면 향후 수년간 유지 관리 부담과 호환성 위험이 발생합니다.

SHA-1이 여전히 존재하는 이유 — 레거시 검증 요구 사항 및 제안과 권장의 차이점

SHA-1은 암호화가 깨졌음에도 불구하고 Web Crypto에 포함되어 있습니다. 이러한 반직관적인 선택은 종종 개발자를 놀라게 합니다. 알고리즘은 160비트 다이제스트를 생성하고 SHA-1에 대한 충돌 공격은 이제 실용적입니다. 동일한 다이제스트를 공유하도록 두 개의 서로 다른 문서를 제작할 수 있습니다. 선택 접두사 충돌을 통해 공격자는 충돌하는 동안 의미 있는 두 개의 문서를 만들 수 있으며, 이로 인해 서명과 인증서가 손상됩니다. 그러나 그것은 플랫폼에 남아 있습니다.

SHA-1는 레거시 호환성이라는 한 가지 필수 이유 때문에 웹 암호화에 남아 있습니다. Git 개체 식별자는 SHA-1을 기반으로 하며 Git 프로젝트가 SHA-256로 전환되는 동안 수백만 개의 기존 저장소, 참조 및 빌드 시스템은 여전히 ​​SHA-1 해시를 방출합니다. 이전 시스템의 TLS 인증서 지문에는 SHA-1 다이제스트가 포함됩니다. 몇 년 전에 HMAC-SHA1 서명을 발행한 API에는 여전히 검증이 필요합니다. 이러한 배포된 시스템을 확인하거나 마이그레이션해야 합니다. 플랫폼에는 필요한 작업을 가능하게 하는 SHA-1이 포함되어 있습니다.

플랫폼 API에는 권장 사항이 아닌 호환성을 위해 존재한다는 점을 명확히 이해하는 SHA-1이 포함되어 있습니다. 브라우저의 UI에는 경고와 함께 SHA-1 라벨이 붙습니다. ToolAcre SHA 해시 계산기는 SHA-1 결과 옆에 "암호화로 손상됨"을 표시하여 이를 사용하는 모든 사람이 레거시 자료로 작업하고 있음을 이해할 수 있도록 합니다. 투명성은 필수적입니다. 사용자는 SHA-1 호환성을 SHA-1 보증으로 착각해서는 안 됩니다.

호환성에 MD5가 필요한 경우 이 도구 외부에서 검토된 구현을 사용하고 호환성을 보안으로 착각하지 마십시오.

Web Crypto의 네 가지 알고리즘은 TLS 암호화 제품군 생태계 및 가장 중요한 보안 표준과 일치합니다. SHA-256은 하위 리소스 무결성 검사, 콘텐츠 주소 지정 및 새로운 보안 시스템에 사용되는 범용 해싱의 현재 기본값입니다. SHA-512은 64비트 하드웨어에서 더 빠르고 더 넓은 다이제스트를 제공합니다. SHA-384은 주로 TLS 암호화 제품군에서 사용되는 것으로 알려져 있습니다.

SHA-1은(는) 누구나 새 시스템을 시작해야 하기 때문이 아니라 상호 운용성을 위해 유지됩니다. 기존 SHA-1 체크섬을 확인하거나, 이전 인증서 지문과 일치하거나, ​​Git 커밋 ID를 재생성하는 경우 ToolAcre의 SHA-1를 사용하여 이를 수행할 수 있습니다. 새로운 시스템을 설계하는 경우 SHA-256이 확실한 선택입니다. 선택한 알고리즘은 보안 모델에 대한 이해를 나타냅니다.

여기서 다루지 않는 내용 — 일반적으로 더 많은 다이제스트 알고리즘을 노출하는 서버 측 런타임

애플리케이션에 정말로 MD5, SHA-3 또는 기타 알고리즘이 필요한 경우 선택은 분명합니다. 해당 코드를 서버측 런타임에 유지하고 최종 결과만 브라우저에 노출하는 것입니다. 브라우저 사용을 위한 암호화 알고리즘의 자체 JavaScript 구현을 제공하지 마십시오. 브라우저의 기본 Web Crypto는 손으로 작성한 JavaScript 기능과 비교할 수 없는 방식으로 더 빠르고 안전하며 감사됩니다. 플랫폼이 필요한 것을 제공할 때 플랫폼에 위임하는 것은 항상 올바른 선택입니다.

이는 "간단한" 알고리즘에도 적용됩니다. 자체 작성한 MD5 구현은 어쨌든 MD5가 손상되었기 때문에 무해해 보일 수 있지만 손상된 알고리즘에는 그라데이션이 없으며 단지 손상되었을 뿐입니다. 하나를 배송하면 애플리케이션 코드에서 암호화를 구현하는 방식이 표준화됩니다. 브라우저는 플랫폼에 필요한 것을 제공합니다. 그것이 제공하는 것을 사용하십시오. 개발자가 미묘함과 엣지 케이스를 과소평가하기 때문에 수동 암호화는 웹 애플리케이션 보안 취약점의 가장 큰 단일 소스입니다.

요약: 제한 사항은 제품의 일부입니다. ToolAcre SHA 해시 계산기는 브라우저가 기본적으로 구현하는 4가지 알고리즘을 제공하고 해당 경계를 문서화합니다.

ToolAcre SHA 해시 계산기는 이 제약 조건을 직접적으로 나타냅니다. 즉, Web Crypto가 제공하는 4가지 알고리즘을 더도 덜도 없이 정확히 볼 수 있습니다. 값을 붙여넣고 "MD5가 필요합니다"라고 생각한다면 의도적인 부재입니다. 필요한 경우 이는 시스템에 신중한 처리가 필요한 레거시 구성 요소가 있다는 신호입니다. 이는 브라우저 유틸리티가 아닌 전문적인 서버 측 마이그레이션 도구의 용도와 정확히 같습니다. 도구가 제공하는 것과 제공하지 않는 것에 대한 정직성은 그 자체로 귀중한 정보입니다.

Web Crypto 설계는 수십 년간의 암호화 관행을 반영합니다. 즉, 표준화되고 감사되며 광범위한 배포에서 입증된 알고리즘입니다. SHA-256 및 SHA-512이 합리적인 기본값입니다. SHA-384는 TLS 계보를 이어갑니다. SHA-1이 있는 이유는 웹에 수년간 확인해야 하는 SHA-1 다이제스트가 있기 때문입니다. MD5가 손상되었고 SHA-3이 아직 플랫폼에 중요하지 않기 때문에 MD5 및 SHA-3가 없습니다.