ハッシュとチェックサム：CRC32 と MD5 を自分で書く理由

自分で書くしかない二つ

crypto.subtle.digest は SHA-1/256/384/512 を提供し、ビット演算を自分で管理せずに済むほど高速です。しかし CRC32 も MD5 もありません。この二つこそ、ダウンロード検証やアーカイブ形式、分割識別子で最もよく使われます。

そこで CRC32 はテーブル方式にします。256 項目を事前計算し、1 バイトずつ XOR して参照するだけです。数十行で済みます。MD5 は RFC 1321 に従いますが厄介なのはエンディアンです。メッセージのパディングと最終出力はリトルエンディアン、内部状態はビッグエンディアンです。逆に書いてもエラーは出ず、それらしい誤った 16 進文字列が出るだけです。

ファイルを一括で読み込まない

ファイル全体を文字列として読む方法は小さな入力には使えますが、数百メガバイトでは破綻します。正しい形は分割読み込みです。ArrayBuffer の断片を同じハッシュ実例に渡し、最後に一度だけ結果を取り出します。

SHA 系はこの形を標準で支えるので、自作の CRC32 と MD5 も一括処理の関数ではなく、逐次更新できる形で書く必要があります。これは実装を設計する時点で決めるべきことです。

期待値を貼り、比較はツールに任せる

実際の場面はこうです。配布元が公開したチェックサムがあり、ファイルが改変されていないか確認したい。64 桁の 16 進を目で比べるのは退屈で信頼できません。大文字小文字、空白、一桁の欠落は見落とします。

そこで期待値の入力欄を用意します。貼り付ければ、どのアルゴリズムで算出されたものか、あるいはどれも一致しないかを返します。これで検証は目視の作業から明快な結論へ変わります。

ひとつ必要な注意

MD5 と SHA-1 はもはやセキュリティ用途に適しません。衝突のコストが低すぎるためです。ここに残しているのは完全性の確認、つまり転送が壊れていないことの確認であって、署名やパスワード用ではありません。想定する脅威が能動的な攻撃者なら SHA-256 以上を使ってください。

自検による担保

自作の暗号実装には既知のテストベクターが必要です。そうでなければ 32 桁の 16 進を出すことと、正しいことは別の話です。自検スクリプトは標準的なベクターを一つずつ確認します。例えば “abc” の MD5 は 900150983cd24fb0d6963f7d28e17f72 です。これによりリファクタリングで静かに壊れることを防げます。