Web Crypto では SHA-1 ～ SHA-512 が提供され、MD5 や SHA-3 は提供されない理由

MD5 はどこですか? — 従来のチェックサム ワークフローを移行する人からの最初の質問

ブラウザの Web Crypto API には、SHA-1、SHA-256、SHA-384、SHA-512 という 4 つのダイジェスト アルゴリズムが同梱されています。 MD5 または SHA-3 を期待して ToolAcre SHA ハッシュ計算ツールに手を伸ばしても、それらは見つかりません。この特異性はツールの制限ではありません。これは意図的なプラットフォームの選択を反映しています。これら 4 つが含まれた理由と、一般的な 2 つの代替案が除外された理由を理解すると、ブラウザ API がどのように設計されているかについて多くのことがわかります。

すべての主要なブラウザは、安全なオリジンで crypto.subtle.digest を公開します。 JavaScript がそのメソッドを呼び出すと、そのメソッドはプラットフォームの暗号化実装 (セキュリティ サンドボックス化とパフォーマンスの最適化で実行されるネイティブ コード) に渡されます。提供されるダイジェスト アルゴリズムは、既存のセキュリティ標準との互換性、暗号ライブラリ全体での利用可能なサポート、成熟度、Web プラットフォームの実際のセキュリティ ニーズといった特定の優先順位に従って、W3C Web Crypto Working Group によって選択されました。

SubtleCrypto.digest がサポートする 4 つのアルゴリズム — 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 つの同等の推奨事項をすべて提供しているわけではありません。その結果オブジェクトには壊れたフラグが設定されており、インターフェイスは従来の警告を繰り返します。他の 3 つは、利用可能な SHA-2 の選択肢です。互換性ツールが古い値への新たな依存を奨励せずに古い値を再現する場合は常に、可用性と適合性を分離しておく必要があります。

MD5 はこの実装と Web 暗号化には含まれていません。この記事は、出典のない標準の根拠を追加するものではありません

MD5 は、128 ビット ダイジェストを生成する暗号化ハッシュ関数であり、SHA-256 よりも短く、計算コストが低くなります。何十年もの間、これはチェックサムとデジタル署名の標準的な選択肢でした。しかし、MD5 の衝突耐性は根本的に壊れています。 2004 では、暗号学者が実際の衝突 (同じダイジェストを持つ 2 つの異なる入力) を実証し、そのアルゴリズムは学術研究によって完全に解体されました。数学的脆弱性は絶対的かつ永続的です。

W3C Web Crypto 仕様では、MD5 を含めないという意図的な選択が行われています。理由は簡単です。壊れたアルゴリズムを何百万ものブラウザ ユーザーに配布すると、たとえそれが従来の互換性シナリオでのみ表示されるはずであっても、新しいアプリケーションでの使用が正常化されるからです。アプリケーションが古いシステムとの相互運用性のために本当に MD5 を必要とする場合、そのコードはブラウザーではなく、要件が理解および監査されるサーバー側のランタイムに属します。壊れたアルゴリズムに簡単にアクセスできるようにすると、新しいシステムにセキュリティへの期待が生まれます。

ToolAcre SHA ハッシュ計算ツールには MD5 実装も同梱されていません。使用するプラットフォーム API と同様に、壊れたアルゴリズムに簡単にアクセスできるようにすることを拒否します。アプリケーションが MD5 を絶対に必要とする場合 (レガシー Git システム以外ではまれです)、実装は互換性シムであることを明確にして独自のコードベースに属します。アクセシビリティは期待を生み出しますが、壊れたアルゴリズムは期待に値しません。

SHA-3 はブラウザ API とツールの外部にあります。その採用履歴はリポジトリの証拠の外にあります

SHA-3 は、長期にわたる公開競争を経て、NIST によって 2015 として標準化され、暗号的に堅牢です。これは、スポンジと呼ばれる SHA-2 とは根本的に異なる構造を使用しており、ハードウェアに応じて興味深い理論的特性とパフォーマンスのトレードオフを提供します。最新のシステムでは、SHA-3 の方が SHA-256 よりも高速になる可能性があります。しかし、ブラウザ プラットフォームは現在それを公開しておらず、この遅れはプラットフォームの成熟度と導入ペースに関する実際的な決定を反映しています。

SHA-3 の出荷遅延は現実を反映しています。Web Crypto は、Web および 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 に対する衝突攻撃が実用化されています。同じダイジェストを共有するように 2 つの異なるドキュメントを作成できます。選択されたプレフィックスの衝突により、攻撃者は衝突中に両方とも意味のある 2 つのドキュメントを作成することができ、署名と証明書が破壊されます。それでも、それはプラットフォームに残ります。

SHA-1 は、レガシー互換性という 1 つの必要な理由から Web Crypto に残ります。 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 の 4 つのアルゴリズムは、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 実装は無害に見えるかもしれませんが、壊れたアルゴリズムには段階がなく、単に壊れているだけです。これを出荷すると、アプリケーション コードに暗号化を実装する習慣が標準化されます。ブラウザはプラットフォームに必要なものを提供します。それが提供するものを使用してください。開発者が微妙な点やエッジ ケースを過小評価しているため、手作業による暗号化が Web アプリケーションのセキュリティ脆弱性の最大の原因となっています。

要点: 制限は製品の一部です。ToolAcre SHA ハッシュ計算ツールは、ブラウザーがネイティブに実装する 4 つのアルゴリズムを提供し、その境界を文書化します。

ToolAcre SHA ハッシュ計算ツールは、この制約を直接明らかにします。Web Crypto が提供する 4 つのアルゴリズムが、それ以上でもそれ以下でもないことがわかります。値を貼り付けて「MD5 が必要だ」と思った場合、その欠如は意図的です。それが必要な場合、それは慎重な処理が必要なレガシー コンポーネントがシステムにあることを示しています。まさに、ブラウザ ユーティリティではなく、専用のサーバー側移行ツールが必要な種類のコンポーネントです。このツールが提供するものと提供しないものについての正直さは、それ自体が貴重な情報です。

Web Crypto の設計には、数十年にわたる暗号化の実践、つまり標準化され、監査され、広範な導入で実証されたアルゴリズムが反映されています。 SHA-256 および SHA-512 が適切なデフォルトです。 SHA-384 は TLS の系統を継承しています。 SHA-1 が存在するのは、Web に何年も検証する必要がある SHA-1 ダイジェストがあるためです。 MD5 と SHA-3 が存在しないのは、MD5 が壊れており、SHA-3 がプラットフォームにとってまだ重要ではないためです。