「ハッシュ値の衝突」（コリジョン）や「データの改ざん」などの対策で、ベストなハッシュ・アルゴリムを判断するために、ハッシュ値の「長さ」や「速度の目安」一覧が欲しい。

ハ ... ... ハッシュ？
... ってか、ハッシュって、そんなにおいしいの？圧縮された暗号とちゃうん？

TL; DR _{^{（今北産業）}}

1. この記事はハッシュ関数の出力結果を桁数ごとに、まとめたものです。

   • ハッシュ関数の各々の「アルゴリズムが最大何文字・・の 16 進数で返してくるか」の事前確認に利用ください。

2. マスター、一番強いヤツをくれ。

   • バランス優先

     • 👉 sha3-512（64 Byte, 128桁, 2020/12/22 現在）

     • OS やプログラム言語間の互換性・強度・速度の一番バランスが取れているハッシュ・アルゴリズムで「強い」ヤツ。使いやすさなら、SHA3-256。

     • 互換性？

       ここでいう互換性とは「大抵どの言語でも標準で・・・実装しているアルゴリズム」のことです。NIST が制定している Secure Hash Algorithm（略して SHA）のうち、SHA-3 シリーズは最新版のアルゴリズムであるため、汎用性がとても高いです。
       最強は SHA3-512 なのですが、現実的で使いやすいのは SHA3-256 でしょうか。
       1 世代前の SHA-2 シリーズであっても、SHA256 や SHA512 であれば目くじらたてる必要はありません。しかし、SHA-2 は 20 年前のアルゴリズムであり、クラウドの演算力やブロックチェーンのマイニング・ファームのハッシング演算力が 10 年で激増していることに留意します。というのも 2 世代前の SHA-1 で「SHA-1 の効率的な衝突方法の論文」が発表されてから Google がそのクラウド演算力を使い実際に衝突例を見つけたこともあり、SHA-1 は廃止されただけでなく、同系統のアルゴリズムである SHA-2 も両手を広げて安全とは言えなくなったからです。
       つまり、SHA-3 は、将来 SHA256 や SHA512 が破られた場合に備えての別系統によるバックアップです。例えば、NIST が長らく実施していた "PQC"（Post-Quantum Cryptography。量子コンピューター演算にも耐性のある暗号アルゴリズム合戦）でも、勝者は内部処理の一部でハッシュ関数に SHA3 も備えています。そのため、SHA256（SHA2-256）や SHA512（SHA2-512）だけでなく SHA3-256/SHA3-512 にも対応しておけよ、というだけです。

     • _{^{注意: SHA-3 のライブラリに本家 libXKCP を使っている場合、脆弱性が発見されているので、修正パッチの当たった最新のものを使ってください。OpenSSL 版をベースにしたライブラリなら大丈夫ですが、やはり最新版を使うのをオススメします。}}

       • SHA-3 ライブラリの脆弱性について

         2022/10/20 に、SHA-3 のオリジナルを作った Keccak チームが提供している libXKCP ライブラリで、バッファオーバーフローの脆弱性が発見されています。（CVE-2022-37454、CWE-680）

         libXKCP の fdc6fef0 のコミットで修正パッチが当たっているので、ライブラリを最新のものにしてください。

         • PHP
           • 7.4.33 以降で対応
           • 8.0.25 以降で対応
           • 8.1.12 以降で対応
         • Python (cPython)
           • 3.11 以降で対応（libXKCP の SHA-3 から OpenSSL の SHA-3 に変更）
         • Debian のパッケージ対応状況
           • CVE-2022-37454 Tracker | Secrurity Tracker @ debian.org

         なお、OpenSSL をベースとしたライブラリには今回の CVE-2022-37454 は問題ありませんが、OpenSSL にもバージョンによって異なる脆弱性があります（CVE-2022-3602、CVE-2022-3786）。

         また、この脆弱性を「SHA-3 に脆弱性があった」と記載しているクリックベイトな記事もありますが、実装方法に問題があっただけで、SHA-3 のアルゴリズム自体に脆弱性が見つかったわけではありません。いずれのライブラリを使うにしても最新のライブラリを使うようにしてください。

         参考文献

         • SHA-3 Buffer Overflow @ Nicky Mouha
         • CVE-2022-37454 @ CVE Report
         • Buffer overflow in sponge queue functions | Security Advisories | XKCP @ GitHub
         • #105 Incorrect integer comparisons and buffer overflows | Issue | XKCP @ GitHub
         • #98517 [CVE-2022-37454] Buffer overflow in the _sha3 module in python versions <= 3.10 | cPython @ GitHub
         • 「XKCP SHA-3」に脆弱性 - 「Python」「PHP」などにも影響 @ Security NEXT
         • PHPにアップデート、複数脆弱性を修正 @ Secrurity NEXT

   • 速度優先

     • 👉 BLAKE3（64 Byte, 128桁, 2021/09/02 現在）
     • OS やプログラム言語間の互換性より「速度優先」の新参ハッシュ・アルゴリズム。
     • 速度優先？

       速度だけを求めると他にもあるのですが、本当に速度だけ・・を求めると沼にハマるので注意しましょう。
       と言うのも、「ハッシュ化しています」「爆速です」と言った途端、セキュリティだけでなく他の OS・アプリ・プログラム言語との互換性といった部分でも比較されるため、選択のバランスが難しいからです。
       例えば、爆速だけどニッチなアルゴリズムを使うと、他のプログラム言語では実装されていなかったり検証しずらかったりすると、悲しいかな、下手すると「爆速だけど信用できない」といったレッテルを貼られたりします。
       有志による速度や強度の測定に SMhasher などもあり、論文や多言語での実装なども考慮しながら、自分の環境での実測値をベースに総合的に判断する必要があります。
       さて、BLAKE3 は、上記 SHA-3 になり損ねたSHA-3選抜ファイナリストの BLAKE2 の後継です。2021/07/25 に v1.0 をリリースしたばかりの新参であるため、大半の OS やライブラリで査読中などにより標準で実装されていないものが多くあります。そのため、本記事の一覧に含めていません。とは言え、BLAKE2 の知名度・認知度から言っても BLAKE3 はメジャーな（公的機関にも採用されうる）アルゴリズムの 1 つと言っていいでしょう。
       強度は SHA3-256（可変長出力においては「SHAKE128」）と同程度と主張（アナウンス）していますが、まぁ爆速です。Go 版だと実測で FNV1 より 6 倍以上速かったです ... まじか。
       ちなみに、セキュリティ目的ではない（暗号学的ハッシュを求めない）のであれば、xxHash の xxHash3 (XXH3) が BLAKE3 以上に圧倒的な速度を誇っているので、そこそこ互換性があり CRC より速くて代替となるハッシュを求めている人にはオススメです。[実装言語]
       もし、OS 間やプログラム言語間の互換性をまったく無視するのであれば rapidhash（wyhash の後継）といった C++ に特化したアルゴリズムもあり、沼にハマること受け合いです。

   • パスワード目的

     • 👉 Argon2 @ Wikipedia（2015 年 PHC 勝者, 可変長, 2021/03/01 現在）

     • パスワード・ハッシュ^[?]の強度で一番強いアルゴリズム
       _{^{（速いとは言ってない）}}

     • NIST で推奨されている PBKDF2 は強くないの？

       NIST の 800-132「パスワードに基づく鍵の導出に関する推奨」 で PBKDF2 が推奨されていることからか、「パスワードの保存に PBKDF2 を使う」ケースが見られます。

       特に OWASP（ Web アプリケーションのセキュリティに関する情報をとりまとめるコミュニテイのプロジェクト）が作成しているチートシート「Password Storage Cheat Sheet」に「FIPS-140 への準拠が必要な場合は、最低でもワークファクター（イテレーション数）が 600,000 以上、内部ハッシュ関数に HMAC-SHA-256 以上を設定した PBKDF2 を使用すること」と書いてあることから、「この設定なら、パスワードの保存に使っていい」と勘違いしちゃうパターンです。確かに、これだけ強く設定すればパスワード保存にも大丈夫な気もしてきますし、そうとも読み取れます。

       しかし、SP 800-132 で言っているのは「あなたのモジュールが、パスワードから鍵を導出する必要があるなら、最低限この設定の PBKDF2 を使わないと FIPS-140 に準拠しているとみなさない」であり、「パスワードの保存に使え」とは、どこにも書いてないのです。言い換えると、たとえパスワード保存に「さいきょうの Argon2id」を利用していても、内部の鍵導出に（上記の最低限設定で）PBKDF2 を使用していない場合は、FIPS-140 に準拠しないと言うことです。

       つまり、鍵の導出に使うことが推奨されているだけで、PBKDF2 は「パスワードの保存」には推奨されていないのです。

       では PBKDF2 と Argon2id の何が違うのかと言うと「ハッシュ値」の利用目的です。PBKDF2は KDF（Key Derivation Function、鍵導出関数、鍵派生関数）に属し、Argon2id は PHF（Password Hash Functions、パスワードハッシュ関数）に属します。

       「KDF」「PHF」は、どちらもハッシュ値を返します。しかし、微妙で重要な意味合いの違いがあります。

       KDF は、配列やキーバリュー型 DB といった、Key（鍵）と Value（値）のセットに必要な Key を、引数から派生（生成）するために使用される関数です。PBKDF はその一例で、主にパスワードから安全な鍵（キー）を導出するために使用される関数です。
       例えば、パスワードに紐づいたデータの保存や、認証などの紐付け目的で鍵（キー）を派生させるために広く採用されている関数です。しかし、PBKDF は主に鍵を導出することが目的であるため、パスワードを安全に保存するためには追加の手順が必要になります。

       一方、「パスワードハッシュ関数」は、パスワードを検証可能なハッシュ値に変換するために使用されます。パスワードハッシュ関数は通常、パスワードの安全な保存に使用され、パスワードの平文を保存することなく、ハッシュ値を比較することで認証を行います。

       パスワードハッシュ関数のうち、Argon2id は、PHC 勝者であるパスワードハッシュ関数です。Argon2id は、パスワードをハッシュ化する際にメモリベースの関数として設計され、高いセキュリティレベルと耐性を持っています。

       総括すると、PBKDF2 は鍵派生のための関数であり、パスワードの保存には適していません。一方、Argon2id は PHC で優勝した安全なパスワードハッシュ関数であり、パスワードの安全な保存に使用することができます。

     • 有名な bcrypt じゃダメ？

       PBKDF はパスワード保存に適していないのはわかったものの、ではパスワード保存の老舗である bcrypt はと言うと、非推奨にはなっていません（2025 年 08 月現在）。

       bcrypt は 1999 年に登場し、20 年以上にわたり実運用されてきた実績があります。また、たくさんのフレームワークやライブラリに標準で組み込まれており、OWASP のチートシートでも Argon2 が使えない旧環境での代替アルゴリズムとして指定されており、「まだ安全に使える」と見なされています。SHA-2 シリーズの SHA256 や SHA512 と同じ扱いと考えて良いでしょう。

       とはいえ、20 年以上前の古い設計であり、CPU のみを使った遅延調整、GPU や ASIC による並列攻撃に弱いとされます。つまり、バイバインがごとく増えていく演算力に対して、異なるアルゴリズムで今のうちから併用して備えるという意味です。

       特に近年、「Harvest now, decrypt later」というステルス遅延型の攻撃が増えています。これは「Collect now, decrypt later」と言い換えるとわかりやすいのですが、いまのうちに暗号やハッシュデータを収集しておき、あとで（時代がきたら）復号するというものです。いまの時点では収集されるだけなので、実害に気づきづらい攻撃です。

3. TS; DR ではハッシュ関数を完全に理解した気になれる基礎知識と応用例が読めます。

   • 読み物です。いささか長いので、ゴロ寝して読んでください。セキュリティ学や暗号学以前の基礎きそ、つまりハッシュ関数の基本中の基本を説明しています。
     読み終わると、ハッシュ使いになった気になり、ブロックチェーン^[?]（台帳式分散データベース）の仕組みの理解、NFT^[?]（分散所有権管理システム）の仕組みが完全に理解できた気になります。さらには IPFS^[?]（分散ファイル・システム）が使える気になります。git（分散バージョン管理システム）が使える人にはおすすめ。

• ハッシュ関数とは： ハッシュ関数の基本・特徴
• なんで長さなの？： ハッシュ関数の応用
• n バイトって HEX 文字列で最大何文字だっけ？：
  • 単純に n を２倍してください。
    _{^{１バイト＝0xFF、例：4バイト＝HEXで8桁＝FF FF FF FF}}
• なに？4DrlX のような短いハッシュ値を作りたい？：
  • ハッシュ値を n 進数に変換して頭の数文字を使うのがいいかも。
• この記事は、「❤︎」（旧 LGTM）が付くたびに、何かしら見直したり、手を加えてスパイラル・アップさせています。そのため適宜内容が変わります。変更通知も送りませんので、ストックくださった方はお暇な時に、また覗きに来てください。

ハッシュ・アルゴリズムとビット長の一覧
（ハッシュ値の長さ一覧）

ハッシュ値の長さ一覧と速度の目安

すべて同じメッセージをハッシュ化したもの（「Hello Qiita!」のハッシュ値）なのに、ハッシュ値の長さ、つまりビット長が同じでも値がまったく異なることに注目ください。

^{_{🐒   各アルゴリズムの PHP 7.2.6 での計算速度も記載していますが、環境だけでなく PHP のバージョンによってかなり速度が異なります。速度は目安程度にご利用ください。まずは強いアルゴリズムで組んでから、「推測するな、測定せよ」の精神でご自分の環境に最適化することをお勧めします。
なお、SHA-3 に含まれる SHAKE256 などの可変長のアルゴリズム、および SHA-3 の最終選考まで残った BLAKE2 や、その後続で爆速と噂の BLAKE3 は、まだライブラリが枯れて（OS やプログラム言語で浸透）していないため含めていません。}}

8 桁のハッシュ値

16 桁のハッシュ値

32 桁のハッシュ値

40 桁のハッシュ値

48 桁のハッシュ値

56 桁のハッシュ値

64 桁のハッシュ値

80 桁のハッシュ値

96 桁のハッシュ値

128 桁のハッシュ値

TS; DR _{^{最速のDBキー検索を求めて with SQLite3}}

ハッシュ値の衝突は別のアルゴリズムでは衝突しない _{^{（限りなく）}}

// 値が微妙に異なる $a と $b
$a = 'xxxxxxxxx..1..xxxxxxxxx'; // 長ったらしい文字列 a
$b = 'xxxxxxxxx..0..xxxxxxxxx'; // 長ったらしい文字列 b

$result_sha1 = ( hash('sha1', $a) === hash('sha1', $b) );
$result_md5  = ( hash('md5',  $a) === hash('md5',  $b) );

// $result_sha1 --> true, 偶然にも衝突が発生！
// $result_md5  --> false, アルゴリズムが異なると衝突しない（可能性が高い）

古くからダウンロード・ページなどでファイルの改ざんや破損がないかを比べるのに使われている「ハッシュ関数」。

身近なところでは、いつもお世話になっているパッケージマネージャーのパッケージ管理、アクセス・トークンの作成や、みんな大好き Git のコミットID が有名ですが、データベース（以下 DB）のクラスタリングや負荷分散などにも使われています。

Linux のニッチで老舗のパッケージマネージャーである Nix では、ハッシュ値を全面的に使うことで依存関係を徹底的に管理しています。最近、頭角を現している Linux の異端児 NixOS は、その仕組みを OS レベルで使う（カーネル含む全てのシステム・ファイルをハッシュ値ベースで管理し、シンボリック・リンクを貼り替える）ことで、異なるバージョンのテストやトライ＆エラーをしやすくしています。

また、後述する IPFS、ブロックチェーンや、そのマッシュアップで新型コロナの頃に話題になった NFT などでは要かなめの関数とも言えるなど、ハッシュ関数は、今後もさまざまな場面で活躍が期待される関数です。

この記事では、「ハッシュ関数の基本と基礎知識」、そして「ハッシュ関数を活用した SQLite3 の 1 つのアイデア」をシェアしたいと思います。

ハッシュ関数を完全に理解した気になるコマケーこと

ハッシュ関数の基本と特徴

先に、一言で恐れずに言うなら「ハッシュ値・はデータの指紋」です。

つまり「データのハッシュ化」と言うのは「データから情報の指紋を採取すること」みたいなもので、「ハッシュ値」とは採取した指紋情報のことであり、データの暗号化でも圧縮でもないのです。

もちろん、データなので指を持ちません。そのため「指紋」よりは、ハッシュ値はデータの「情報紋」と言ってもいいかもしれません。

人間の指紋が、特定の個人を識別するために使えるように、データの指紋（ハッシュ値）も特定のデータ識別に使えます。

符号化された情報、つまりコンピューターが認識できるデータ（0 と 1 のビットで表現できる情報）であればテキストであろうが、画像であろうが、プログラムであろうが、そのデータからハッシュ値を得ることができます。

人間の指紋は、それ自体からは直接本人を特定できませんし、個人情報を持ちません。しかし、本人の指紋と「比較」したり「対応表」さえあれば、誰の指紋であるか特定できます。そして、そこから DB で個人情報と紐づけることができます。とは言え、本人を特定できたとしても指紋からは本人を復元（クローンを作成）できません。

ハッシュ値も似ています。ハッシュ値だけでは元の値はわかりませんが、ハッシュ値を比較したり、対応表さえあれば元の値を特定できます。また、それをもとに（キーとして）DB に紐づけることもできます。さらに、ハッシュ値を知っていても、ハッシュ値そのものからは元の値を復元できません。

「復元できない」というのは、逆算できない・計算で割り出せないということです。例えば「割り算の余り」（剰余）からは、元の値がわからないのと似ています。

$max = 100;     // IDの長さ（最大値は99。∴ 2桁表示で 00 〜 99 の固定長）
$message = 123; // メッセージを数値化したもの（文字コードなど）
$hash = $message % $max; // 123 を 100 で割った余り（必ず 0 〜 99 の範囲）
printf("%02s", $hash);   // 23 <-- 余りが 23 になる組み合わせは無限にあるため
                         //        message を見つけるには行動学的なアプローチ
                         //        が必要になる

• message が、どんな値でも2桁のIDになる例をオンラインで見る @ paiza.io

そして、同じ指紋を持つ 2 人は必ず 1 ペア以上いる（0 %ではない）ように、異なるデータなのに同じ指紋（ハッシュ値）を持つデータは必ず作れます。_{^{（簡単とは言ってない）}}

先の例で言うと、メッセージが異なっても同じ余りになるようなイメージです。

$secret = 100;

$message = 123;
print_r($message % $secret); // 123 mod 100 = 23

$message = 323;
print_r($message % $secret); // 323 mod 100 = 23

もちろん、実際には、こんな簡単な式は使われません。

しかし、とてつもなく弱いながらも関数化すれば立派な「ハッシュ関数」です。ただ、実用には耐えない「アルゴリズム」と「ハッシュ値の長さ」の、なんちゃってハッシュ関数である、というだけです。

つまり、異なるデータが同じ「データの指紋」を持つ確率（識別の精度）が、内部のアルゴリズムやハッシュ値の長さに依存する、この「謎の箱」がハッシュ関数です。

では、ハッシュ関数の基本を「正しく」知ろうと Wikipedia を開くも、何を言っているのかわかりません。

• ハッシュ関数 @ Wikipedia

これは法律や音楽理論や機械学習などのドキュメントと同じように、「同じプロトコルの人（言っていることがわかる人）向けのドキュメント」だからです。

例えば、「変数」や「配列」と言う用語がわからないのにソート・アルゴリズムの説明を覗きに行ったり、メモリアドレスやポインタが理解できていないのに高速化ドキュメントを読んだり、ビットや XOR がわからないのに TCP や JPEG の仕様書を覗くようなものです。

もしくは「デスクトップを右クリックしてプロパティを開いてください」と説明したら、「日本語でおk」と相手がブチキレたことはないでしょうか。同じようなものです。

つまり、ハッシュ関数を正しく知ろうとするとプログラミングの基礎だけでなく「数学」や「暗号学」の基礎知識も必要なのです。そして端的に伝えようとすると、ある程度の基礎知識を相手に求めることになるものなのです。

この記事は、ゴロ寝読みでもいいので、一通り読んでから、再度 Wikipedia の記事を読み直してみてると「（読める ... 読めるぞ）」となることを期待しています。

学問こわい（暗号学・数学こわい）

さて「数学や暗号学の基礎知識も必要」とは言ったものの、暗号学の世界は調べれば調べるほど「暗号化・復号」といった世間一般が思うことを超え、いまや「暗号＝セキュリティ」と同義なんだなと痛感します。

そして（数学含む）基礎知識がない人からの「本当に安全なのか」「なぜ安全と言えるのだ」と言った質問には、数式で証明して見せるしかありません。言葉で説明すると、今度は言葉が独りひとり歩きするといった機械学習のエンジニアの方と話している時と似たジレンマを垣間見ます。

言葉の独り歩きと言えば、機械学習のディープラーニング系の話題で「研究者も、なぜそうなるのかわからない」と報道されるのを目にしたことがあると思います。そのため「作ってる本人たちすら理解できない謎の技術」的に思われがちです。

しかし、「わからない」というのは「仕組みはわかっているが、キチガイじみたと言うより、天文学的な組み合わせのパターンを機械にさせているため、なぜその組み合わせにたどり着いたのかがわからない」という略なのです。理解していないわけではないのです。

そして「では、仕組みを素人にもわかるように説明せよ。三行で。」みたいな、仕組み（理論や理屈）を理解する気もない、結果だけが欲しいせっかちさんが言うものだから、「なんかわからんけど、すごい」という認知と、AI という言葉が一人歩きして、世間との用語の乖離かいりに悩んでいるそうです。

「AI が〜 AI が〜」と騒ぐのは、機械学習の学者からすると「『なんか知らんけど、時代らしい』というだけで付けた、電気ブランやデジタル・パーマみたいなもんが溢れかえっている」らしいです。

まぁ、確かに時代ではあるのですが、ぶっちゃけ 👌資金 がないと、まともな研究やモデル作成はできません。そのため流行ってくれないと予算も出ないし、説明した（正した）ところで「動くものだけで、仕組みに興味がない相手」に誤解を解くための時間を割くのも無駄と言うのが現状らしいです。

我々プログラマーの世界で言えば、「デジタル化」は「符号化であって、電子化のことではない」と思いつつも「デジタル化＝電子化」という世間の認知に流されないといけない歯痒さに似ています。もしくは「（えぇぇ。それはクラウドとチャうヤろ）」といった感じでしょうか。

さて、暗号学の世界も我々のようなパンピーが解釈した内容が微妙に間違ったまま広まっているため、動くものだけで仕組みには興味がない相手に、基礎から教えたり間違いを正す時間を割くのも無駄と感じるようです。

偉そうにゆうて、筆者も数学や暗号学に強いわけではありません。

しかも、エンジニアと言うよりは猿人に近いのえんじんにnearなので、1 つの公式より 500 文字のソースコードを見せてもらった方が理解できるのです。

そこで、bash などを触ったり、自分で何かしらのプログラム言語で俺様関数を作ったことがあればわかるプログラマー的な表現方法で「知っておいた方が良いハッシュの基礎知識」を説明したいと思います。

なお、この記事にはサンプル・プログラムはあるものの、計算式やアルゴリズムの詳細はありません。また、セキュリティーの記事でもありません。むしろ暗号学やセキュリティー以前・・の基礎知識レベルです。「割り算の余り」や「変数」が理解できていれば十分です。

あくまでも筆者が考える、実動作するものを通して理解する「ハッシュ関数の基礎きそ概論がいろん」的なものです。そのため、丁寧に説明しているつもりですが、いささかくどい・・・部分があります。

ジャンクフード的な記事ですが、自分なりに「ハッシュ関数が好きになる話題や実例」を、てんこ盛りにしていますので、ゴロ寝でもしながらスマホでお読みください。

この記事では、さまざまな用語と、その概要を説明しています。そして、それらの用語がつながって（点と点が線になって）行くさま・・を楽しんでいただければと思います。

また、興味のあるキーワードが出て来たら自分なりに掘り下げて、より正確なものに堀り下げて欲しいと思います。キーワードの概要を理解した上で各種文献をご覧になると、より理解度が高まった、そんな記事になるといいなと思います。

そして間違いを見つけたら、戻ってきて、こっそりコメント欄に書いていただけると嬉しいです。

また、この記事は「❤︎（旧 LGTM）」が付くたび、その時折で得ている知識や間違いを整理するつもりで更新・修正しています。書き出さないと理解できないサガなので、1 つの情報として気軽にお読みください。

「ハッシュ」の意味と「ハッシュ関数」の定義

さて、ハッシュ関数の説明の前に「ハッシュ」の意味と、この記事における「ハッシュ関数」の定義をしないといけません。

というのも、後述しますが一般的に「ハッシュ関数」という言葉は「暗号学的ハッシュ関数」を暗あんに指していることが多いからです。

そのため「ハッシュ関数のアルゴリズムとして CRC を含めるのは違うんジャマイカ^🔈」と言う方もいると思います。

鋭い。

確かに、CRC はチェック・サムの親戚みたいなものだし、正しくは「ジャメイカ^🔈」です。

しかし、それに固執しすぎるとセキュリティにばかり目が行ってしまい、「ハッシュ」の用語の理解だけでなく、「ハッシュ関数」の利用方法を狭めてしまいます。

特に、「データの類似性」をハッシュ値にする「知覚ハッシュ」（Perceptual Hash）の理解の妨げや、機械学習において「ハッシュ化してトークンを作成する」と言われ「機械学習に暗号が使われている」といった誤解にも繋がりかねません。

「ハッシュ」とは何か

myArray["foo"] = "bar"; などの連想配列の「ハッシュ・テーブル」や、JSON オブジェクトなどの「ハッシュ」（添字配列）と聞いて、「（ハッシュって何だろう）」と調べたら、やたら暗号や数学の話しが出てきて、そっ閉じされた方も多いと思います。

それでは「ハッシュ」とは何でしょう。

ハッシュ関数の「ハッシュ」は「hash」と書き、単純に日本語に訳すと「ごた混ぜ」「細コマ切れ」「台無しにする」などの意味があります。

しかし、その語源を辿ると面白いルーツがわかります。

美術の古典技法で「hatch」という平行線で描画する技法があり、フランス語の「hach^🔈」から来ています。日本の漫画などでもペン画の基本となっている技法ですね。

ハッチング技法の例（Wikipedia 「ハッチング」より）

そこから英国イギリス英語では平行線で構成された「井いの字」や「二にの字」のような状態のものを hatch もしくは hash と呼ぶようになりました。潜水艦や宇宙船の「ハッチを開ける」などのハッチも「井いの字型の出入り口」であったことから来ています。

他にも、肉やジャガイモなどを、縦横に井いの字カットしていき、細切れになったものを「hashed 〜（ハッシュドなんとか）」と呼ぶのも同様の語源です。

そして英国では電話の「＃」キーを「ハッシュ・キー」と呼ぶようになりました。これが現在の「ハッシュ・タグ」（ハッシュ記号 ＃ によるタグ付け）の語源です。

さて、閑話休題。

転じて データをコマ切れにして、それ単体では全体がわからないものをコンピュータの世界では「ハッシュ」と呼びます。

先に、「ハッシュ化してトークンを作成する」という機械学習の表現があることに触れました。具体的には、データ（例えばテキスト文）をコマ切れにして、各々をトークンと呼び、トークンには ID が振られます（トークンとは、そこでしか利用できない発行物を指し、ここでは、このデータでしか意味をなさない ID です）。

このコマ切れにすることを機械学習でハッシュ化と言います。

他にも、Javascript などの Hash map や、Redis などの hash といった、どうみても連想配列か JSON のオブジェクトにしか見えないものを「ハッシュ」と呼んでいるのも、データ全体を細分化したものだからです。

上記データの Redis におけるハッシュ（1 件のデータ。行のこと）。

しかし、この程度の細分化では個々のデータを寄せ集めれば元の形に戻ってしまいます。角切りステーキのようなイメージです。ハンバーグのミンチ肉のように、復元ができないレベルまで分割して都合のいいサイズで使いたい場合に使われるのが「ハッシュ関数」です。

「ハッシュ関数」の定義

データをコマ切れにするなど、「それ単体では全体がわからないデータにすることをハッシュと呼ぶ」ことはわかりました。

そして、ハッシュ・マップなどは寄せ集めれば全体が見えてしまうので、そもそも元の形に復元ができないレベルまで細分化（ミンチ状態に）して、都合のいいサイズにしたい時に使うのがハッシュ関数ということもわかりました。

以上を踏まえて、この記事における「ハッシュ関数」の用語の定義をしたいと思います。

A hash function is any function that can be used to map data of arbitrary size to fixed-size values.

（Hash Function @ Wikipedia より）

【筆者訳】
ハッシュ関数とは、任意のサイズのデータを固定サイズの値にマッピングするために使用できる関数全般のことを言います。

つまり、どのような内部処理の考え方アルゴリズムの関数であっても「その関数を通すと固定長のデータで返ってくる関数」を、この記事ではハッシュ関数と呼びます。広義（広い意味）でのハッシュ関数ですね。

「ハッシュ関数」とは何か

何はともあれハッシュ関数は「任意のデータを渡すと『ハッシュ値』と呼ばれる値が返ってくる関数のこと」です。

... ... ... まぁ、そうですよね。

でも「ただの関数である」という認識は意外に重要なのです。

機械学習などで「ニューラル・ネットワーク」とか見聞きする際、「○」がたくさんの線でつながっている図を見て、怖いと感じた方もいると思います。

実は、あの「○」って関数やメソッド（クラス関数）のことなんです。

そして関数の出力を、別の関数の引数に「配列で渡している」のが「線」なんです。

しかも「○」の関数は「引数に重みを付けて足し算してフィルターにかけるだけ」といった「単細胞かよっ！」と言いたくなるような単純な処理をするだけだったりします。

そう考えながら見ると単純です_{^{（簡単とは言ってない）}}。

「ハッシュ関数」も、なんだかんだ言っても結局のところ「ただの関数」なのです。

「函数」つまり「引数が同じなら期待する値が出てくる謎の函はこ」です。そして「ハッシュ値なる謎の値」が戻り値であると言うだけです。（「ハッシュ値」については後述します）

ほとんどのプログラム言語で「ハッシュ関数」は実装されていますが、使用できるアルゴリズム函の中身は環境によって異なります。標準ライブラリ（最初から同梱されているモジュールなど）に含まれているかに依存するからです。

「ハッシュ値」とは何か

さて、ハッシュ関数の戻り値である「ハッシュ値とは何か」の前に、以下の "beef" および "beef1" という文字列をハッシュ値にした例をご覧ください（一見、ランダム関数のようにも思えますが違いは後述します）。

本記事で使用する言語は、bash と PHP です。コマンドが 1 行でおさまると言うだけで選びました。どちらの言語も知らなくても、やっていることは同じなので気楽に構えてください。文字列を関数に渡して出力しているだけです。プログラムの文法などは深く考えずに「単純に何をしているか」に気付けば十分です。

bash は openssl コマンド、PHP では hash() 関数を使ってハッシュ化しています。また、利用するアルゴリズムは md5 と sha512 です。

ポイントは、bash php に限らず、どのプログラム言語を使っても以下の 3 つは同じことに注目です。

1. 数値（16 進数）の文字列で返ってくる。
2. アルゴリズムと引数が同じ場合は結果も変わらない。
3. 塩を 1 足すだけで結果が大きく変わる。

ハッシュド・ビーフの例

$ # 粗挽き牛ミンチ
$ echo -n 'beef' | openssl md5
34902903de8d4fee8e6afe868982f0dd

$ # 粗挽き牛ミンチ
$ echo -n 'beef' | openssl md5
34902903de8d4fee8e6afe868982f0dd

$ # 粗挽き牛ミンチ（Bash）
$ echo -n 'beef' | openssl md5
34902903de8d4fee8e6afe868982f0dd

$ # 粗挽き牛ミンチ（PHP）
$ php --run 'echo hash("md5", "beef");'
34902903de8d4fee8e6afe868982f0dd

$ # ハッシュド・ポテト
$ echo -n 'poteto' | openssl md5
147f31c730caa77f8a3440e549264a2e

$ # 角切りトマト
$ echo -n 'tomato' | openssl md5
006f87892f47ef9aa60fa5ed01a440fb

$ # 粗挽き牛ミンチ ＋ 1g の塩入り（beef1）
$ salt=1; echo -n 'beef'$salt | openssl md5
30017279d6a5bac241e764eeed261dd8

$ # 粗挽き牛ミンチ ＋ 1g の塩入り（コックが違っても同じレシピなら同じ味）
$ php -r '$salt=1; echo hash("md5", "beef" . $salt);'
30017279d6a5bac241e764eeed261dd8

$ # 絹ごし牛ミンチ
$ echo -n 'beef' | openssl sha512
8cd8bb0cef938ef9cd054c2c2cb965e83310ab5c197cb5fc8f35892a44c1a028bac9e1bcd6248580fa2739cc96074885ea3ee116ef35c2d8f6124270aeff50b7

$ # 絹ごし牛ミンチ（コマンドの言語が違っても同じアルゴリズムと引数なら同じミンチ肉）
$ php -r 'echo hash("sha512", "beef");'
8cd8bb0cef938ef9cd054c2c2cb965e83310ab5c197cb5fc8f35892a44c1a028bac9e1bcd6248580fa2739cc96074885ea3ee116ef35c2d8f6124270aeff50b7

$ # 絹ごし牛ミンチ ＋ 1g の塩入り
$ salt=1; echo -n 'beef'$salt | openssl sha512
a528829f370819123ad3fb04d8066b77ec79ce6eddad07e5b2c925bbd9b2e699e73428d23315875c29b45500b8c767262cf5546e33974e4f7a6102abd1bb045e

$ # 絹ごし牛ミンチ ＋ 1g の塩入り（コックが違っても同じレシピなら同じ味）
$ php -r '$salt=1; echo hash("sha512", "beef" . $salt);'
a528829f370819123ad3fb04d8066b77ec79ce6eddad07e5b2c925bbd9b2e699e73428d23315875c29b45500b8c767262cf5546e33974e4f7a6102abd1bb045e

• オンラインで動作をみる (PHP, Bash, Go, Python3) @ paiza.IO

Get-FileHash [オプション] <ファイルのパス>

# 使用例
Get-FileHash -Algorithm SHA512 foo.pdf

PS C:\Users\KEINOS\OneDrive\Desktop> # 改行なしで "beef" のテキストを作成
PS C:\Users\KEINOS\OneDrive\Desktop> "beef" | Out-File beef.txt
PS C:\Users\KEINOS\OneDrive\Desktop> Get-FileHash -Algorithm MD5 ./beef.txt

Algorithm      Hash                                 Path
---------      ----                                 ----
MD5            34902903DE8D4FEE8E6AFE868982F0DD     C:\Users\KEINOS\OneDrive\Desktop

PS C:\Users\KEINOS\OneDrive\Desktop> # スクリプトの中身
PS C:\Users\KEINOS\OneDrive\Desktop> get-content ./beef.ps1
$stringAsStream = [System.IO.MemoryStream]::new()
$writer = [System.IO.StreamWriter]::new($stringAsStream)
$writer.write("beef")
$writer.Flush()
$stringAsStream.Position = 0
Get-FileHash -InputStream $stringAsStream -Algorithm MD5 | Select-Object Hash

PS C:\Users\KEINOS\OneDrive\Desktop>　# スクリプトの実行
PS C:\Users\KEINOS\OneDrive\Desktop> . ./beef.ps1

Hash
----
34902903DE8D4FEE8E6AFE868982F0DD

PS C:\Users\KEINOS\OneDrive\Desktop> $PSVersion::PSVersion

Major  Minor  Patch  PreReleaseLavel  BuildLabel
-----  -----  -----  ---------------  ----------
7      4      1

さて、上記を見ると beef の原型はありませんが、ハッシュ値の対応表があれば、元は beef もしくは beef1 であることは確認できそうです。

ハッシュしたてのビーフはミミズにしか見えませんが、成分表（？）上は同じでも「原型を留めていない状態を数値の文字列にした値」がハッシュ値です。

非可逆な感じは、「覆水盆に返らず」でも「水である」ことはわかるようなイメージでしょうか。

とは言え、ハッシュ値は「値」とあるように数値です。しかし、10 進数の値のままだと人間（エンジニア）が扱いづらいので短くするため、一般的に 16 進数の「数値の文字列」で返してきます。ハッシュ関数のオプションによっては文字列型でなく、バイナリ（バイトデータ型）のまま取得できるものもありますが、いずれにしても「数値として認識できる値」で返ってきます。

そして、どのようにミンチ（ハッシュ）にするかが「アルゴリズム」になります。

カードをシャッフルするかのように何度も XOR をする物もあれば、データを 1 バイトずつ読み込みながらゴニョゴニョしたりと、どのアルゴリズムも使用目的や思想によって設計が異なります。

暗号学的ハッシュ関数とチェックサム的ハッシュ関数

ハッシュ関数の戻り値である「ハッシュ値」を生成するには、本記事の一覧で紹介しているように、色々なアルゴリズムがあります。

各々異なった思想や目的で設計されていますが、いずれのアルゴリズムでも「引数が同じであれば戻り値も同じ」「どんな長さのデータでも固定長のデータにする関数」という点は変わりません（例え演算結果が 1 と短くても、最大値は決まっているため「パディング」と言って、頭をゼロで埋めて固定長にします。それに輪を掛けて、SHA-3 の SHAKE256 のように任意の長さで取得できるアルゴリズム、つまり可変長のアルゴリズムもありますが、引数が同じであれば同じ値が返ってきます）。

「ハッシュ関数」の種類

ハッシュ関数には大きく 2 つの種類があります。

暗号学的ハッシュ関数と、それ以外です。

ハッシュ関数によっては、暗号化にも使われている考え方アルゴリズムを利用したものがあります。これを「暗号学的ハッシュ関数」と呼びます。恐れずに言うと「セキュリティー目的で使われるハッシュ関数のこと」です。

先述しましたが、ハッシュ関数には以下の 2 つの特徴があります。

同じ結果になる

アルゴリズムと引数が同じ場合は、同じハッシュ値が返ってくる。

同じ長さの値になる

ハッシュ値は固定長の数値で返ってくる（一般的に n 桁の HEX 文字列）※1

そして「暗号学的ハッシュ関数」の場合は、これに輪をかけてさらに大きな 3 つの特徴が加わります。

同じハッシュ値にならない

異なる引数を、同じハッシュ値にするのは限りなく難しい。

逆算ができない

ハッシュ値から元の値（引数の値）は計算式による算出ができない。※2

予測が困難である

入力の規則性に対して出力に規則性があってはならず、ハッシュ値から元の値の予測は難しい。※2

異なる値なのに、ハッシュ化すると同じ値になることを「衝突」（コリジョン）と言います。

しかし、同じ衝突でも「あるハッシュ値と同じハッシュ値になる値を探す」のと「同じハッシュ値になる異なる 2 つの値を探す」のでは種類が違います。

「自分と同じ指紋の人を探す」のと「同じ指紋を持つ 2 人を探す」のでは確認する数が違うのと同じです。研究する上で、これらの違いは重要なため、専門家同士が迅速に疎通できるように各々に専門用語が付いているので Wikipedia や専門記事を読んでも難しく感じるのです。

暗号学的ハッシュ関数について、セキュリティ（暗号学）専門の方の説明を聞いても、わかるようでわからない説明に感じます。「... ... 美学」と説明されるような小難しさです。

「なぜ小難しい言い方をするのだろう」と思い、備忘録として、この記事を書き始めたわけですが、単純に「（その業界の）勉強不足」という語彙力のなさなのでした。とほほ。

ランダム関数とハッシュ関数

さて、ハッシュ関数に触れ始めるとランダム関数との違いが気になってきます。

ハッシュ関数とランダム関数は、どちらも戻り値の予測が難しいゴタ混ぜな数値を返します。しかも、ランダム関数（擬似乱数）も、シード値が同じ場合は「毎回同じ結果になる」のです。

ランダム関数は、同じ値になる戻り値を「均等にランダムに返そうとする」ことが目的です。つまり、出力結果に偏りかたよりがないようにランダムに値を出力しようとします。そのため、ランダム性の性能は、OS やライブラリやハードウェアに依存するため、シード値が同じでも、すべての環境で同じ値が返ってくる保証がないのです。

反面、ハッシュ関数の場合は「アルゴリズムと引数が同じなら、どの環境でも毎回同じ結果になる」という点がランダム関数と異なります。

さらに、ハッシュ関数の場合（特に暗号学的ハッシュ関数）は、「入力値が異なるなら、なるべく同じ値の戻り値にならないように返そうとする」点も異なります。

暗号化とハッシュ化

さて、「暗号学的ハッシュ関数」と言われて「暗号学・的？暗号的でなく？」と思った方も多いと思います。

これは、暗号学の考え方を取り入れた、セキュリティ用途に使われるハッシュ関数だからです。

「暗号学的ハッシュ関数」は後から出てきたのですが、現在は他を凌駕りょうがし、ハッシュ関数と言えば暗号学的ハッシュ関数を暗黙的に指すことも多くあります。

ハッシュ関数は「暗号の世界」でも、とてもよく使われる関数で、暗号化する際にも内部でよく使われます。

そのためか、ハッシュ関数を「データを暗号化する関数のひとつ」のように説明しているブログもありますが、違います。厳密には「データの暗号化に関係する関数のひとつ」です。ハッシュ関数自体は暗号化をするものではありません（後述しますが、関連はあります）。

確かに、元データとハッシュ値の対応表を別途用意していれば、対応表を暗号の解読コード表としても使えるため「暗号用途」には使えます。

しかし、暗号は「可逆」、つまり元に戻せる（復号できる）とわかっているから暗号と呼ばれます。

反対にハッシュ関数は「非可逆」、つまり「元には戻せないことが特徴」であるため、ハッシュ化は暗号化ではありません。

くどいのですが、この違いは意外に重要なのです。

と言うのも、ハッシュ関数を知らないし興味もない相手に説明するのが面倒たいへんなため「暗号の一種です」と言ってしまうものだから「ハッシュ値を復号したい」という人が後を断ちません。「ハッシュ化」=「暗号化 + 圧縮」と勘違いさせてしまうパターンです。

これは、「アーカイブ」を「圧縮」と説明されるものだから「tar でアーカイブしたのに、サイズが小さくならない」と勘違いするような、小さなことかもしれません。しかし、そのようなクレームを入れる人は「ハッシュ値から復号して欲しい」と要望するのです。

また、「暗号学的ハッシュ関数」を説明する時に「暗号学的な特性をもたなければいけない」という言葉からも誤解が生まれているようです。

「（暗号の特性ということは復号できるんだな）」と。

できません。

おそらく、大半のハッシュ関数初心者が勘違いすることではないでしょうか。かく言う私もそうでした。

ここで重要な用語の認識があります。「暗号」です。

と言うのも、先に「暗号は復号できる（元に戻せる）とわかっているから暗号と呼ばれます」と言いました。実は、これは「パソコン」を「計算機」と言ってしまうくらいの語弊があります。

現在「暗号」と付くものは「セキュリティ」と同義です。どちらも「何かを他者から守るもの」と考えれば、しっくりくると思います。

つまり、暗号化・復号だけを暗号と呼ぶのではなく、暗号学を駆使したセキュリティ技術も「暗号」と呼ばれます。

例えば、後述するビットコインなどのハッシュ値の塊かたまりみたいなものでも「暗号資産」と呼ぶのも最さいたる例です。

「暗号資産」と言うのは「暗号化された資産」という意味ではなく「暗号学でセキュリティが強化・保護された資産」という意味なのです。ゼロ知識証明などの最先端の暗号技術が駆使されているのです。

このように、セキュリティに関係したハッシュ関数の使い方も広義の意味で「暗号」の一部だったりします。

そのため、この「現在の暗号の常識」を認識している人が言う「ハッシュ化は暗号の一種です」というのは、実は間違っていないのです。問題は、その常識を認識していない人にも同じように説明してしまうためなのです。

英語であれば cipher、encryption、cryptography は違うものなのですが、日本語に翻訳されるものはすべて「暗号」や「暗号化」と翻訳されるのが問題かもしれません。日本語難しい。

日本語が難しいと言えば、翻訳の問題も「ハッシュ関数が暗号の一種という誤解」に関係があると思います。

暗号の論文をわからないながらも読むと "〜 by one-way encryption using hash ..." という言い方が多く出てきます。

丁寧に訳すと「... の、逆算による復号が難しい暗号化を行うためにハッシュ値で〜する」という意味です。

しかし、基本がわかっている人には長ったらしい説明であるため「一方向暗号をハッシュで行う」みたいに訳してしまうのだと思います。

後述する「一方向性関数」を理解して、じっくりと咀嚼そしゃくすれば訳は間違ってはいないとわかるのですが、パッと「一方向暗号をハッシュで行う」と言われると「ハッシュ関数で一方向に暗号化する」と捉えてしまいそうです（ました）。

また、暗号学の世界では、2 つの固定長のデータを 1 つの非可逆な固定長データとして出力する関数を「One-way compression function」（一方向性圧縮関数）と呼びます。

「非可逆な固定長データにする」という点から、これらの関数を「hash function」とも呼ぶことがあるため、「暗号化＋圧縮＝ハッシュ値」と誤解のある説明になりがちなのだと思います。

さて、以上を踏まえると「暗号学的ハッシュ関数」が意味することは「セキュリティ目的で使われるハッシュ関数」と言えます。

とは言っても、以下の条件に「暗号でも使われる考え方」（アルゴリズム）を利用しているハッシュ関数というだけのことです（重要なのですが）。

• 「A → （処理） → B」としたとき
  1. 「B から A がバレてはいけない」
  2. 「C から B が作成できてはいけない」

このような「片方向の処理は簡単だが、逆方向は難しい」系の関数（A → B は簡単だが B → A は難しい値を返すもの）を One-Way Function一方向性関数 と言います。

「一方向性関数」自体は概念的なもので、具体的にこれ・・というものは存在しません。

例えば「大きな素数を掛け算して自然数を返す」関数などが近いものです。なぜなら、逆の「（大きな値の）自然数から素数を算出する処理」は大変だからです。

他にも「割り算の余り」、つまり剰余（MOD や %）などもよく使われます。なぜなら逆の「余りだけから考えられる元の値の組み合わせ」は無限にあるからです。(A * B) % C = D の場合、D のループするパターンを見れば C は予測できても A B の組み合わせは無限にあります。

hash(){
    str="$1" OPTIND=1 # 入力を取得
    prime=257         # 秘密の定数
    sum=0             # 割られる数

    # 入力文字ごとにループ
    while   getopts : na  -"$str"
    do
        ascii="$(printf '%d\n' "'$OPTARG")"   # ASCII コードを 10 進数で取得
        sum=$(( sum + ascii ))                # 割られる数に加算
    done

    h="$(( $(( $sum * $prime )) % 100 ))" # 加算値に秘密の定数を掛けて割った余り
    printf "%s:\t%02d\n" "$str" "$h" # 2 桁で出力 (00〜99)
}

• オンラインで動作をみる @ paiza.IO

このように「一方向性関数」の考え方は暗号化の処理には重要です。そしてハッシュ関数も一方向性的な性質を持っているため、暗号処理やセキュリティ関連でも、よく使われるのです。

暗号学的ではないアルゴリズム（破損と類似の検知）

これまでの話しをまとめると、「暗号学的ハッシュ」は他のアルゴリズムと比べて「非可逆性」と「同一性」を重視したアルゴリズムです。つまり、「異なるデータが同じハッシュ値にならないこと」を目的としたタイプと言えます。

逆に「暗号学的ではない・・ハッシュ関数」も数多くあります。

主に、暗号（セキュリティ）目的ではなく「データの状態」を確認するためのものです。例えば、非可逆性や同一性よりも「データが壊れていないかの確認」を目的としたタイプです。

つまり、異なるデータが同じハッシュ値になる可能性が高いことを承知の上で、あくまでも手元のデータが壊れていないかを確認するためのものです。有名なものでは CRC などがあります。

ハッシュ値を「データの指紋」だとすると、暗号学的ハッシュ関数に比べ CRC などは「指紋の種類（渦巻き状、ひづめ状、弓形状、変形状など）の確認しかできない程度のもの」と言えるかもしれません。「渦巻き状であるか」は確実に識別できるも、渦巻き状の指紋の人は多い、みたいなイメージです。

他にも「暗号学的ハッシュ関数ではない・・」ものに、aHash, pHash, dHash, wHash, NeuralHash などがあります。

これらは Perceptual Hash（知覚ハッシュ）と呼ばれ、「感覚的に似たようなデータかの確認」を目的としたタイプです。

つまり、データの破損や完全な同一性の確認よりも、データの特徴・パターンをハッシュ値にすることで似たようなデータは近い数値、もしくは似たビットの並びになるのが「知覚ハッシュ」です。

知覚ハッシュは、主に画像や音楽といったマルチメディア関連の類似コンテンツの検知に使われます。他にも、最近では「類似論文の検出」や、機械学習において「類似データの生成や推論にも使えないか」といった研究も盛んです。

例えば LLM などでは、単語や語句の関連性を空間軸として、単語や語句を多次元空間に配置します。

"Word embeddings and how they vary" @ ミシガン大学 AI ラボより

すると、類似した文は類似した位置関係値を持つことになります。

その関係値をマッピングしたもの（座標をベースとした位置関係の配列。ハッシュ値とは言わず、Embeddings と呼ばれる配列データ）を、DB の検索キーとしてコンテンツの自然文検索に活用したりしています（これを Semantic Search と言います）。

知覚ハッシュの具体例として、類似画像の検知で有名な pHash を実際に見てみるとピンとくるかもしれません。

以下の 3 つの画像は人間が見ると「似たようなデータ」です。しかし、暗号学的ハッシュやチェックサム的ハッシュの場合は、1 ビットでも異なるとまったく異なるハッシュ値になります。

MD5: 1776fb44ba995fff55ef3498f289b3ba	MD5: abd3a65a92022c0b1cb37b1d5bafb53e	MD5: 060eeab60cc578367f8cd22731a5774e

対して、Perceptual Hash（知覚ハッシュ）はデータの類似性をハッシュ値にする（数値化する）試みです。例えば、先の画像を 64bit長（16桁）の pHash に通した場合、以下のように同じハッシュ値になります。

pHash-64: ab85f430d0c3d35e	pHash-64: ab85f430d0c3d35e	pHash-64: ab85f430d0c3d35e

また、解像度（出力ビット長）を高めると、違いは出てくるものの、ほぼ似た値になります。

pHash-256: abfd856df40a30b7 d081c3e0d2745e0a 8f56cc0783c35c1f 8e9b3cf8926d36e8	pHash-256: abfd856df40a30b7 d083c3e0d2745e0a 8f56cc0783c35c1f 8e993cf8926d36e8	pHash-256: abfd856df40a30b7 d081c3e0d2745e0a 8f56cc0783c35c1f 8e9b3cf8926d36e8

package main

import (
	"fmt"
	"image"
	"image/jpeg"
	"os"

	"github.com/corona10/goimagehash"
)

const (
	file1         = "qiitan_color1.jpg"
	file2         = "qiitan_color2.jpg"
	file3         = "qiitan_mono.jpg"
	imgShrinkSize = 8 // 8 -> 64bit pHash, 16 -> 256bit pHash, must be 2^N
)

func main() {
	img1, err := getImg(file1)
	panicOnError(err)

	img2, err := getImg(file2)
	panicOnError(err)

	img3, err := getImg(file3)
	panicOnError(err)

	hash1, err := goimagehash.ExtPerceptionHash(img1, imgShrinkSize, imgShrinkSize)
	panicOnError(err)

	hash2, err := goimagehash.ExtPerceptionHash(img2, imgShrinkSize, imgShrinkSize)
	panicOnError(err)

	hash3, err := goimagehash.ExtPerceptionHash(img3, imgShrinkSize, imgShrinkSize)
	panicOnError(err)

	fmt.Printf("hash1: %x\n", hash1.GetHash())
	fmt.Printf("hash2: %x\n", hash2.GetHash())
	fmt.Printf("hash3: %x\n", hash3.GetHash())
}

func getImg(imgPath string) (image.Image, error) {
	file1, err := os.Open(imgPath)
	if err != nil {
		return nil, err
	}

	defer file1.Close()

	return jpeg.Decode(file1)
}

func panicOnError(err error) {
	if err != nil {
		panic(err)
	}
}

さて、この pHash の仕組みをザクっと説明すると「画像をモノクロ（グレースケール）に変換して、中央値からの濃淡の変化をパターンにし、固定長の配列にマッピングしたもの」です。

とは言え、単純に低解像度のモノクロ・モザイク画像を配列にしたものではありません。JPEG や MP3 の圧縮などでも使われる、差分の違いをパターン化するアルゴリズムを使っています。

ここで言う「パターン化」とは、数値の変化を波と見なし「複数の波が組み合わさったもの」として、単純な波（サイン波）に分解することを言います。そして各々の波の成分をマッピングしたものをハッシュ値とします。

伝わるかわかりませんが、電子音楽で言うシンセ音源と逆のことをするイメージです。各々のオシレーターの設定値（パラメーター）をマッピングしたようなもの、みたいな。もしくはフーリエ変換ってやつです。

そして、どれだけ類似しているかをハミング距離で計測します。

ハミング距離というのは、同じ長さの 2 つのデータを比較した時、違いが少ないほど距離が近い（類似している）とする考え方です。

具体的には、並びの違う箇所の数を距離とします。例えば、2 つのハッシュ値を xor した値（2 つが異なる場合は 1 にする処理）のビットの数を数え、1 の出現数が少ないほど距離が近いと考えます。

func HammingDistance(a, b []uint64) (int, error) {
	if len(a) != len(b) {
		return -1, errors.New("different length of input")
	}

	dist := 0

	for i := range a {
		// (a xor b) した結果のビットが 1 の数を加える
		dist += bits.OnesCount64(a[i] ^ b[i])
	}

	return dist, nil
}

IMG1	IMG2	IMG3	IMG4
pHash-256: abfd856df40a30b7 d081c3e0d2745e0a 8f56cc0783c35c1f 8e9b3cf8926d36e8	pHash-256: abfd856df40a30b7 d083c3e0d2745e0a 8f56cc0783c35c1f 8e993cf8926d36e8	pHash-256: abfd856df40a30b7 d081c3e0d2745e0a 8f56cc0783c35c1f 8e9b3cf8926d36e8	pHash-256: e6bac719ba453ae6 e4123961c1ae319e 92f063b6c79064f9 c647b6d0924f6666
IMG1 との距離: 0	IMG1 との距離: 2	IMG1 との距離: 0	IMG1 との距離: 122

package main

import (
	"errors"
	"fmt"
	"image"
	"image/jpeg"
	"math/bits"
	"os"

	"github.com/corona10/goimagehash"
)

const (
	file1         = "qiitan_color1.jpg"
	file2         = "qiitan_color2.jpg"
	file3         = "qiitan_mono.jpg"
	file4         = "keinos_logo.jpg"
	imgShrinkSize = 16 // 8 -> 64bit pHash, 16 -> 256bit pHash, must be 2^N
)

func main() {
	images := []string{file1, file2, file3, file4}

	lenImages := len(images)
	hashes := make([][]uint64, lenImages)

	for index, imgPath := range images {
		img, err := getImg(imgPath)
		panicOnError(err)

		pHashed, err := goimagehash.ExtPerceptionHash(img, imgShrinkSize, imgShrinkSize)
		panicOnError(err)

		hashes[index] = pHashed.GetHash()
		fmt.Printf("hash #%d: %x\n", index, hashes[index])
	}

	for i := range lenImages {
		for j := range lenImages {
			if i == j {
				continue
			}

			dist, err := HammingDistance(hashes[i], hashes[j])
			panicOnError(err)

			fmt.Printf("Distance between #%d and #%d: %d\n", i, j, dist)
		}
	}
}

func HammingDistance(a, b []uint64) (int, error) {
	if len(a) != len(b) {
		return -1, errors.New("different length of hashes")
	}

	dist := 0

	for i := range a {
		dist += bits.OnesCount64(a[i] ^ b[i])
	}

	return dist, nil
}

func getImg(imgPath string) (image.Image, error) {
	file1, err := os.Open(imgPath)
	if err != nil {
		return nil, err
	}

	defer file1.Close()

	return jpeg.Decode(file1)
}

func panicOnError(err error) {
	if err != nil {
		panic(err)
	}
}

ちなみに、類似画像のハッシュについて、英語ですが以下の動画が参考になります。

• SPED Talk Image Hashing @ Youtube
• 論文: AN IMAGE SIGNATURE FOR ANY KIND OF IMAGE | PDF by パロアルト研究所 @ ペンシルベニア州立大学
  • 論文の説明動画: Ryan Henderson - One in a billion: finding matching images in very large corpora @ Youtube

何はともあれ、いずれのハッシュ・アルゴリズムであっても「データを特定する指紋のようなもの」であることがポイントです。

破損チェック

先に述べた CRC や fnv などの「データが壊れていないかの確認」に使われる値は「チェックサム」とも呼ばれます。

しかし、学術的には「CRC」と「チェックサム」は別物です。各々のアルゴリズムが存在するからです。面倒臭いのが、実用面でチェックディジット的に使われる値全般を「チェックサム」と呼ぶことがあることです。

チェックディジットというのは、例えば、バーコードの最後の 1 桁の数値（ディジット）などです。

データは“123”、チェックディジットは“6”のバーコード （「チェックディジットとは」 バーコードのしくみ @ キーエンスより）

上の例では、バーコード・リーダーは値 "1236" を読み取ると「最後の 1 桁を除く値（ここでは "123"）をゴニョゴニョと計算したら最後の 1 桁（ここでは "6"）と同じになるか」と確認することで正常に読み取れたか確認します。

他にも、身近なところではクレジット・カードの番号にもチェックデジットが付いています。カード自体が有効であるかを確認する前に、そもそも入力された（読み取った）番号が正常に読み取れたか確認する必要があるからです。カード会社によってチェックに使われるアルゴリズムは異なりますが、有名なところでは Luhn アルゴリズムがあります。

• Go で Luhn アルゴリズムの動作を見てみる @ Go Playground

このように、最後の数値、つまり読み取りエラーを検知するのに使われる数値がチェックディジットです。

そして、ハッシュ値を似たような目的のために使われる場合に「チェックサム」と呼ばれることがあります（「SHA-256 なのにチェックサム足し算って、なぜに？」と思ったことがある人は多いのではないでしょうか）。

そのため、アルゴリズムとしての「チェックサム」と、用途としての「チェックサム」があることに注意します。この記事では CRC およびチェックサムの両アルゴリズムを「チェックサム的・アルゴリズム」と総称します。

なお、暗号学的アルゴリズムに比べ、チェックサム的アルゴリズムは速いものの、改竄かいざんに弱く、パターンが表れやすい傾向があります。

特に改竄に対しては、とてつもなく弱いです。

異なる値なのに簡単に衝突させる（同じハッシュ値にさせる）ことができてしまいます。これは、意図しないコードを差し込むことができるということでもあります。

例えば「foo」というコードに「this is a bad code」というコードを差し込みつつ、「0x1ff172ec」という調整を加えることで、同じハッシュ値にすることができてしまいます。

package main

import (
	"fmt"
	"hash/crc32"
)

func main() {
	// Expected code
	goodCode := "foo"
	hashGolden := crc32.ChecksumIEEE([]byte(goodCode))
	fmt.Printf("Good: %x\n", hashGolden)

	// Inject malicious code "this is a bad code" with adjustment value
	badCode := goodCode + "\nthis is a bad code\n\x1f\xf1r\xec"
	hashHacked := crc32.ChecksumIEEE([]byte(badCode))
	fmt.Printf("Bad : %x\n", hashHacked)
	//
	// Output:
	// Good: 8c736521
	// Bad : 8c736521
}

• オンラインで動作を見る @ GoPlayground

これは、チェックサム的アルゴリズムが「たとえ演算結果から元のデータは逆算できなかったとしても、データの改竄がしやすい」と言うことです。

つまり、ハッシュ値のやりとりを傍受された場合に、内容は分からずとも「はは〜ん」と流れを読まれ、いじられてしまう可能性がある、と言うことでもあります。

そのため「流れてきたデータに問題はないか」の確認に、「破損チェック」にはチェックサム的アルゴリズムを使い、「改竄チェック」には暗号学的アルゴリズムを使う、といった特徴に合わせた適材適所の判断が必要になります。

とは言え「数マイクロ秒の差が売り上げに大きく影響する」など、よほどシビアな条件でない限り、暗号学的アルゴリズムを使うのがいいでしょう。暗号学的アルゴリズムはチェックサムとしても使えるからです。（逆はできない）

使うなら SHA-2 系の SHA-512 や SHA-3 系の SHA3-256 などの強めのアルゴリズムなら、なおベストです。処理時間などのコストが許す限りベターなものを選びましょう。組み上がってからベストなものに調整して行った方がいいと思います。便利で丁度いいサイズの MD5 アルゴリズムを大事な局面で使っていると暗号警察がやってきますよ。

いまどき CRC なんて使い所あるの？

SHA-2 や SHA-3 などのツヨツヨなハッシュ・アルゴリズムを知ってしまうと、CRC などのチェックサム的アルゴリズムなんかオワコンと思われがちです。

ところが、意外なところで使われるのがデーターベース（以下 DB）の負荷分散処理です。

例えば、リクエストされたキー（key）に対してバリュー（value）を返すだけの連想配列のような、キー・バリュー型の DB では、負荷を分散するために使われます。

と言うのも、リクエスト数やデータ量が多くなった場合、複数のノードにデータを分ける必要が出てきます（ここで言うノードとは、複数台で 1 つのサービスを提供している場合の 1 台のことです）。

この時、どの DB ノードにデータを保存するか・リクエストするかを決めるのに、リクエストされたキーをハッシュ関数に通し、その値をノードの台数で割った余り（余剰、mod）を使います。

nodeCount = 3                    // 3台の DB ノードでクラスタリングする
nodeID  = crc16(key) % nodeCount // 0〜2 の ID に分けられる

リクエスト毎に接続先を順番に切り替えるラウンドロビン方式を発展させた考え方で、リクエスト・キーが同じなら決まったノードに転送できます。メリットとしては、ラウンドロビンのように全てのノードが同じデータを持つ必要がありません。また、ハッシュ値が衝突したとしても同じノードに送られるだけなので、速度を優先できます。

しかし、このままだとノードの増減にフレキシブルに対応できません。そこで、あらかじめノードに複数の ID をマッピングしておきます。そして、ノードが増えたらマッピングしたデータの一部を移動させます。この考え方を利用した、有名なところでは Redis などがあります。

• Overview of Redis Cluster main components | docs @ redis.io

「ハッシュ値」と「暗号」の関係

さて「ハッシュ化は暗号化ではない」とは言ったもののハッシュ値は暗号と密に関係しています。

これは、ハッシュ値は暗号データの担保情報としても使われるためです。

特に暗号通信においては「切っても切れない関係」にあります。公開鍵・秘密鍵暗号では、公開鍵を担保する情報としても使われるからです。他にも、後述しますが、お互いの秘密鍵を共有せずに相手の公開鍵から共通の鍵を作成する際にも、ハッシュ関数が活用されたりします。

さて、このハッシュ関数の「非可逆」な特徴は、一般的に「パスワードの保存」などに使われます。

「パスワードの管理」で、皆が通る道に「パスワードをどうやって保存するか」の葛藤があります。

ユーザーのパスワードを生で保存する（そのまま保存する）のはもってのほか。暗号化するにしても秘密鍵が漏洩したら全てのパスワードがわかってしまうため元も子もありません。また、各々のパスワードに対して秘密鍵を作成しても、秘密鍵の DB が漏洩したら同じことです。

しかし、管理側で求められるのは「ユーザーが事前に決めたパスワード」と「ログインで入力されたパスワード」が同じであるかの確認だけです。

「パスワードはサーバーに保存しておきたくない」、でも「パスワードが登録したものと同じか確認したい」という、覚えたくないけど答えられるようになりたい暗記パンみたいなワガママをハッシュ関数は実現します。

具体的には「パスワードをハッシュ化して保存する」ことで可能です。

パスワードが正しいかの確認はハッシュ値を比較すれば良く、「ハッシュ値が流出したとしても元のパスワードはわからない」だけでなく「管理者すら元のパスワードはわからない」といったメリットがあるからです。パスワード流出事件があると「自分たちでもわからない状態で保存されているから云々うんぬん」という話しがでるのもこのためです。

このようなエンコード（特定のルールに従って変換）した値でやりとりする仕組み、つまりオリジナルを隠蔽したままの（デコードする必要のない）状態で、確認のやりとりをする仕組みを「一方向暗号」と呼んだりします。しかし、あくまでもハッシュ値を「暗号セキュリティ用途」として使っているだけです。繰り返しますが、ハッシュ化=暗号化ではありません。

しかし、単純にハッシュ化したからといって安心はできません。

まず、ハッシュ関数のアルゴリズムに CRC のようなチェックサム的アルゴリズムを使ってしまうと、簡単に衝突する（異なるパスワードなのに同じハッシュ値になりやすい）だけでなく、わざと衝突させて改竄する攻撃にまったく耐性がありません。

そのため、後述する salt（塩）を使ったテクニックも役に立ちません。しかし、CRC や checksum は改竄耐性がない以前に、そもそも用途が違います。

次に、「鳩の巣原理」という「鳩の巣箱が鳩の数より少ない場合は、必ず 1 つ以上の巣箱で衝突する鳩がいる」という原理があります。椅子取りゲーム的なものです。

つまり、ハッシュ値のビット長が短かいほど、同じ原理で衝突しやすくなります。

では「暗号学的ハッシュ関数など、ハッシュ値のビット長が長ければ安心か」と言うと、安心できません。

1. 「誕生日のパラドックス」と呼ばれる、「意外に衝突する」というジレンマの問題。
2. 暗号学的アルゴリズムであっても MD5 や SHA-1 のように「合理的に衝突させる方法が見つかっているアルゴリズム」がある。

実は、上記以上の問題があります。

「引数が同じ場合は戻り値も同じ」という、もう１つのハッシュ関数の特徴により流出したデータがハッシュ化されていても意味をなさないことがあるからです。

具体的には、別途パスワード・リストなどがあった場合です。

なぜならパスワード・リストからパスワードをハッシュ化して同じ値を探せばいいからです。つまり「辞書攻撃が使える」ということにもなります。

例えば Folding@home で有名な、バークレー大学の BOINC を使った分散コンピューティングのプロジェクトの 1 つに "Free Rainbow Tables" というものがあります。

これは、注意喚起のために作成された、ハッシュ関数の逆引きを可能とする、数テラバイト規模の巨大な辞書（レインボーテーブル）です。

他にも、過去に流出したメールアドレスとパスワード、32 億件をアーカイブした COMB データなども存在し、その後の流出したものを含めると 150 億件以上のデータが検索可能となっています。つまり、全世界の人口（80億）の約 2 倍近くのパスワードが「表の世界」であっても確認できることになります。

例えば、この記事のサンプルに出てくる 34902903de8d4fee8e6afe868982f0dd（beef を MD5 でハッシュ化したもの）でも、筆者のショボいマシンでも 10 秒以内で総当たり解析できてしまいます。

$ # 総当たり（-a 3)で MD5(-m 0)を解析する
$ time hashcat -a 3 -m 0 "34902903de8d4fee8e6afe868982f0dd"
hashcat (v6.2.6) starting

METAL API (Metal 263.9)
=======================
* Device #1: Intel(R) Iris(TM) Graphics 6100, skipped

OpenCL API (OpenCL 1.2 (Aug 17 2023 05:46:30)) - Platform #1 [Apple]
====================================================================
* Device #2: Intel(R) Core(TM) i5-5257U CPU @ 2.70GHz, 4064/8192 MB (1024 MB allocatable), 4MCU
* Device #3: Intel(R) Iris(TM) Graphics 6100, skipped

Minimum password length supported by kernel: 0
Maximum password length supported by kernel: 256

Hashes: 1 digests; 1 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates

Optimizers applied:
* Zero-Byte
* Early-Skip
* Not-Salted
* Not-Iterated
* Single-Hash
* Single-Salt
* Brute-Force
* Raw-Hash

ATTENTION! Pure (unoptimized) backend kernels selected.
Pure kernels can crack longer passwords, but drastically reduce performance.
If you want to switch to optimized kernels, append -O to your commandline.
See the above message to find out about the exact limits.

Watchdog: Temperature abort trigger set to 100c

Host memory required for this attack: 1 MB

The wordlist or mask that you are using is too small.
This means that hashcat cannot use the full parallel power of your device(s).
Unless you supply more work, your cracking speed will drop.
For tips on supplying more work, see: https://hashcat.net/faq/morework

Approaching final keyspace - workload adjusted.           

Session..........: hashcat                                
Status...........: Exhausted
Hash.Mode........: 0 (MD5)
Hash.Target......: 34902903de8d4fee8e6afe868982f0dd
Time.Started.....: Sun Mar 24 15:29:11 2024 (0 secs)
Time.Estimated...: Sun Mar 24 15:29:11 2024 (0 secs)
Kernel.Feature...: Pure Kernel
Guess.Mask.......: ?1 [1]
Guess.Charset....: -1 ?l?d?u, -2 ?l?d, -3 ?l?d*!$@_, -4 Undefined 
Guess.Queue......: 1/15 (6.67%)
Speed.#2.........:   313.1 kH/s (0.01ms) @ Accel:512 Loops:62 Thr:1 Vec:4
Recovered........: 0/1 (0.00%) Digests (total), 0/1 (0.00%) Digests (new)
Progress.........: 62/62 (100.00%)
Rejected.........: 0/62 (0.00%)
Restore.Point....: 1/1 (100.00%)
Restore.Sub.#2...: Salt:0 Amplifier:0-62 Iteration:0-62
Candidate.Engine.: Device Generator
Candidates.#2....: s -> X
Hardware.Mon.SMC.: Fan0: 42%
Hardware.Mon.#2..: Temp: 46c
**snip**

34902903de8d4fee8e6afe868982f0dd:beef

**snip**

Started: Sun Mar 24 15:29:04 2024
Stopped: Sun Mar 24 15:29:13 2024

real	0m9.168s
user	0m1.211s
sys	0m0.576s

それくらい、単純に「ハッシュ化しただけ」では安心できないものなのです。

ハッシュしただけでは味気ないので塩を足そう

さて、ハッシュ関数や暗号関数を触っていくと「salt」（ソルト、サルト^🔈）という言葉が出てきます。日本語で「塩」のことですが、一般的に「ソルト」と記載されます。

コンピューターの世界で salt は、各々のデータに加えるランダムな数値や文字列のことを指します。先の例で言えば beef に加えた salt=1 です。

料理でいう「塩加減」のように「同じ具材でも塩の加減１つで味が変わるため、毎回調整が必要で加減も秘伝hidden」と言ったイメージが近いのですが、「塩土化」、つまり「戦時中の敵国が占領地の土地に塩を撒いて使えなくする」から来ている説もあるようです。

これまでの例のように、salt の値は「データの前」もしくは「データの後ろ」につなげてハッシュ化する方法によく使われます。

$a = hash( 'md5', $data . $salt); // 後から塩を足す
$b = hash( 'md5', $salt . $data); // 先に塩を足す

data='beef'
salt='1'

# 先に塩を足す（"1beef"）
hash_prepend_salt=$(echo -n "${salt}${data}" | openssl md5)
echo $hash_prepend_salt; # b14ab03be97e0b8deb2fa930cfdd4f4a

# 後から塩を足す（"beef1"）
hash_append_salt=$(echo -n "${data}${salt}" | openssl md5)
echo $hash_append_salt;  # 30017279d6a5bac241e764eeed261dd8

上記のように、salt を加えるとハッシュ値が変わるのは当然として、前後の salt を入れ替えるだけでもハッシュ結果が大きく異なります。

では、前に足すか、後ろに足すか、どちらのパターンが良いのでしょう。

塩は後から足そう

料理の場合、味を見て後から塩を足すのが基本であるように、単純に salt をデータに足す場合も、後から足すようにしましょう。

$a = hash( 'md5', $data . $salt); // 👍 ベター
$b = hash( 'md5', $salt . $data); // 👎 問題あり

これは、Length extension attack（「伸長攻撃」）と呼ばれるハッシュ値の衝突攻撃に弱いからです。

特に、MD5, SHA-1 や SHA-2 などの Merkle–Damgård と呼ばれる構造を使うハッシュ関数の場合についてまわります。発音は「マークル・ダンガード」のようです。ヒーロー・ロボットのような名前ですが、ブロック・チェーンに興味のある方は、この名前と salt を覚えておいてください。後から出てきます。

さて、この「伸長攻撃」攻撃を恐れずに短く説明すると以下の通りになると思います。

Y = hash( salt . X ) の X と Y がわかっている場合、salt の長さがわかれば salt が逆算できなくても Y = hash( salt . X . Z) の計算ができる。（. は文字列の結合子）

そのため Z に良しからぬ文字列を入れて Y の値を同じにすることができる可能性がある。

• ソルトとハッシュ関数だけでパスワードをハッシュ化するのが微妙な理由 @ Qiita
• Length Extension Attack ツール "Hash Extender" @ GitHub
  • salt を secret、X を data、Y を signature、Z を append に置き換えて README をご覧ください。
  • このツールの作者のブログに詳しい計算方法が載っています。
    Everything you need to know about hash length extension attacks @ SkullSecurity

逆に Y = hash( X . salt) と後に付け加える場合は、この攻撃を回避できます。「味付けは後から行う」（salt を加えるのは後）と覚えておきましょう。

塩だけでなく胡椒も足そう

この「salt」（塩）は基本的に個々のデータに加えるのですが、DB の場合、全体に加える「pepper」（胡椒）と呼ばれる値もあります。

• ソルト（暗号化）@ Wikipedia 日本語
• ペッパー（暗号化）@ Wikipedia 英語

例えば、下記はプレーンな（加工や手を加えていない素すの状態の）パスワード情報です。偶然にも user1 と user2 のパスワードが同じです。

上記だと流出時にバレバレなので、次のようにパスワードに塩・胡椒して味付けします。

$passwd_hashed = md5($passwd . $salt . $pepper);

DB の保存で考えると、定数に pepper='pepperA' と設定しておき、テーブルは以下のようなイメージになります。

DB ファイル自体が流出したらテーブルをわけても同じことであるため、パスワードとソルトを同じテーブルに格納する場合もあります。どこに格納するかは運用の考え方しだいだと思います。

「ならば、ソルト値を別 DB に保存してリスク分散しなきゃ」と言った、沼にハマったのであれば、以下の記事を一読することをオススメします。

• ソルト付きハッシュのソルトはどこに保存するのが一般的か @ Qiita

さて、全体に胡椒を加えるpepper値を使うメリットは、DB のファイルが流出した場合の迅速な対応が取れることと、全体のコントロールを取りやすいことです。

pepper の定数が流出していなければ、流出した DB の salt 値からだけでは保存されたハッシュ値を算出するのは大変なので、2 つ目のブロック防壁としては機能します。しかし、攻撃者が予めダミーのアカウントでパスワードを登録しておけば、パスワードと salt 値はわかることになるので、pepper 値の算出は時間の問題となります。

このような事態の場合、まずは「ユーザー全員にパスワードを再設定をしてもらうこと」が最優先です。そこで、pepper 値を変えれば、すべての保存値と計算が合わなくなるので全体をロックできます。

この胡椒を効かせる方法は、アイデア次第で色々と使えます

ログイン時の cookie の ID などでも使われるテクニックで、不審なログインを複数ユーザーで検知した場合に、pepper 値を変えることで、全員を強制的に再ログインさせることができます。

他にも、定期的に pepper 値を変えて、その後「更新した・しない」でアクティブ・ユーザーを確認したり、アプリに興味のないユーザーをふるい・・・にかけたりするのにも利用できます。スマホのアプリでも定期的に再ログインさせられ、舌打ちしたことがあると思いますが、アレです。

もちろん、スマホの OS のアップデートやセッションの期限切れによるものもありますが、「更新」という名において、いささかダークなパターンにも利用される可能性があるということです。

また、実際に salt や pepper 値を使う場合は以下のように、より複雑にシェイクします。

1. "saltA" などの単純な文字列でなくランダムな数値や文字列を使う
2. アルゴリズムを sha256 や sha512 などのより複雑なアルゴリズムを使う
3. hash('sha256', hash('sha256', $value)) と二重・三重にハッシュ化させたりする（時に数万回）

パスワード・ハッシュとは

さて、ここまではパスワードの保存に関する話がメインでした。

しかし、本記事はセキュリティのための記事ではありません。あくまでもハッシュ関数の基礎知識と「活用」に関する記事です（「結構、セキュリティ（暗号）の話しをしとるやないかい」と思うかもしれませんが、我々の世界でいう「HDD と SSD の説明と違い」を説明している程度の内容らしいです）。

「安全なパスワード保存」にハッシュ値を使いたいのであれば、パスワード管理専用の関数やフレームワークが各々のプログラム言語には数多くあります。一般的にハッシュ値をパスワード管理に特化したものを「パスワード・ハッシュ」と呼びます。

自分で実装するよりは、それらを利用した方が楽らくだし、何より安全です。例えば PHP の場合であれば password_hash() という、まんま・・・の関数があります。

先の「ストレッチング」のように「パスワード・ハッシュ」は計算のしづらさ（面倒くささ）に重点をおいているので、速度の速さと強度が重視される「ハッシュ関数」とは目的が違います。

2021/03/01 現在、最強のパスワード・ハッシュは Argon2 と思われます。2013 年から 2015 年にかけて行われた PCH というパスワード・ハッシュの競技会で優勝したのが Argon2 だからです。

Argon2 には、Argon2i と Argon2d の大きく 2 つあります。

Argon2i は、処理時間やハードの電圧など物理的に観察して情報を盗むサイドチャンネル攻撃に耐性があり、Argon2d は、GPU 攻撃（単純な計算の並列処理）に強い耐性があるアルゴリズムです。そして、両方を備えたアルゴリズムが Argon2id です。

例えば PHP 7.3 以降では両方に対応した PASSWORD_ARGON2ID が使えます。（オンラインで動作をみる @ paiza.IO）

また、Go の場合は golang.org/x/crypto/argon2 の公式パッケージが使えます。いささか使いづらいので、手前味噌ですが、使いやすくしたパッケージ "go-argonize" も用意しました。どのように使うのかの参考にしてみてください。

セキュリティの記事ではないとは言え、セキュリティが心配でハッシュ関数を勉強に来たという方は、かの Web セキュリティのバイブルとも言える「徳丸本」で有名な徳丸先生の Youtube 動画チャンネルを入り口とする（フォローする）ことをお勧めいたします。その上でバイブルの１冊くらいは持っておくと良いと思います。

ぶっちゃけ、こんなジャンクで基本的な内容の記事を読むより、先生の本や e ラーニングのコースを受講された方が実装の役に立ちます。

• 徳丸浩のウェブセキュリティ講座 @ Youtube
• 先生の e-ラーニングサービス @ Security Campus [説明動画]
• 徳丸本 「体系的に学ぶ 安全なWebアプリケーションの作り方 第2版」
  〜脆弱性が生まれる原理と対策の実践〜
  • ISBN-10: 4797393165
  • https://amazon.co.jp/dp/4797393165/ @ Amazon
  • ここ 1 年の「徳丸本」に関する Qiita 記事 @ Google

これから使うなら SHA-3

パスワード以外のデータのハッシュ化に強いアルゴリズムが欲しいと悩んだら、とりあえずは「SHA3-512」を選ぶといいでしょう。次点で、SHA3-256 でしょう。OS やプログラム言語間で互換性が高い（汎用度が高い）中では、一番強いハッシュ・アルゴリズムだからです。（2020/10 現在）

ぶっちゃけ SHA-2 の SHA-256 や SHA-512 でも実用としては現状十分です。

しかし、SHA-2 は 20 年以上前のアルゴリズムであること、脆弱性（合理的な衝突方法）が発見されている SHA-1 の親戚であること、今後の演算力の向上により SHA-2 も時間の問題であることから、移行が推奨されていることを知る必要があります。

これから実装するのであれば SHA-1 や SHA-2 とはまったく違う概念のアルゴリズムで SHA-2 の後継と正式に制定された SHA-3 の利用を検討する価値はあると思います。

とは言え、強いアルゴリズムほど複雑さが増すため処理速度やレスポンスの問題も出て来ます。

どの程度複雑化させるのかも運用の考え方しだいになると思います。一旦強いもので組んでから、予算・運用コスト（計算コスト）・UX と相談しながら、測定しながら低い方へ検討してください。（「憶測するな、測定せよ」です）

いずれにしても、引数に $salt や $pepper およびハッシュ化のループ回数という、絶対公開しない要素加えることで予測を難しくさせているのです。

もちろん salt 値や pepper 値が流出してしまうと意味がありません。シオシオのパーです。つまり、秘密鍵と同じくらい扱いには気をつけないといけないので、「ハッシュ化しても安心できない」とわかると思います。

塩に工夫をして秘密の共通レシピを作ろう（簡易共通鍵の作り方）

さて、元のデータに秘伝hiddenの salt 値を加えてハッシュ化することで、元のデータのハッシュ値を隠蔽いんぺいすることができました。

ここで、salt 値を「外部に公開してはいけない値」なおかつ「元の値を引き出す・特定するために使われる値」とすると、salt は秘密鍵keyと同じ定義を持つことにお気づきでしょうか。

この salt 値を使った仕組みをさらに工夫すると、2 者間でお互いの秘伝hiddenの salt 値から共通の salt 値を作成することができます。

つまり、俗に言う「共通鍵」のようなものが、お互いの秘密鍵salt値から作成することができるのです（鋭い人はお気づきかもしれませんが、そうです「ディフィー・ヘルマン鍵共有」のことです）。

注意点として、このような使い方の値を salt とは呼びません。ここでのポイントは「お互いの秘伝hiddenの値を相手に知らせなくても、加え方次第で共通の鍵が作成できる」という点です（ゆうて、足し算的なことをしているだけなのですが）。

さて、基本的な仕組みですが、数式を使うと頭がチャンポンしちゃうので「色をチャンポンする」と例えると理解しやすかったです。

と言うのも、データに salt 値を加えてハッシュ関数でゴチャ混ぜにするというのは、別の見方をすると「とある色」に「俺様カラー」の絵具を混ぜるようなものとも言えます。

そこで「共通鍵の作り方の流れ」を、まずは色を使った概念図で全体を把握したいと思います。

下図における「共通色」は Alice と Bob が事前に合意している色、「秘密色」は各々がランダムに選んだ色、と考えながら下の図を見てください。

ここでのポイントは「秘密色の交換をしていない」ことと、「色を混ぜているだけ」です。

"Diffie–Hellman key exchange" @ 「ディフィー・ヘルマン鍵共有」の英語版 Wikipedia より筆者による日本語訳

色で概念を捉えたとは言え、コードで書かないと理解できないタイプなので、上記を Bash で再現してみました。

いささか分かりづらいですが、"yellow" "red" "green" の文字列を MD5 で数値化し、上記の図の通り足し算しているだけです。Alice.sh と Bob.sh がお互いの秘密色（xxxSecretColor）を参照（受け取って）いないことに注目してみてください。

• オンラインで動作を見る @ paiza.IO

鋭い人は「えー。でもお互いに同じ『共通色』を持っているんだから、『相手から受け取った混合色 - 共通色』と引き算すれば相手の秘密色がわかっちゃうじゃん」と気づくでしょう。

かく言う私は、自分で bash で実装してみて初めて気づきました。足し算でなく掛け算であっても同じです。割っちゃえばいいので。

上記図にある色交換のコメントで「混合色から元の色を分離させることは困難な混合の仕方とする」とあります。

つまり、2 つの値をゴニョゴニョと混ぜて 1 つの値を出すことを「色を混ぜる」と表現しているのですが、単純な足し算や足し算の連続（掛け算）は「分離させることが簡単な混合の仕方」ということになります。

では、色交換した値を自分の秘密色で hash(<色交換した相手の色> + <自分の秘密色>) のようにハッシュすれば良いかというとダメで、塩を前に足すか・後に足すかで大きく変わってしまうからです。

そこで再登場するのが割り算の余り。そう、mod（剰余、%）です。

X := (A * B) % Y // X から見ると、Y は予測できても、A と B の組み合わせは謎

つまり「割り算の余りからは、元の組み合わせを得ることは困難」という性質を使って「元の色（値）の組み合わせに分離させることは困難」という状況を作ってみましょう。

ここで、アホみたいな話しですが「a * b は b * a と同じ結果になる」という算数を思い出してください。

そして、同様に下記の 2 つは同じ結果になります。

• (a3)2 = (a * a * a) * (a * a * a) = a3*2 = a6
• (a2)3 = (a * a) * (a * a) * (a * a) = a2*3 = a6

これは数学的に表現すると (ax)y = (ay)x = axy, x = 3, y = 2 と表せます。落ち着いて見比べれば何てことないことを、短く表現しているだけです。

さて、この ax と ay を上記の色の概念図で交換される混合色とした場合、a が共通色、x と y が各々の秘密色とできそうです。

すると、各々算出する「共通秘密色」（共通の値 axy） は (ax)y と (ay)x と計算できそうです。

しかし、これでは（ただの掛け算なので）余りよろしくありません。

そこで両辺を同じ値 p で割った余りを出してみます。以下の 4つは同じ値になるのがおわかりでしょうか。

• (ax)y % p = 共通秘密色
• (ay)x % p = 共通秘密色
• axy % p = 共通秘密色
• ayx % p = 共通秘密色

これで「共通秘密色」が流出しても、a^x もしくは a^y の算出は難しくなります。

つまり、a とペアになる値 p を用意し、この 2 つの値をセットで「共通色」（事前に合意している色）とできそうです。

この考え方、つまり「掛け算の順番を変えても同じ値になる」「掛け算の結果が同じなら、それをさらに同じ値で割っても余りは同じになる」が、共通の秘密鍵を作成する際の基本となります。

とは言え、上記で問題なのが「お互いが a と p を知っていること」です。

交換しあった混合色（ax もしくは ay）から相手の秘密色の値（x と y）は算出できてしまいます。受け取った混合色を、結果が 1 になるまで a で割った回数が相手の秘密色だからです。

なんか、振り出しに戻ってきてしまいました。

そこで、相手に渡す混合色を p で割った余りにしたらどうでしょう。

• 旧混合色 % p = 新混合色
  • ax % p = pubA
  • ay % p = pubB

これであれば、お互いが a と p を知っていても pubA や pubB からは、秘密にしている x と y の色（値）の算出は劇的に難しくなります。

つまり、受け取った新しい混合色を各々は以下のように計算して、共通秘密色を算出することになります。

• 色交換後の共通秘密色の算出（新バージョン）
  • (pubB)x % p = (ay % p)x % p = 共通秘密色
  • (pubA)y % p = (ax % p)y % p = 共通秘密色

果たして「割った余りを、さらに割った余り」が同じ値になるのでしょうか。

それでは、以上を踏まえて Alice と Bob の公開鍵を具体的な数値で作ってみましょう。色のミックスに、足し算ではなく割り算の余り、つまり mod（剰余）を使っていることに注目です。

まずは、Alice と Bob は秘密鍵として、各々ランダムな値を決めます。ここでは、わかりやすいように Alice の秘密鍵を a、Bob の秘密鍵を b とします。

a = 4 // Alice の秘密鍵（ランダムな値）
b = 3 // Bob の秘密鍵（ランダムな値）

次に、事前に合意している 2 つの値（共通色）として、g と p の値を決めます。変数なので、x と y にしてもいいのですが、気分です。なんか、みんなこの変数名を使いたがるので。

// 事前に合意した値（セットで共通色とする）
g = 5
p = 23

g と p の値ですが、g は generator の略で乱数関数で言うところの seed 値的な役割をする値で素数です。p は prime（素数）の略です。ここでは「事前に合意している 2 つの定数 g と p がある。どうやら素数らしい」程度に考えておいてください。

本来はバカでかい素数を元に作られるのですが、わかりやすくするために 5 と 23 にします。

つまり、公開鍵は 5 の倍数（5^秘密鍵）を 23 で割った余りなので、0 〜 22 の間をクルクル循環する値とになります。

イメージとして、23（0 〜 22） 時まで表示できる時計があり、5 時を起点に秘密鍵ぶんの時間を進めた時の時間が自分の公開鍵の時間、そして相手はその時間に相手の秘密鍵ぶんの時間を進めるとお互いが同じ時間に止まるという考えです。

それでは、まずは Alice の公開鍵（混合色、pubA）を作ってみましょう。

事前に合意している g と p を元に、自身の秘密鍵（a）を使って計算するのですが、計算方法は以下の通りです。g を a 回掛けて、p で割った余りを公開鍵としているだけです。

• pubA = (g)a % p

同様に、Bob も公開鍵（混合色、pubB）を秘密鍵（b）を使って計算します。

• pubB = (g)b % p

次に、各々が公開鍵を交換（相手の公開鍵を参照）して、秘密の共通鍵の計算をします（commonA と commonB）。計算式は以下の通り。

• Alice の計算
  • commonA = (pubB)a % p
• Bob の計算
  • commonB = (pubA)b % p

共通鍵の計算といっても、秘密鍵を作った際の g を相手の公開鍵と入れ替えただけです。見比べてみてください。

それでは、実際に代入して（a = 4, b = 3, g = 5, p = 23 で）計算してみましょう。すると、共通の秘密鍵は同じ値になります。

• 公開鍵（混合色）の計算
  • pubA = (g)a % p = 54 mod 23 = 4 ... Alice の公開鍵
  • pubB = (g)b % p = 53 mod 23 = 10 ... Bob の公開鍵
• 共通秘密鍵の計算
  • commonA = (pubB)a % p = 104 mod 23 = 18 ... Alice の共通秘密鍵
  • commonB = (pubA)b % p = 43 mod 23 = 18 ... Bob の共通秘密鍵

なんと、割り算の余り（公開鍵）を、さらに割り算すると、余り（共通鍵）が同じになりました。（オンラインで動作を見る @ paiza.IO）

なぜ同じになるのかというと、剰余（modulo）には面白い性質があって、g と p が素数の場合、ある条件下において (ga % p)b % p は gab % p と同じになる性質があります。

• (ga mod p)b mod p = gab mod p

試しに (54 mod 23)3 mod 23 と 5(4*3) mod 23 が同じ答えになるか試してみてください。

これは y = x mod p の場合、つまり x を p で割った余りの y は 0〜(p-1) の間を循環するという剰余の性質と、1 と自分自身以外では割り切れない素数の性質を利用していて、ぐるりと巡りに巡って同じになるような感じです。

ここで注目して欲しいのは、上記の証明や条件の詳細ではなく、以下の点です。

1. 公開鍵は ga mod p と、余りを使っているため a を特定することは難しい。
2. p と g が素数の場合、ある条件下において以下が成り立つ。
   • (ga mod p)b mod p という計算は、gab mod p の計算と同じ結果になる。
   • (gb mod p)a mod p という計算は、gba mod p の計算と同じ結果になる。
   • gab mod p は、gba mod p と同じこと。

以上を踏まえて、改めて図を見てください。混合色を「割り算の余り」を使うことで、色を分離できない状態にしているのが面白いと感じませんか？

"Diffie–Hellman key exchange" @ 「ディフィー・ヘルマン鍵共有」の英語版 Wikipedia より筆者による日本語訳

この、混合色を交換して共通の秘密色を生成する概念を「ディフィー・ヘルマン鍵共有」（DH）と言います。

色交換に使われる混合色の作成は、今回のような mod を使ったもの以外にも、方程式（曲線）を使ったもの（ECDH）などがあります。

ECDH の基本概念をザクっと説明すると、事前に共通色となる方程式を決めておき、秘密鍵と公開鍵を方程式に掛け算した座標を交換しあうことで、お互いの線が交差する点を共通秘密鍵の値とするものです。

先の MOD（余剰、%）を使った方法のポイントは、割り算の余りを使い「組み合わせを無限にした」ことで、色交換する際の混合色、つまり「元の組み合わせに分解できない状態」にしたことです。

そこで、2 つの点があれば直線が引けることを思い出してください。そこから、導き出された方程式（ｙ＝ａｘ＋ｂ）を相手に渡しても、最初の 2 つの点は相手にはわかりません。

また、2 つの点のうち 1 つを共有しても、その方程式（もしくは傾き）からは 2 つ目の点はわからないため、受け取った相手は元の組み合わせはわからない（混合色から共通色と秘密色には分解できない）という状況が作れます。

そして、お互いが交換した方程式（or 傾き）が交差する点を共通点（共通秘密色）とすることができます。

このような考え方を、直線ではなく楕円曲線（EC、Elliptic Curve）を使ったものが ECDH です。

以下は Go 言語ですが、オンラインで動作が見れます。

• オンラインで Go の ECDH による秘密鍵共有の動作を見る @ GoPlayground

  • 参考文献：【Golang】ECDH 公開鍵から DH 鍵交換で共通鍵を作成する（ディフィー・ヘルマン鍵共有） @ Wiita

「（え？使うには、こんなもんでいいの？）」と思えればシメたものです。複雑な仕組みをリスペクトした上で関数化して利用する（盲目的に関数を使っていないという）大事な使い方が見えた証拠だと、私は思います。

ここでのポイントは「一方向への算出は簡単だが、逆方向は難しい」（ここでは色分解）という考え方が、暗号（セキュリティ）には重要であるという具体例です。

ストーカー・チャーリーの中間者攻撃

mod を使った DH、楕円曲線を使った ECDH、どちらも「とある問題」を除けば、堅牢な秘密の共通鍵が作成できる方法です。

そして、とある問題とは「中間者攻撃」です。

計算方法自体は堅牢なものの、実は、これだけではセキュリティー上よろしくありません。お気づきでしょうか。色交換で受け取った相手の混合色の「配合」は、お互いがわからないことに。

アリスAliceとボブBobが色交換をする際、中間にチャーリーCharlieがコッソリ入っていた場合、意図せずダミーの共通秘密色を使わせることができてしまいます。

つまり、色交換している相手が実はチャーリーだった場合です。チャーリーが適当な色を作って両者に渡してしまえば、両者は気付かないうちにチャーリーとの「共通秘密色」を作成していることになるのです。

これは、例えば github.com にアクセスしているのに、ダミーの IP アドレスにアクセスさせることで実現可能です。hosts ファイルの一時的な書き換えや、ダミーの DNS サーバーを立てて、DHCP をいじるなどです。

このように、中間にチャーリー的なストーカーが居た場合の攻撃に弱いということです。https 接続が重要という理由の 1 つがここにあります。

https 接続以外にも追加対策として、アリスとボブが「オンライン以外で、事前にランダムな数値を共有しておく」という方法があります。そして、そのランダム値を salt 的に使います。つまり、生成した共通秘密鍵を直接使わず、共通の salt を加えてハッシュ関数を通したものを最終的な共通秘密鍵とするなどです。

これにより、中間者を通すと自分以外は誰も復号できない状態になるので、異常を検知する手助けになります。TOTP といった、2 要素・・認証が重視される理由も見えてくるのではないでしょうか。

手前味噌ですが、Go 言語で手軽に TOTP を実装するパッケージに、ECDH 鍵交換機能を付けたものをリリースしています。

https://github.com/KEINOS/go-totp @ GitHub

これは、ECDH 鍵交換で生成された共通秘密鍵を TOTP の秘密鍵に利用して、Alice と Bob が同じパスコード（有効期限のある n 桁の数値）を発行できるものです。この仕組み自体は中間者攻撃を回避できませんが、このパスコードを SALT 値として利用することで、制限時間付きの要素に使えます。かなりニッチな機能ですが。

このような、秘密鍵や共通秘密鍵を直接使わず、一旦それらをハッシュ関数に通したものを使ったり、salt 値を加えるという手法は、そこかしこで使われます。

そして、salt の概念をベースにしているものの、用途が異なる場合、各々に名前が付いていたりします。

例えば MAC（Message Authentication Code）などです。「塩を加える」という概念を持つと、読んでいて「あー。なるほど」と思えることが多いです。

ところが、せっかく塩・胡椒をして独自の味付けをしたのに「同じ味や歯ごたえなのに実は合成肉だった」みたいな、なりすましが発生するご時世になってきました。

詳しくは後述の「MD5 と SHA-1 のセキュリティについて」でも説明しますが、塩・胡椒しただけの粗挽き肉ではグルメセキュリティ重視の人を唸らせることは難しくなってきているのです。

データの「指紋」としてハッシュ値を使う

ハッシュ関数はセキュリティ用途ばかりがクローズアップされますが、「処理」に目を向けると「数値で返ってくる」という特徴はデータの管理に活かすことができます。

ハッシュ値の王道の使い方は「変更の検知」です。１バイトどころか１ビットでも違いがあるとハッシュ値の結果は大きく変化します。この特徴により、大量の文書（データ）であっても１文字の変化を検知できるのです。（変化した場所の特定は別の話し）

この「本編を詳細に見なくてもザッと見るだけで把握できる」的な意味で「ハッシュ値」を「ダイジェスト値」もしくは「メッセージ・ダイジェスト」と呼ぶこともあります。また「ハッシュ関数」は「要約関数」とも呼ばれますが、個人的に「『要するに...』と言われても、まったく意味がわからないのと似た関数」だと思っています。

むしろ、海外ドラマなどの冒頭で流れる「前回までのなんとか」のダイジェストのように「以前が何であったか、わかっている人にしか伝わらない確認をするためのもの」といったイメージです。

^{🐒 「ハッシュ値」「メッセージ・ダイジェスト」どちらも同じものですが、暗号関連などの確認に使う場合に「ダイジェスト値」と呼ぶことが多い気がします。この記事では「ハッシュ関数」の値という意味で「ハッシュ値」と統一します。}

「データに変更がないか」の、最も一般的なハッシュ値の活用方法は、おそらくダウンロード・ファイルの確認でしょう。

ZIP や ISO といった巨大なアーカイブ・ファイル（複数ファイルを１つにまとめたファイル）をダウンロードする際に、リンクと一緒にファイルのハッシュ値が添えてある、アレです。ダウンロードしたファイルのハッシュ値と比べることで、破損もしくは改ざんされていないことが確認できます。

逆に言えば、「ハッシュ値が同じであれば、データに変更はない」という使い方でデータの管理にも利用できます。

みんな大好き git などは、ファイルの diff のハッシュ値を比較して変更があったかを検知しています。アプリやライブラリなどの管理で、いつもお世話になっているパッケージマネージャーも、競合や改ざんを防ぎつつ共通の動作をさせるために ライブラリ名<ハッシュ値> のような形式で内部管理していたりします。

他にも、BitTorrent（P2P 型ファイル転送システム）や後述する IPFS（P2P 型分散ファイルシステム）などは、ネットワーク上に「名前は異なるが、実は中身は同じ」ファイルがあってもファイルのハッシュ値を使うことで同等に扱えるようになっています。

身近なところでは、Web サーバーなどに画像やファイルがアップロードされた際、既に同じものがあるかをファイルのハッシュ値で確認をしたりもできます。

これを応用して「微妙に異なるが、ほぼ似たようなデータ」が多いものなどは、ストレージ（データの保存先）の容量を節約することもできます。

例えば保存したいデータを n バイトごとに分割して、分割された状態で保存します。次に、分割されたデータのハッシュ値を算出し、バイナリ・ツリー（1 つの親に対し 2 つの子を持つ）構造で各々ハッシュ値を算出して、ファイル全体のハッシュ値を出します。最後に、それらの値を DB などで管理します。

ハッシュ木 @ Wikipeida より

これにより、類似データを保存する際に、既存の共通する分割データは保存せず、異なるデータだけを保存すれば容量を節約できるという考え方です。後述する IPFS は、この仕組みをデータの取得にも応用したものです。余談ですが、MD5 や SHA2 といったハッシュアルゴリズムも、この考え方をベースにしています。

このように「ファイル名が異なっていても、中身が同じファイルであった場合はハッシュ値は同じ」ということを、逆手に利用したデータの管理方法に使えます。

そのため、ファイルの中身を特定する目的で作成されたハッシュ値を「フィンガー・プリント」（指紋）と呼ぶこともあります。

ハッシュ関数がセキュリティ目的が多いのは、指紋と同じで「識別 ID として使えるから」なのです。

するどい人は「え？じゃあ、電帳法とかの、電子取引データを保存する際の訂正・削除・改竄かいざん防止対策にもハッシュ値って使えるんじゃねーの？」とお気づきでしょう。

預言者の予言を担保する（当たるとは言ってない）

さて、この「ハッシュ値が同じならデータに変更はない」仕組みをさらに工夫すると、「俺様」電子証明書が作れます。「電子署名」でなく「電子証明書」です。

どういう事かと言うと、「ハッシュ値」と「公開鍵・秘密鍵暗号」を組み合わせることで簡易的な電子証明書が作成できるのです。

つまり「内容が同じものである」ことを証明できるのです。（内容が信用できるとは言ってない）

具体的に言うと、ファイルのハッシュ値を自分の「秘密」鍵で暗号化して公開すれば、それが俺様電子証明書になるのです。

まずは暗号化にも使う公開鍵と秘密鍵を使った、なんちゃって証明書の作成方法です。

1. 自分が正しいと認めたファイルのハッシュ値を自分の「秘密鍵」で暗号化し、それを「証明書」としてファイルと一緒に公開し（相手に渡し）ます。
2. 相手は、そのペアとなる「公開鍵」で証明書を復号して対象のファイルのハッシュ値と比較します。
3. 同じハッシュ値であれば、相手は「自分が認めたファイルである」ことが確認できます。

これは公開鍵・秘密鍵の「片方の鍵で暗号化したものは、もう片方の鍵でしか復号できない」という特徴を活かした手法です。

ここで「別にハッシュ値じゃなくてもファイル自体を秘密鍵で暗号化すれば、（復号できたら）それ自体が証明になるじゃないか」とお気づきかもしれません。

鋭い。

確かに、なんちゃって証明書では「ファイルのハッシュ値の計算」→「証明書の復号」→「ハッシュ値の比較」と確認するのに、いささか手間がかかります。

公開鍵で復号できたら一発で確認できるのですが、問題は「暗号化」です。

というのも、復号の処理はハッシュ値の処理より負荷（時間）がかかります。しかも、ファイル・サイズが無駄に大きくなります。ギガ単位の大きなファイルの場合は、特に顕著です。

「誰がアクセスしてもいいけど、自分の提供したファイルだとユーザーが確認できるようにしておきたい」場合の方が多いため、一般公開データを暗号化して提供することは（あることはありますが）少ないです。

とは言え、ハッシュ値を使うにしても、証明書の確認に 3 ステップかかるのは手間ではあります。

... ... どうしよう。

そこで出てくるのが、両方のいい所どりをした「デジタル署名」です。

データのハッシュ値を秘密鍵で暗号化し、公開鍵で復号したハッシュ値が実際のハッシュ値と合致した場合、その公開鍵の所有者が認めたファイルであるという考え方が基本ではあるものの、工数が多いのが問題です。

そこで、「ファイル」と「秘密鍵」をハッシュ関数に通してゴニョゴニョしたものを「署名」とし、確認側は「ファイル」と「公開鍵」と「署名」のデータからハッシュ値を算出し、同じであれば「署名」は有効と判断する方法があります。

ここでのポイントは「秘密鍵もハッシュ値も署名も数値である」ことと、「署名に必要な公開鍵、秘密鍵はランダムな数値でも構わない」ということです。

もう少しザクっと説明すると、「電子署名」は秘密鍵から作成した署名鍵と、Siglet と呼ばれる小さなデータをセットとした 64 バイトのデータです。Siglet とは、ハッシュ値・秘密鍵＋署名鍵で算出された値です。使われるハッシュ値は、署名鍵の一部とファイルをハッシュ関数に通したものです。

確認側は、ファイルと署名鍵をハッシュ関数に通し、ハッシュ値・公開鍵＋署名鍵 で Siglet 値と同じか検証することで確認します。

暗号化・復号を使わずともハッシュ値を出すだけでよく、計算量も少なく速いので、現在はこの手法がメジャーです。この手法をシュノア署名と言います。

ここで重要なのが「署名」という単語の再認識です。

「署名」は英語で言うと「sign」です。日常では「社長、ここにサイン捺印ください」という、アレです。

社長がサイン捺印することで、「社長が認めた書類」という意味を持ちます。そして、社長のハンコが誰でも使えたり、押せたりすると意味がありません。そのため、社長印や会社印は金庫にしまってあると思います。

しかし、重要なのはハンコではなく「その人が認めたものである」と証明できることです。そのため、手書きのサインでもいいし、拇印でもいいわけです。

電子署名も同じです。「その人が認めたものである」と証明できれば、何だっていいのです。

確かに、電子署名に使うハンコ（鍵）は大事にしないといけないので「秘密鍵」という言い方をします。しかし、だからと言って「秘密鍵で電子署名する」というのは暗号化するというわけではありません。

くどいですが、「秘密鍵Key」というのは、value（価値）を引き出すのに必要な非公開の値です。そのため、暗号化用の秘密鍵でなくても、ランダムな数値でも構わないのです。

公開鍵・秘密鍵による署名では RSA 鍵を使った署名が有名ですが、これは「たまたま」暗号用の鍵が署名に使えたというだけで、「署名は RSA 鍵で行うもの」というわけではありません。

最近では git などでも移行が進んでいる、シュノア署名の 1 つの Ed25519 が主流になりつつあるようです。（RSA と Ed25519 の強度の違いは、後述する IPFS で軽く説明します）

閑話休題。

さて、検証や証明にハッシュ値を使うメリットはデータサイズを小さくできるだけに過ぎません。

秘密の鍵をベースに作成され、不特定多数が公開された鍵で確実に確認できれば、何だって署名（サイン）となります。別に鍵が暗号化用の鍵でなくたっていいのです。

あとはプロトコル双方の合意の問題です。

どのような方法にせよ、電子証明は「本物同一のものであることが証明できればいい」ので様々な手法があります。

署名の例として、GitHub などのリポジトリや、OS などのリリースページで、リリースされたファイルと共に *.sha256 *.sha256.sig といったファイルがあったりしますが、それらです。

*.sig 以外の拡張子もあります。しかし、いずれもファイルのハッシュ値を羅列したリストと、そのリストを署名したファイル（*.sig や *.gpg など）のセットが大半です。

• 大容量のファイルを担保するために、ハッシュ値のリストと、それを署名した例 | 22.04 @ Ubuntu リリースページ

署名ファイルがある場合は、リポジトリ・オーナーが「対象のファイルが正式なものであるとサイン（署名、signサイン）した」という意味で、*.sig ファイルが捺印のような役割を持ちます。そして、捺印と判子を透かして照会する役割をするのがリポジトリ・オーナーの公開鍵です。

ここで復習ですが、重要なのが署名ファイルは安全性を証明するものではないということです。

あくまでも代表者や著者自身が「認めたものである」というサインをしたものなのです。そのため、サイン（*.sig）があっても、盲判、俗に言う「めくら印」である可能性もあるため、必ずしも「安全である」とは言えないことを念頭に置きましょう。

それでもサイン（署名ファイル）が「ある」「なし」では、あった方が安心感が違います。同じ書類でも社長印が押されたものと、そうでないもののような違いです。

マスター、うんちくはいいから早く食えるものをくれ

以下が具体的な署名（サイン）の仕方と検証の例です。

*.sha256 が各ファイルの（SHA2の 256,SHA256 による）ハッシュ値一覧で *.sha256.sig がその署名ファイルです。

$ # ハッシュ値の算出
$ openssl dgst -sha256 sample.txt >sample.hash

$ # 「秘密」鍵で署名（sign, signature）
$ openssl rsautl -sign -inkey privatekey.pem -keyform PEM -in sample.hash >sample.sig

$ # 「公開」鍵で検証（verify）
$ openssl rsautl -verify -inkey publickey.pem -pubin -keyform PEM -in sample.sig

いずれの方法でも、このような、「秘密鍵・公開鍵のペア鍵の作成」「証明書の作成」「復号および検証」といった一連の仕組みを総合して「デジタル署名」と呼びます。証明書の作成は、これらの応用でしかありません。

デジタル署名の面白い使い方としては「予言の書」などがあります。

事前に予言と予言した日付を書いておき、「秘密」鍵で暗号化したその予言（ファイル）と、その電子証明書を同時に公開します。そして予言後に「公開」鍵を公開するなどです。まぁ、予言なので普通に公開しちゃっても良いんですけど。

上記コマンドのように、ファイルをデジタル署名することは難しいものではありません。

ファイルを秘密鍵（非公開値）で署名して、公開鍵（公開値）を公式な場所に公開すれば、何にでも「公式なもの」として示せます。

後述する NFT でも述べますが、デジタル作品の作家の方には、自身を守るためにも鍵の作成と署名の仕方は、ぜひ覚えてもらいたい仕組みです。

肥大化しないパターン ID

「引数がどれだけ長くても、ハッシュ値は固定長の数値」であることもメリットです。つまり、データがそれ以上増えないということです。

例えば、Web サイトのページ遷移せんいのパターンを固定長の ID にすることもできます。

$list_url_visited=[
  'http://hoge.com/p1',
  'http://hoge.com/p6',
  'http://hoge.com/p4',
  ...
];

asort($list_url_visited); //配列をソート
$string     = implode(' ', $list_url_visited); //配列を文字列に結合
$id_visited = hash('md5', $string); //文字列をハッシュ化

• オンラインで動作を見てみる@ paiza.IO

この行動パターンに固定長の ID を振れるメリットは機械学習などにも応用できます。

身近なところでは、リンクを開こうとして URL を見るとやたらとハッシュ値っぽいものがあるのを見たことがあると思いますが、アレです。

なぜなら、ハッシュ値は数値なので機械学習における「離散値」の特徴量としても使えるからです。

もちろんページ遷移だけでなく、5x5 ピクセルや 10,000x10,000 ピクセルといった、どんなサイズのピクセル・データにも固定長の ID を振ることもできます。

つまり、ハッシュ関数の特徴をよく理解すれば、アイデア次第でさまざまな活用方法がある関数でもあるのです。

そのハッシュ関数やハッシュ値の活用方法の例として「IPFS」と「ブロックチェーン」そして「NFT」をあげたいと思います。

ハッシュ関数と次世代ファイルシステム IPFS の関係

IPFS と言う用語を耳にしたことはあるでしょうか。以前から存在しているのですが、2020 〜 2021 年にかけて色々な理由で話題になったものです。

IPFS は Inter Planetary File System の略で、日本語に訳すと「惑星・・間ファイル・システム」です。

とても壮大な名前で、意味も不明です。しかし、内容はシンプルです。

従来の Web のファイル・システムが「場所」を指定してコンテンツを取得していたのに対し、IPFS は「内容」を指定してコンテンツを取得する、WEB 3.0 時代の新プロトコル。

「（自分で惑星とか言っちゃってるよ）」と感じるかもしれません。しかし、現在のインターネットの起源ともなった ARPANET も「Intergalactic Computer Network」（銀河・・間コンピューター・ネットワーク）が初期コンセプトにありました。

さて、「内容を指定してコンテンツを取得する」と言うのは「コンテンツのハッシュ値を指定して」と同義です。

百聞は一見にしかずなので、以下のリンクを別タブかウィンドウで開いてみてください。しばらくするとコンテンツが表示されると思います（この場合、"Hello, Qiita!" のテキスト）。

• https://ipfs.io/ipfs/bafybeicd7b7mnnlnpvhv5kimfb5vedgslcwe5bgexj7olcszncnyzvp4oi

詳しくは後述しますが、上記の bafy...p4oi がコンテンツのハッシュ値を元に作られた CID と呼ばれるコンテンツの ID です。この CID を IPFS ⇆ HTTP のゲートウェイの 1 つである https://ipfs.io/ipfs/ にリクエストして、コンテンツを表示していることになります。

誰かが閲覧していた場合は、キャッシュが働いてコンテンツが即時表示されます。キャッシュの期限が切れていた場合、HTTP サーバーは IPFS ネットワークに問い合わせて表示します。同じ CID のコンテンツをシェア（PIN 留め）している最寄りの IPFS ノード、もしくは筆者の自宅にある RaspberryPi Zero のノードが問い合わせに反応し、数十秒ほど待つと表示されます。

ここで言うノードとは、P2P ネットワークにおけるピアと同義で、IPFS アプリが動いている端末（マシン）のことです。

サーバーであり、クライアントでもある端末をピアと呼びますが、他のピアから見てサーバー状態（リクエストを受け付けている状態）のピアをノードと呼びます（IN と OUT の接点と考えるといいでしょう）。そして同じサービスを提供しているノードの烏合の集をクラスタと呼んだりもします。この場合、IPFS クラスタです。

先述したように、この bafyb... から始まる数値が CID と呼ばれる、コンテンツのハッシュ値を元に IPFS の書式で表現したものです。

この値だけで Base32（32 進数）で表現された sha2-256 アルゴリズムを使ったコンテンツのハッシュ値を CID v1 の書式で記載したものである、ということがわかります。もちろん、ハッシュ値なので、この値からだけではコンテンツが "Hello, Qiita!" であることはわかりません。

• CID インスペクタで、bafybei...p4oi から得られる情報を見てみる
  • https://cid.ipfs.tech/#bafybeicd7b7mnnlnpvhv5kimfb5vedgslcwe5bgexj7olcszncnyzvp4oi

$ echo 'Hello, Qiita!' | sha256sum
5d3f0b287c036f5941a87a7589c8864d5259cdbf59673fe16681a2688baec652  -

$ echo 'Hello, Qiita!' | ipfs add --offline --only-hash --quieter --upgrade-cidv0-in-output
bafybeicd7b7mnnlnpvhv5kimfb5vedgslcwe5bgexj7olcszncnyzvp4oi

次に、Brave などの ipfs:// プロトコルに対応したブラウザをお持ちの場合、以下のアドレスをアドレスバーにコピペして開いてみてください。

• ipfs://bafybeicd7b7mnnlnpvhv5kimfb5vedgslcwe5bgexj7olcszncnyzvp4oi/

同じデータが表示されたと思います。

「CDN？」「Etag？」「キャッシュ・サーバ？」と思うかもしれません。

まずは「どこにデータがあろうが、存在するならハッシュ値で取得できる」ことがポイントです。

File System と付いていたり、P2P 型であったり、「分散型ファイルシステム」と形容されるので、クラウド風のファイル・ストレージのようなイメージを受けますが違います。

どちらかと言うと git（分散型バージョン管理システム）と BitTorrent（分散型ファイル転送システム）を足して割ったようなものです。

「自分が共有しているファイルを、他の人も共有のサポートをしてくれるシステム」というイメージが近く、IPFS であっても自身のストレージは必要になります。

確かに「自分のストレージは持ちたくない」という場合であっても、git で言う GitHub、GitLab、Gitea のような有料 or 無料の範囲で外部サービスを利用することは可能です。

IPFS の外部ストレージ・サービスとしては Pinata などがありますが、クラウドや VPS などにデータを置き IPFS をインストールするなどの方法もあります。

しかし、忘れてはいけないのが git であっても IPFS であっても外部サービスを使った場合、「本来はローカル環境で管理するデータを、外部に委託してデータを置いているというだけ」ということです。災害時のリスク分散、メンテナンス、利便性を、お金で買っているという認識が大事です。

そのため、IPFS の外部サービスが落ちたり倒産するとデータは消えてしう（アクセスできなくなる）ということでもあります。WEB3 系の勧誘で「IPFS 上にデータがある限り、永遠にデータは消えません」という口上に「嘘は言っていないけど、ダークな誘導がある」と、お気付きでしょうか。

「分散型」を理解する

git の「分散型バージョン管理システム」をはじめ、IPFS の「分散型ファイルシステム」、後述するブロックチェーンの「分散型台帳」や NFT の「分散型所有権管理システム」といった、「分散型」という用語が多く出てきます。

注意しないといけないのは、分散型のメリットを過大解釈して、「分散型」を「非中央集権型」と言ってしまうことです。特に IPFS、 ブロックチェーン、NFT を扱う企業やメディアが使いがちです。

しかし、同じ 「分散型」の先輩である git パイセンの「分散型バージョン管理システム」を知る人は、GitHub がダウンするとニュースになるくらい依存しているのに「非中央集権型」とは変だとお気づきでしょう。

ここで改めて「分散型」という用語を認識する必要があります。

「分散型」（distributed）というのは「メインとなる何かを直接操作・処理しないで、コピーしたものを操作・処理するもの」を言います。

OS のイメージなど、コピーを配布することを英語で「distribute」と言いますが、配布されたものを使うイメージに近いものです。

そのため「拡散型」が適切な訳にも思えます。しかし、ローカルにコピー or 同期してから操作するので「メインがダウンしても、同じものが別の場所にある」という意味で「分散型」と呼ばれます。「リスク分散型」と捉えても良いでしょう。

そういう意味では git を「分散型バージョン管理システム」と呼ぶのがわかりやすい例です。

メインのレジストリ（例えば GitHub）がダウンしたとしても、コピーがローカルにあるので共倒れする（データがメインと一緒に飛ぶ）ことはありません。

本来は、それが git 本質なのですが、問題はローカルにも GIT サーバーを建てずに外部依存（GitHub に依存）してしまい、ユーザー自身が中央集権型にしていることなのです。

さて、IPFS の場合も、特定の共有ファイルを参照すると共有者に直接アクセスして参照せずに、一旦ローカルにコピーしてから参照します。

また、GitHub と GitLab をミラーリングするように、IPFS も参照したファイルをピン留めすることで（pin コマンドで、自分も再共有することで）単一障害点を少なくすることができます。

このように、共有者のマシンがダウンしても自身のローカルに残るため「分散型」と呼びます。

つまり将来、木星から地球のデータに IPFS で時間をかけてアクセスしたとしても、キャッシュ／PIN 留めをしておけば、同じ木星から誰かがアクセスした場合、そのキャッシュを使うことになるのです。これが IPFS が「惑星間うんぬん」と自称している理由です。

「... ...（NAS とかファイルサーバーを参照してプロキシとかでキャッシュするのと同じじゃん）」と感じると思います。

実際に似ています。しかし、IPFS のポイントは「特定の共有ファイルを参照する際の方法」です。

http:// や ftp:// はじめ afp:// file:// といったリソースを取得するプロトコルは、特定のサーバー上のファイルを取得するファイル・システムです。

これを、分散型にして「該当ハッシュ値のファイルを持っているマシンから取得する」というファイル・システムが IPFS プロトコル（ipfs://）です。

つまり「URL」や「ファイルのパス」を指定していたものが、「ハッシュ値」を指定してデータを取得するのです。

http://myhost.com/myusr/mydir/hello_qiita.txt
ftp://myhost.com/myusr/mydir/hello_qiita.txt

$ wget http://myhost.com/myusr/mydir/hello_qiita.txt
$ cat hello_qiita.txt
Hello, Qiita!

ipfs://QmSuyo747aBeA4yzXy354VUH3Z3pUBC3rULAQ5oF62fy5B
ipfs://bafkreic5h4fsq7adn5mudkd2owe4rbsnkjm43p2zm476czubujuixlwgki

$ # CID v0 フォーマットでリクエスト
$ ipfs cat QmSuyo747aBeA4yzXy354VUH3Z3pUBC3rULAQ5oF62fy5B
Hello, Qiita!

$ # CID v1 フォーマットでリクエスト
$ ipfs cat bafkreic5h4fsq7adn5mudkd2owe4rbsnkjm43p2zm476czubujuixlwgki
Hello, Qiita!

これは、IPFS は分散型であるため「だれ」（ホスト）や「どこ」（URL）を指定するのではなく、「なに」（ハッシュ値）を指定することを重視します。逆に「だれ」が重要になるのは、P2P で接続している相手になります。

具体的な IPFS の使い方は後述しますが、まずは同じ「ハッシュ値をベースにしたリポジトリ」同士である git と IPFS の共通点と違いを理解しましょう。

git と IPFS の相違点

分散型バージョン管理システムの git の場合、add と commit コマンドでローカルのリポジトリにファイルを登録すると、その版のハッシュ値（コミット ID、CID）が作成されます。

$ echo 'Hello, Qiita!' > hello.txt

$ git add .
$ git commit -m "initial commit"
[main (root-commit) 312eb0b] initial commit
 1 file changed, 1 insertion(+)
 create mode 100644 hello.txt

$ git log
commit 312eb0bf67d49b3107eaccaeb0b0f1fe3f0ae5a9 (HEAD -> main)
Author: KEINOS <github@keinos.com>
Date:   Sun Sep 15 18:58:04 2024 +0900

    initial commit

また、push すると登録したファイルが git レジストリ（GitHub や Gitea などの git リポジトリ置き場）に反映・公開（シェア）されます。そして他のユーザは pull した後、その CID（コミット ID）を叩けば同じ版を確認することができます。

分散型ファイル・システムの IPFS の場合も似ており、ファイルを add するとファイルがローカルのリポジトリに登録されハッシュ値（コンテンツ ID、CID）が作成されます。

$ echo 'Hello, Qiita!' > hello.txt

$ ipfs add hello.txt
added QmSuyo747aBeA4yzXy354VUH3Z3pUBC3rULAQ5oF62fy5B hello.txt
 14 B / 14 B [=========================================================] 100.00%

また name publish すると IPFS ネットワークに、自分がその CID を持っていることが公開されます。

$ # CID が QmSu...y5B のファイルを k2k...ci4 の公開鍵を持つノードから公開した例
$ ipfs name publish QmSuyo747aBeA4yzXy354VUH3Z3pUBC3rULAQ5oF62fy5B
Published to k2k4r8ovnhyqds4oh2ndfmzjn9oca0104ekiln8dive2pin83chpbci4: /ipfs/QmSuyo747aBeA4yzXy354VUH3Z3pUBC3rULAQ5oF62fy5B

そして、他のユーザは、その CID（コンテンツ ID）を叩けば同じ版のファイルを確認することができます。ちなみに、コミット ID もコンテンツ ID も、同じ CID と略されるのは偶然です。

さて、この時の git と IPFS の違いは、受け取った CID のコンテンツがローカルにない場合の動きです。

git は相手が pull もしくは fetch などでローカルを同期しておかないとコミット ID を受け取っても確認できないのに対し、IPFS の場合は CID を叩いてローカルに該当するファイルがない場合は IPFS ネットワーク上の他のピア（IPFS ノード）に問い合わせてローカルにキャッシュすることで確認できるようになります。

コンテンツ取得までの大きな流れは 5 ステップあります。「ルーターのパケットリクエストみたいなもの」と考えて読むとピンとくると思います。

1. コンテンツの CID を、接続しているピアたちに問い合わせる。
2. 問い合わせを受けたピアは、そのコンテンツを持っている場合は、それを返す。
   持っていないが、持っているピアを知っている場合、該当ピア（ノード ID）を知らせる。持っていないし知らない場合は、他の接続しているピアに問い合わせる。見つかった場合は、一時キャッシュして次回に活かす。
3. CID を持っているピアが特定できたら、該当ピアにコンテンツをリクエストして受け取る。データが大きいため分割化されている場合は、コンテンツの目録を受け取る。
4. 受け取ったものが目録の場合は、接続しているピアたちに分割されたデータ（CID）を持っているか問い合わせる。（2 に戻る）
5. 分散化されたデータを 1 つにまとめ、出力（表示 or 保存）する。

この時の「中間のピア」、つまりリクエストしたピアと、該当する CID のファイルを持っていたピアの「間にいる他のピア」の動きですが、皆が同じ動きをするのがポイントです。つまり、「ローカルになかったら他のピアに問い合わせる」です。

1. リクエストされた CID のファイル、もしくはその一部がキャッシュにある場合はリクエストしてきたピアにデータを渡す。
2. キャッシュにファイル、もしくはその一部がない場合は、さらに他のピアに問い合わせる。
3. 見つけたらキャッシュして、リクエストしてきたピアにデータを渡す。

上記で「その一部が」というのは、ファイルが大きい場合は小さく分割されて管理されるからです。

BitTorrent でいう「リーチャー」（未完成のファイル、もしくは完成まであと一歩のリーチのかかったファイルを持っているピア）みたいなイメージです。

これにより「参照頻度の高いファイル」もしくは「その断片」は色々なピアにキャッシュされるため、総合的にダウンロードが速くなります。逆に「参照頻度の低いファイル」の場合、探し出すのに時間がかかります。ここらへんの動きも BitTorrent などと同じ感覚です。

そうなると、自分のピア（IPFS ノード）のキャッシュが「どの程度ストレージを圧迫するか」と、「ファイルを取得する速度がどの程度なのか」が気になります。

キャッシュ・ファイルの容量

デフォルト標準設定では IPFS は、IPFS リポジトリのあるローカル・ドライブ（パーティション）の空きがなくなるまでキャッシュされます。そして、容量がほぼ一杯になると、古くて参照頻度の低いキャッシュを削除していきます。macOS でいう TimeMachine と同じ考えです。

とは言え、このような Winny 時代にも問題でもあった「肥大化するローカル・キャッシュ」に対してガベージコレクションというオプション（--enable-gc）が用意されています。

IPFS デーモン（IPFS のサービス）を起動する際に --enable-gc オプションを付けると、ガベージコレクションが定期的に実行される設定になります。

デフォルトで 1 時間おきに 90 日以上参照されなかったキャッシュは削除され、自然淘汰されます。これらの時間や容量の設定は ipfs init で作成されたディレクトリ（リポジトリ）の config ファイル（~/.ipfs/config）を編集することで変更できます。

後述する ipfs.io や CloudFlare などが提供しているアクセスの多いピアは 24 時間経過してもアクセスのないファイルはキャッシュから削除しています。

また、BitTorrent で言う「シーダーになりたい」つまり「永続的にキープ（提供）したい」データの場合は 2 通りの方法があります。

1. 普通にデータを IPFS リポジトリにコミット（ipfs add <CID>）する。
2. ipfs pin <CID> コマンドでキャッシュをピン留めしておく。

「ピン留め」とはキャッシュ・データに「削除しないフラグ」を立てることで、その CID を維持できます。

このように、IPFS は BitTorrent と git を足したようなものを公開専用のファイル置き場にしたものというのが、うっすらと見えてきたと思います。

IPFS の速度

IPFS にしたからといってファイルのダウンロードは速くはなりません。しかし、ローカルや、近いネットワークに別のピアを用意したり、CDN 、PIN サーバ（キャッシュ・サービス）を使うことで速くすることは可能です。IPFS のメリットは「誰かしらがファイルを持っていてくれたら必ず探し出せる」という点と、「しょぼいマシンで共有しても、使う人が多ければ多いほど負荷が下がっていく」の 2 点です。

分散型（P2P）の神話に「分散型にすると速くなる」があります。

分散型にすると速くなるというのは「特定の目線においては正しい」のですが、恵まれた環境、特に光回線が進んでいる日本国内においては必ずしも速くなるとは言えません。

「BitTorrent を使うとダウンロードが早いと聞いたのに、思ったより速くない」と感じた方も多いのではないでしょうか。

実は IPFS も同じです。

まず、アクセス頻度の低いファイルは、探し出すのに時間がかかります。そして、見つかった場合でも特定のピアからダウンロードされるため、そのピアのマシン・スペックや回線速度の影響をダイレクトに受けてしまいます。

逆に言えば、同じネットワーク内の別のピアにファイルがあった場合は、ローカル・ネットワークの速度でファイルをダウンロードできることになります。それでも大きなファイルは分割されて保存されているため、HTTP や FTP などのファイルの丸ごとダウンロードに比べると劣ってしまいます。

それでも IPFS を使うメリットは、災害時含めインフラが弱い（回線が遅かったり、高価なサーバーがない）ネットワークでも、負荷分散できることです。

また、昔の IPFS のサイトには「A peer-to-peer hypermedia protocol to make the web faster, safer, and more open.」といった記載があったので、「IPFS は速い」と勘違いされた経緯もあるようです。誤解を招くため現在は削除されています。

ここで言う faster とは、（CID がわかっていれば）「探し出すのが早い」という意味合いです。つまり「欲しいファイルがわかっているのに、どのサーバーにあるかわからないので、探すのに時間がかかる」という従来の問題に対して、「IPFS なら CID さえわかっていれば、どのサーバーにあるかは関係ない」という意味で faster と言っているのです。

じゃぁ BitTorrent と git でいいじゃん

良いと思います。しかし、IPFS は「WEB（http/https）の代替となる次世代プロトコル」を目指しており、名前だけでなく内容も野心的です。

• 「みんなで共有すればサーバいらない（高負荷に耐えるサーバじゃなくてもいい）じゃん」
• 「コンテンツの ID === hash(コンテンツの中身) なので改竄の心配ないじゃん」
• 「誰かのマシンにデータがあれば、消えることないじゃん」
• 「https と同じようにコンテンツ自体を暗号化しておけば公開ネットワークでもいいじゃん」

と、現在の Web サイトやインターネットの公開情報が持つ問題（例えばデータ改竄や DNS 改竄など）を、「ファイルのハッシュ値を使う」と言う、シンプルかつ大胆な新世代の情報ネットワークを作ろうと言うものです。

• InterPlanetary File System @ Wikipedia
• https://ipfs.io/ @ IPFS 公式サイト

IPFS と、その他のプロトコルの違い

何度か言及していますが、Web における HTTP や FTP などの従来のプロトコルと IPFS が根本的に違うのがコンテンツを取得する概念です。

1. Web（HTTP）の場合は、コンテンツの場所を指定してコンテンツを取得する、つまり「どこ」から取得するかが重要である。
2. IPFS の場合は、コンテンツの中身（ハッシュ値）を指定してコンテンツを取得する、つまり「なに」を取得するかが重要である。

もちろん、この IPFS プロトコル（仕様）以外にも HyperCore プロトコル や ICN など、似たアイデアはあり、多数存在します。

しかし、IPFS は

1. Wikipedia が不当な検閲の回避に使った
2. Brave ブラウザが標準で IPFS プロトコルが使えるようになった
3. Android 版 Opera ブラウザも標準でサポートしている

などにより、注目を浴びています。

何より 👌予算 の使い方が上手く、issue やドキュメント作成に対して懸賞金をかけることでコミッターに還元したりしているので、他のプロトコルよりドキュメントが整っていて使いやすい印象を受けます。

そのため、数あるコンテナ技術のうち Docker が一強になったように、公開分散ファイルシステムの Docker 的なメジャーなものになりつつあります。（たぶん。知らんけど）

つまり、今後はブラウザのアドレスに ipfs://<IPFSハッシュ値> と打てば、このハッシュ値のファイルを持った最寄りのノード（ipfs を立ち上げているマシン）から取得されるようになるのです。このファイルが HTML の場合は静的 Web サイトが表示され、ZIP などのアーカイブの場合はダウンロードが始まると言うことです。

実際に 2021/05/20 現在の時点で Brave ブラウザやモバイル版 Opera ブラウザは標準で実装済みで、Chrome・Firefox・Edge は拡張機能／アドオンをインストールすることで使えるようになります。

• IPFS の URI 例:
  • ipfs://bafkreicnzih5l5beumnqhk4aps5oo7vtfpznbcpo2hhocvftv7wuldpa3q
    _{^{（Brave などの対応ブラウザもしくはプラグインを入れて URI を開いてみてください。"hello, world!" と、以下の URL と同じコンテンツが表示されるはずです）}}
  • https://ipfs.io/ipfs/bafkreicnzih5l5beumnqhk4aps5oo7vtfpznbcpo2hhocvftv7wuldpa3q
    _{^{（この https://ipfs.io/ipfs/ については後述）}}

IPFS の使い勝手

さて、ここからが Qiita 的に IPFS の真骨頂です。つまり「IPFS の使いやすさは、いかほどのものか」というところです。

IPFS 自体はプロトコルなので、それらを使えるように実装されたプログラムが提供されており、大きく GUI 版と CUI 版がります。

CLI で動かせる CUI 版には Go 言語で実装した Kubo（旧 IPFS） と、Javascript で実装された js-ipfs があります。

そして CLI が苦手なら、GUI 版の IPFS デスクトップ版や、ブラウザの拡張機能があります。

Brave などの、ブラウザによっては標準で実装されているものがあります。Brave ブラウザの場合、アドレス欄に「brave://ipfs」と打って「開始する」ボタンを押すと表示される「マイノード」でもデスクトップ版と同じものが表示されます。

とは言え、「IPFS のデスクトップ版」と言っても Electron ベースで、同梱されている ipfs コマンド（Kubo）のビルトイン Web サーバーを表示しているだけなのです。

実は ipfs コマンド（Kubo）はビルトイン Web サーバーを内蔵しているので、これらはそれを表示しているだけなのです。

ブラウザの機能拡張では js-ipfs（Javascript 実装）が使われ、IPFS Desktop では　Kubo（Go 言語実装）が使われている程度の認識でいいでしょう。そして Electron の重さが気になる人は ipfs コマンドを使い、ビルトイン Web サーバーを使うといいでしょう。

さて、この ipfs コマンド（Kobo）は Go 言語で書かれているため、ビルドされたバイナリは単体のプログラムとして動きます。

• go-ipfs | Distributions @ IPFS

つまり、ipfs.exe や ipfs のバイナリをパスが通った先に設置するだけなので、使うのにアレコレとインストールする必要がないのです。

もちろん、手動インストールやアップデートの更新が面倒な人のために brew や choco などのパッケージマネージャー経由でインストールも可能ですし、ipfs-update という ipfs のインストール & アップデート専用ツールもあります。ダウンロードして実行するだけでインストールや更新をしてくれます。

さて、CLI 版（コマンド）の使い勝手ですが、git に似ているものの git より直感的です。

実際に触ってみれば、おそらく「え？これで動くの？」と思うことでしょう。

以下のコマンド・ラインでの実行例をザッとご覧ください。

$ ipfs --version
ipfs version 0.7.0

$ # ipfs リポジトリの初期化。通常 ~/.ipfs に作成される。（専用の秘密鍵＆公開鍵、リクエストした
$ # ファイルのキャッシュなどの置き場）
$ ipfs init

$ # ipfs デーモン（同期機能）の起動。バックグラウンド実行とログ出力付き。これで P2P の 1 つの
$ # ピアとして起動する。
$ ipfs daemon > ipfs.log &

$ # ipfs ネットワーク上もしくはリポジトリ上にあるファイルを開く。ネットワーク上にあった場合は、リポジ
$ # トリにキャッシュする。
$ ipfs cat bafkreicnzih5l5beumnqhk4aps5oo7vtfpznbcpo2hhocvftv7wuldpa3q
hello, world!

$ # 新規サンプル・データの作成（データはテキストに限らず画像などのバイナリでも問題ない）
$ echo 'Hello, Qiita!' > hello.txt

$ # リポジトリにデータ追加。追加したデータのハッシュ値（CID）が返される。
$ ipfs add hello.txt
added QmSuyo747aBeA4yzXy354VUH3Z3pUBC3rULAQ5oF62fy5B hello.txt
 14 B / 14 B [=== ... ===] 100.00%

$ # リポジトリ内のデータ（CID）の公開および通知。戻り値は公開したノードの ID（IPNS の Key）と公開
$ # した内容。
$ ipfs name publish QmSuyo747aBeA4yzXy354VUH3Z3pUBC3rULAQ5oF62fy5B
Published to k51qzi5uqu5dloao8jzqletz2tz06su210ddl0hn7vwo5hoi1an40zs57wjh3y: /ipfs/QmSuyo747aBeA4yzXy354VUH3Z3pUBC3rULAQ5oF62fy5B

$ # 公開したファイルの確認（他のマシンで確認してもよい）
$ ipfs cat QmSuyo747aBeA4yzXy354VUH3Z3pUBC3rULAQ5oF62fy5B
Hello, Qiita!

$ # IPFS ネットワークを HTTP に転送するゲートウェイ経由であれば cURL でも取得できる
$ curl https://ipfs.io/ipfs/QmSuyo747aBeA4yzXy354VUH3Z3pUBC3rULAQ5oF62fy5B
Hello, Qiita!

$ # データを公開した際に得たノードの ID（IPNS の Key）でゲートウェイ経由で cURL してみる
$ curl https://ipfs.io/ipns/k51qzi5uqu5dloao8jzqletz2tz06su210ddl0hn7vwo5hoi1an40zs57wjh3y
Hello, Qiita!

$ # ローカルの HTTP ゲートウェイ経由でファイルを取得（ipfs デーモンが簡易 Web サーバの機能を
$ # 持っています）
$ curl http://localhost:8080/ipfs/QmSuyo747aBeA4yzXy354VUH3Z3pUBC3rULAQ5oF62fy5B
Hello, Qiita!

上記のように、意外に簡単に公開分散ファイルシステムが使えてしまいます。

途中で https://ipfs.io/ipfs/<CID> や https://ipfs.io/ipns/<Key> でもアクセスできることに「（おっ！curl や wget でも使えるってか！）」と感じたかもしれません。

https://ipfs.io/ipfs/ は IPFS ネットワークを HTTPS につなげるゲートウェイの 1 つです。自分でも建てられますし、CloudFlare などの CDN プロバイダーも建てています。

• オンラインで上記のコンテンツを表示してみる
  • https://ipfs.io/ipfs/QmSuyo747aBeA4yzXy354VUH3Z3pUBC3rULAQ5oF62fy5B @ ipfs.io
  • https://gateway.pinata.cloud/ipfs/QmSuyo747aBeA4yzXy354VUH3Z3pUBC3rULAQ5oF62fy5B @ pinata.cloud

CDN を通すと何が良いかというと、キャッシュされていれば CloudFlare の速度で Web サーバー・レスで静的ファイルを提供できるということです。つまり後述する Raspberry Pi や使っていない PC などにコンテンツを突っ込んで IPFS 上で共有して、定期的に URL を叩いておけば、CDN を通して提供できるということです。

ファイルの更新

若干の復習ですが、CID は実質的にコンテンツの内容のハッシュ値なので、コンテンツの内容が変わるたびに CID も変わります。

つまり「そのコンテンツの ID」と言うよりは「そのコンテンツの版（バージョン）の ID」という表現が似合うかもしれません。git で言うところのコミット ID（CID）や、Docker で言うイメージレイヤーのハッシュ値（Image ID）と同じです。

これによりデータの一意性が増すのですが、逆にデータの内容を更新して共有したい場合には CID は適しません。何かを更新するたびに新しい CID を相手に伝えないといけないからです。

この問題を解決する方法の 1 つが IPNS（InterPlanetary Name System）です。

IPNS とは

IPNS（InterPlanetary Name System）は、名前に CID を紐づける仕組み。

これを活用してディレクトリを紐づけるとコンテンツを更新しても変わらない一意のアドレスを作ることができる。

IPNS を完全に理解した気になるためには ipfs name コマンドは何をするのか理解しないといけません。なぜ name なのか、と。

_{^{🐒   説明が長ったらしいので「IPNS は IPFS の PKI の名前空間で、ノードの公開鍵のハッシュ値を名前（Key）に、CID と、ノードの秘密鍵による CID の署名と、公開鍵を Value にして空間に設置し、ディレクトリを CID にすることでディレクトリ内の複数ファイルを共有できる」と言われてピンとくるせっかちさんは次の章に進んでください。私には何を言っているかわからなかったので、この章では、これをかなり咀嚼そしゃくしながら説明します。}}

まずは具体的な動きを見ながら逆算して（紐解いて）いった方が、ちょっとできるくらいには理解できるかなと思います。

コンテンツを登録して、その CID を公開すると、最終的に 2 つのハッシュ値が得られます。① /ipfs/Qm から始まるハッシュ値と、② k5 から始まるハッシュ値です。

下記ログの、ipfs add コマンドと ipfs name publish コマンドで得られた各々のハッシュ値に注目ください。

$ # コンテンツの登録（データをリポジトリに追加。そのハッシュ値が確認できる）
$ ipfs add hello.txt
added QmSuyo747aBeA4yzXy354VUH3Z3pUBC3rULAQ5oF62fy5B hello.txt
 14 B / 14 B [=== ... ===] 100.00%

$ # 追加したリポジトリ内のデータの公開。戻り値はコンテンツの IPNS の Key とコンテンツの IPFS URI
$ ipfs name publish QmSuyo747aBeA4yzXy354VUH3Z3pUBC3rULAQ5oF62fy5B
Published to k51qzi5uqu5dloao8jzqletz2tz06su210ddl0hn7vwo5hoi1an40zs57wjh3y: /ipfs/QmSuyo747aBeA4yzXy354VUH3Z3pUBC3rULAQ5oF62fy5B

2 つ目のコマンド実行結果にある、最初が k5 から始まるハッシュ値ですが、これが IPNS の仕組みだけでなく IPFS の P2P ネットワークが構築される上で重要な役割を果たします。

CID が「何what」（コンテンツの中身）を示すハッシュだとすると、k5 から始まるハッシュは「誰who」（ピアのノード ID）を示すハッシュなのです。

ipfs name publish のコマンドの意味を、もう少し掘り下げましょう。

ipfs name publish QmSuy...中略...fy5B

上記コマンドは、日本語だと
「このノードの名nameにおいて、コンテンツ QmSuy...中略...fy5B を公開publishせよ！ipfs!」
という意味になります。

そして、実行結果は以下のようになります。

Published to k51qz...中略...jh3y: /ipfs/QmSuy...中略...fy5B

上記レスポンスは「k51qz...中略...jh3y に /ipfs/QmSuy...中略...fy5B を公開しました」という意味になります。

IPFS 上の各々のピアは、name と呼ばれる情報のフィールド（項目）を持っています。この値は、各ノードの公開鍵をハッシュ化した値で、これが上記の k5... から始まる値です。そして、この値がノードの ID になります。

上記 Published to ... というレスポンスは、厳密には「ノード ID k51qz...中略...jh3y の秘密鍵で /ipfs/QmSuy...中略...fy5B を署名して、他のノードに公開している旨を通知しました」という意味になります。

逆に言うと、ノード名 k51... にアクセスすると、そのノードが公開している（署名された）ファイルにアクセスできるということでもあります。

これが IPN・S の /ipns/k51qz...中略...jh3y でも取得できる理由です。（詳しくは後述）

このように、特定の IPFS ノードからデータを引き出すために使われるため、ipns で指定するノード ID（name） の値は Key と呼ばれます。変数が Value（価値）を引き出すために Key を指定するようなものです。

概念より、具体的な流れで見てみましょう。「理解した」というかたは、すっ飛ばして構いません。

この Key を使って、ひと工夫するとコンテンツが更新されても変わらないアドレスが作成できます。先に「ひと工夫」の答えを言ってしまうと「ディレクトリを共有する」ことです。

その「ひと工夫」の前に、先ほど公開したコンテンツにアクセスしてみましょう。実際の動作を見ることで、復習もかねて、より正確に理解できます。

まずは CID を使った /ipfs/<CID> でアクセスする方法と、IPNS を使った /ipns/<Key> でアクセスする方法です。どちらも同じ内容が返って来ます。

$ # IPFS の CID でアクセス
$ curl https://ipfs.io/ipfs/QmSuyo747aBeA4yzXy354VUH3Z3pUBC3rULAQ5oF62fy5B
Hello, Qiita!

$ # IPNS の Key でアクセス
$ curl https://ipfs.io/ipns/k51qzi5uqu5dloao8jzqletz2tz06su210ddl0hn7vwo5hoi1an40zs57wjh3y
Hello, Qiita!

次に、同じ手順で同じファイルを更新（内容を書き換え）して、再度公開してみます。つまり、ipfs add で CID を発行したのち、その CID を ipfs name publish で公開します。

この時、Published to の前半の k5 から始まるハッシュ値（Key）は変わらないことに注意します。

$ # コンテンツの変更（内容の書き換え）
$ echo "Hello, I'm KEINOS!" > hello.txt

$ # 変更コンテンツの登録
$ ipfs add hello.txt
added Qme36EKDmxfnhWhFcZQ7pZUnoCLCinxNShS66JwM7z4Fvx hello.txt
 19 B / 19 B [=== ... ===] 100.00

$ # 変更コンテンツの公開（更新の反映）
$ ipfs name publish Qme36EKDmxfnhWhFcZQ7pZUnoCLCinxNShS66JwM7z4Fvx
Published to k51qzi5uqu5dloao8jzqletz2tz06su210ddl0hn7vwo5hoi1an40zs57wjh3y: /ipfs/Qme36EKDmxfnhWhFcZQ7pZUnoCLCinxNShS66JwM7z4Fvx

そして同様に、公開されたコンテンツを cURL で確認してみます。IPNS（/ipns/<key>） でアクセスする方は Key の値が変わっていないことに注目します。

$ # IPFS の CID でアクセス（内容が変わったので、当然 CID も変わる）
$ curl https://ipfs.io/ipfs/Qme36EKDmxfnhWhFcZQ7pZUnoCLCinxNShS66JwM7z4Fvx
Hello, I'm KEINOS!

$ # IPNS の Key でアクセス（内容が変わったのに Key は変わっていない）
$ curl https://ipfs.io/ipns/k51qzi5uqu5dloao8jzqletz2tz06su210ddl0hn7vwo5hoi1an40zs57wjh3y
Hello, I'm KEINOS!

どちらも同じ変更された内容になりました。つまり /ipns/<Key> を使うと同じアドレスが使えることがわかりました。

しかし、1 つ落とし穴があります。

「別のファイルと内容」で、同じように登録 & 公開してみましょう。今度はファイル名を hello.txt から greetings.txt に変えて、内容は定番の "Hello, world!" にしてみます。

$ echo "Hello, world!" > greetings.txt

$ ipfs add greetings.txt
added QmeeLUVdiSTTKQqhWqsffYDtNvvvcTfJdotkNyi1KDEJtQ greetings.txt
 14 B / 14 B [=== ... ===] 100.00%

$ ipfs name publish QmeeLUVdiSTTKQqhWqsffYDtNvvvcTfJdotkNyi1KDEJtQ
Published to k51qzi5uqu5dloao8jzqletz2tz06su210ddl0hn7vwo5hoi1an40zs57wjh3y: /ipfs/QmeeLUVdiSTTKQqhWqsffYDtNvvvcTfJdotkNyi1KDEJtQ 

当然のように CID は変わったのですが、Key は変わっていません。

するどい人は「（あ〜、なるほど）」と、お気づきかもしれません。鈍にぶチンの私は、公開コンテンツにアクセスして「えっ？」となるまでわかりませんでした。てへ

早速、新規公開コンテンツにアクセスしてみましょう。

$ # IPFS の CID でアクセス（CID が変わったが、当然内容も変わる）
$ curl https://ipfs.io/ipfs/QmeeLUVdiSTTKQqhWqsffYDtNvvvcTfJdotkNyi1KDEJtQ
Hello, world!

$ # IPNS の Key でアクセス（Key は変わっていないが、内容が変わった）
$ curl https://ipfs.io/ipns/k51qzi5uqu5dloao8jzqletz2tz06su210ddl0hn7vwo5hoi1an40zs57wjh3y
Hello, world!

なんと、先ほどの Hello, I'm KEINOS! が上書きされてしまいました！

つまり、ターゲットとなるファイルは関係なく IPNS の Key でアクセスできるのは最後に登録された CID のみということです。

1 ページものの静的 Web ページを公開するなら良いのですが、これでは複数ファイルには使えません。かといって、コンテンツごとに別の IPFS ノード（IPFS のデーモン）を用意するのも非合理です。

実は、この Key の値は現在の「ノードの公開鍵Key」をハッシュ化した値です。そのため、何を登録しても Key の値は変わらなかったのです。

$ ipfs name publish <CID>
Published to <Key>: /ipfs/<CID> 

IPNS の NS は Name System とは言うものの、どちらかと言うと Name Space の System（名前空間の仕組み）と考えるとしっくりきます。

IPFS ネットワークには IPNS という名前空間があり、この Key のハッシュ値を「ノードの名前（name）」として使います。

そして、各々の name は Key-Value 型の連想配列のようになっており、値（Value）は 3 つの要素で構成されています。

1. ノードの公開鍵
2. CID
3. CID をノードの秘密鍵で署名した証明書

つまり ipfs name publish <CID> というのは、「コンテンツの公開」と言うよりは、厳密には「コンテンツを署名した name の公開」なのです。

具体的には、ipfs name publish <CID> を実行すると、ノード（name）の「秘密鍵」で CID を署名して IPFS ネットワークに公開（publish）する」というコマンドなのです。

これが /ipns/<Key> でアクセスすると上書きされてしまう原因です。ipfs name publish によって証明している CID が変わってしまったからです。

ここで、いったん落ち着いて「複数の CID を公開する」場合を考えると、2 つの方法が考えられます。

1. ipfs name publish する際に複数の CID を指定する。
2. コンテンツごとに新しい公開鍵と秘密鍵のペアを作成して使う。

前者は、ディレクトリに複数コンテンツを入れておき、ディレクトリを ipfs add することで、まとめて 1 つの CID にできます。また、1 つの鍵のペアで済むため、管理が楽になります。

しかし、全てが同じグループ（ディレクトリ）になってしまうため、異なる内容も含めてしまうと、ファイルやディレクトリ構成が煩雑になるというデメリットもあります。（ちなみに、ディレクトリ下のファイルにアクセスするには /ipns/<Key>/<ファイル名> とファイル名でアクセスできます）

後者は、管理は煩雑になりますが、前者の「ディレクトリ」の仕組みと組み合わせると、内容のグループごとに鍵のペアを作成しておけば、ファイルやディレクトリ構成が綺麗になるというメリットがあります。

_{^{🐒 ちなみに鍵のペアを作成するコマンドは ipfs key gen です。詳しくは ipfs key --help をご覧ください。}}

Web3.0 時代の Web サーバを建てずに Web サーバを建てる

この、ipfs name publish によるディレクトリの公開を、CDN と従来の DNS の仕組みに紐づければ、公開 Web サーバを建てなくても高パフォーマンスの Web サーバを建てることができるのです。

「建てなくても建てられる」とか、何を言っているのかと思うかもしれません。

先に一言で言ってしまうと「HTTP ゲートウェイ自体が Web サーバーだから」です。

つまり、公開したいコンテンツの IPFS ノードさえ立ち上げておけば、HTTP ゲートウェイ経由でアクセスできるのです。そして、HTTP ゲートウェイが CDN であれば、2 度目以降のアクセスはキャッシュされるので、自分のノードの負荷を減らせます。

何はともあれ、Wikipedia 英語版の 2016 年のスナップショットをご覧ください。ipfs.io cloudflare-ipfs.com どちらの HTTP ゲートウェイからでもアクセスでき、同じ内容を参照できますが、どのノードにあったコンテンツかはわからないことに注目です。

• ipfs://QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco/wiki
  • https://ipfs.io/ipfs/QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco/wiki/

とは言え「静的ページだし ... CID 叩いてるだけだし ... まぁ、そうだよね」という感じでしょう。

やはり、ドメイン依存の我々からすると俺様ドメイン独自ドメインで ipns/<KEY> を公開したくなります。

例えば、俺様ドメインの https://oresama.sample.com/ にアクセスすると /ipns/<MyKey>/ で共有している俺様ディレクトリを参照させる、といったことです。

後述しますが IPFS ノードは RaspberryPi Zero でも建てられます。また、前述したように IFPS デーモンは標準で HTTP ゲートウェイ（IPFS → HTTP）を持っているので、自宅のルーター設定で俺様 IPFS ノードに HTTP ポートを向けて解放して、Dynamic DNS ツールなどを使えば公開できます。

しかし、この HTTP ゲートウェイを公開して共有するのは昔ながらの自鯖（自宅サーバ）の方法です。

つまり、ルータの設定や自鯖のパフォーマンスが問われ、何より不特定多数が自宅のルーター経由でアクセスしてくるため避けたいものです。

HTTP の世界において、アクセス過多や不正なアクセスを防ぐ 1 つの方法が CDN を利用することです。これを俺様ノードのゲートウェイ（出入り口）として活用するのです。

つまり、フロントエンドを CDN に設定することで、自分のノードにリクエストするのは CDN だけに絞られ、キャッシュ・サーバーとして働くので自分のノードの負荷は減ります。つまり、ラズパイ Zero 程度のマシンでも、サーバーを建てられるのです。

「（いや。サーバ公開してんじゃんwww）」と思うかもしれません。... ... 確かに。

でも、自宅では IPFS のノードだけで、外部に HTTP のポートを公開していないことに注目です。

CloudFlare を例にすると、以下のような設定をします。

1. 俺様ドメインの DNS 設定
   1. CNAME を CloudFlare の HTTP ゲートウェイに向ける（cloudflare-ipfs.com）
   2. TXT に dnslink=/ipns/<MyKey> を追加する
      • 参考: Connecting Your Website | IPFS Gateway @ developers.cloudflare.com

これだけで、https://mydomain.com/sample.html とアクセスがあった場合、https://cloudflare-ipfs.com/ipns/<MyKey>/sample.html にアクセスした場合と同じになります。そして CloudFlare は ipns/<MyKey> が共有している sample.html を取得 & キャッシュし表示します。

この仕組みを DNSLink と言います。

この時のポイントは、俺様 IPFS ノードがあるネットワークのルータの設定をいじる必要が（基本的に）ないことと、一度アクセスすれば CloudFlare だけでなく IPFS ノードから自宅までの中間の IPFS ノードにキャッシュされることです。

つまり、低いスペックのマシンでも専用機にするなら IPFS デーモンを十分走らせることができます。

何より、CloudFlare 経由の HTTP 接続でなくても IPFS 対応のブラウザなどで /ipns/<MyKey>/sample.html とアクセスする際も CloudFlare のノードのキャッシュを使ってくれるなど、いいとこ取りです。

「（でも静的ページのみで動的ページのコンテンツは公開できないじゃん）」と思うかもしれません。そういう方は WebAssembly を掘り下げてみてください。

外部に向けたサーバを建てなくてもコンテンツを公開できるこの IPFS の仕組みから、何か色々と見えて来たのではないでしょうか。

さらに、この IPFS の技術と、後述するブロックチェーンと組み合わせるなど、なさらなる色々な技術（マッシュアップ）が産まれようとしています。

いよいよティム・バーナーズ＝リーさんの言う「セマンティック・ウェブ」もしくは Web 3.0 の時代が来つつありそうです。たぶん。知らんけど。

プライベートな IPFS ネットワーク

IPFS は、基本的に公開文書向けのネットワークとして始まったのですが、やはり「プライベートな分散ファイルシステムとして使いたい」と思うかもしれません。

基本的には可能ですが、プライベート IPFS は、どちらかと言うとハッシュの話しより、暗号寄りの話しなので割愛しますが 3 行で説明します。

1. IPFS のリポジトリ（.ipfs）直下に共通鍵を置くと通信を暗号化することができる。
2. 同じ共通鍵を持つ（設置した）ピア同士で仮想的なネットワークが作れる。（HTTPS や VPN と似た発想）
3. 共通鍵は ipfs-swarm-key-gen コマンドで作成する。

• 参考文献: IPFS Tutorial: Building a Private IPFS Network with IPFS-Cluster for Data Replication @ eleks

IPFS はラズパイ Zero(W) でも動く

「（IPFS 試してみたいけど、ローカルに入れるには、いささか躊躇ちゅうちょしてしまうな）」という方には、2千円程度で手に入る RaspberryPi Zero W で試されてはいかがでしょう。

Linux と SSH 接続の知識が必要ですが、IPFS 専用機にチューニングすれば十分に使えます。

• 主なチューニング内容
  • GUI なし (RaspberryPi OS Lite)
  • 解像度低め
  • GPU メモリ割り当て少なめ
  • スワップサイズ 2GB

GitHub に IPFS のインストールとアンインストールのスクリプトを置いてありますので、よろしければご覧ください。

• IPFS Installer for RaspberryPi Zero W | IPFS-RPi-Zero @ GitHub
• 参考資料
  • IPFS の Qiita 記事 @ Qiita カテゴリ
  • IPFS 入門 @ decentralized-web.jp
  • Raspberry Pi Zero W の価格 @ スイッチ・サイエンス
  • ヘッドレス RaspberryPi ZeroW のブートディスク作成（Wi-Fi 設定済み SSH 有効済み）と設定 @ Qiita
  • QiiCipher | GitHub 上の公開鍵を使ってファイルの暗号化と署名確認、ローカルの秘密鍵で復号や署名をするシェル・スクリプト @ GitHub

ハッシュ関数とブロック・チェーンの関係

• ブロックチェーンの今北産業
  1. 分散型の追記専用データベースである。
  2. 既存データの変更（改ざん）防止は、上書き禁止といった設定や運用ではなく、仕組みそのもので追記しかできないようになっている。
  3. 分散化および検証への貢献にインセンティブを設けることで、データの永続化が期待できる。

さて、ちょいちょい出てきた、仮想通貨（暗号資産）で有名なブロック・チェーンですが、その仕組みのベースに使われているのもハッシュ関数です（ハッシュ関数の特徴に関しては前述の「ハッシュ関数の基本と特徴」参照）。

ブロック・チェーンを、恐れずに一言で表すと「実質的に変更や改竄かいざんができない分散型のログ変更履歴」です。

もしくは「一度書き込んだら変更できない、追記と読み取り専用のデータベース」です。

変更を行いたい場合は、住民台帳や銀行の口座などと同じで「追記により調整」します。例えば、7 というデータを 5 に変更・修正したい場合は、-2 というデータを追加して調整します。

この追記型の記録方式を「台帳」と呼びます。ブロック・チェーンを「分散型台帳・・」とも呼ぶのは「変更は追記のみによって行う」という台帳の概念と同じだからです。

つまり、一度書き込んだデータは読み取り専用になるという機能自体は、CD-R のような、35 年以上前からある WORM (Write once read many) と変わりがありません。

そして「分散型ロギング・システム」と呼ばれないのは、そのログ（記録）に「紐付けたいデータのハッシュ値」を記録することで外部データとの紐付けも行えるからです。

しかし、そこ（ハッシュ値によるデータの紐付け）がブロックチェーンにおけるハッシュ関数のキモではありません。分散型で紐付け式に特化した DB 自体は etcd などに代表される KVS があるからです。

後述しますが「実質的に変更や改竄かいざんができない仕組み」の実質的な部分にハッシュ関数が使われています。

ブロックチェーンとgit

さて、変更を積み上げていくという意味でも、git（分散型バージョン管理システム）などと同じ「変更履歴の DB」の一種と考えると良いでしょう。

しかし、ブロックチェーンの場合は、git などのように --amend と懺悔ざんげして過去を無かったことに仕組み上できません（変更できない仕組みも後述します）。

また「分散型・・・台帳」の「分散型」というのは「データをメインからローカルに同期してから使う参照する」「データの追加はメインにリクエストして、メインが行う」という意味です。

これも git と理屈は似ています。

リモート・リポジトリを直接参照するのではなく、ユーザーは同期されたローカル・リポジトリを参照し、変更はリモート・リポジトリにリクエストして、無事マージ反映されると他の人にも同期されていくのと同じです。

マージ（変更の追記）ですが、git の場合、マージ権限を持つのはリポジトリのオーナーや、権限をもつコラボレーターです。

ブロックチェーンの場合は、参加しているノードのうち「リーダー」と呼ばれるノードが追加の処理を代表して行います（リーダーは多数決により適宜決まります）。そして他のノードは、リーダーの DB 変更に追随して、ローカルの DB を参照します（ノードとは、ここでは DB を管理しているマシンを指します）。

また、マージ前の追記内容の確認（レビュー）ですが、git の場合は、マージ権限を持った管理者が行います。ブロックチェーンの場合は、CI による自動マージに近いです。リクエストされた追記内容（数値の増減など）に不等号がないと他のノードから判断された場合は、早い者勝ちで登録（追記）されます。

この時の「不等号がないか」の確認は、サービスによって異なります。

例えば、ブロックチェーンが仮想通貨などの暗号資産のサービスに使われている場合は、「口座残高を確認する」などの確認です。

実際の確認は自動で行われますが、手動でも確認可能です。暗号資産の DB（ブロックチェーン）そのものをダウンロードして確認してもいいのですが、データサイズが大きかったり、DB クラスターの一員にならないといけないなど、煩雑です。

たいていのブロックチェーンは API を提供しているので、Web API を経由して確認するのが、手動の場合は楽でしょう。その 1 例として、Solana のブロックチェーンを利用した暗号資産の 1 つである SOL の筆者の口座をご覧ください。

• KEINOS の SOL ウォレットをオンラインで見る @ explorer.solana.com

2023/02/27 現在、たったの 1.19 SOL しか残高がないことが確認できます。また、History で口座間の移動の履歴も確認できます。

ここでは、仮想通貨うんぬんではなく、ブロックチェーンの仕組みにより、この History は「追記はできても変更や改竄かいざんはできない」という点に注目してください。

ブロック・チェーンでは「変更不可能」を実現するために、以下の３つのハッシュ関数の特徴が活かされています。

1. 非可逆である（元に戻せない）
2. 同一性（同じものであること）が確認できる
3. 衝突を探すのは大変だが、探したものを確認するのは簡単

ここで言う「衝突」とは「異なる値なのにハッシュ値が同じになっちまった」という状態です。業界用語で collision と言い、発音はチョッと照れる感じで「これじゃん？」寄りに「コリジョン」です。

しかし、ブロック・チェーンの何が「すごい」のでしょう。

「中央集権型に依存しなくていい」とか「お金に変わる何とか」とか聞きます。しかし、エンジニアを続けていると peer-to-peer（or 分散型）が必ずしも良いわけではないことを体感していたり、メンコとかトレーディングカードとかと何が違うのか、と。パチンコやスロットの換金コインと何が違うのか、と。「世間との熱量の違い」を感じてしまいます。

恐らく、エンジニア的にブロック・チェーンが面白いのは「ビザンチン将軍問題」もしくは「二人の将軍問題」を解決できることかもしれません。

• ビザンチン将軍問題 @ Wikipedia
• 二人の将軍問題 @ Wikipedia

「ビザンチン将軍問題」「二人の将軍問題」の概要

「ビザンチン将軍問題／二人の将軍問題」は、一言で説明すると「A から B へ情報を伝達するルートが信用できない場合に、正しい情報を伝えることができるか」という問題です。

おおざっぱにサーバーで例えると以下のイメージです。

A 国にサーバー A 、B 国にサーバー B があり、お互いの準備が整うと各々「処理 X」を始めます。しかし、どちらかの準備が整っていないで「処理 X」を始めると、核核然然かくかくしかじかな理由で「両国が崩壊する」と仮定します。

問題は A 国と B 国のネットワークが複数の国を経由しないといけないことです。

その経由先には敵対する C 国があるだけでなく、寝返る「かも」しれない同盟国 D 国と E 国もあります。「寝返る『かも』」と言うのは、D 国も E 国もお賃金が安く、役人でさえ小遣い稼ぎで賄賂をもらうような人が多い国である、という設定です。

「準備ができていない」と伝えたのに「準備できた」と伝わってしまった場合、両国が崩壊します。つまり敵対国は中継経路で改ざんするのが狙い目であるため、同盟国といっても安心できないのです。

この、「準備が整った」と伝達するルートの途中で改ざんされる可能性があるのが最大の問題です。

途中の経路が絶対的に信頼できない状態は、まさにサーバー間通信が持つネットワークの問題と同じだと感じると思います。

この問題に対して現在ネットワークで使われているのが TLS/SSL 通信です。

HTTPS などの TLS/SSL 通信の場合は、サーバの証明書を通してサーバとクライアントのお互いの秘密鍵・公開鍵暗号から作成された共通鍵を使って、途中で「傍受ぼうじゅ」されたり「改ざん」されることを防いでいます。

しかし、残念なことに復号された内容そのものが「正しいか」まではわかりません。https://〜 で始まるからといって安心できるサイトではないのと同じです。（秘密鍵・公開鍵暗号の概要に関しては、本記事上部にある「ハッシュ関数の基本と特徴」を参照ください）

ここで、著者が発行したデータのハッシュ値も別ルートで送れば「復号された内容が正しいこと」を検知できそうです。しかし、どの通信ルートも信用できないため、そのハッシュ値すら正しいか確信が持てません。

同じインターネットのルートでなく、電話網、トークンキーやスニーカーネットワークといった別の媒体のルートを介して確認することを「２要素・・認証」と呼んだりしますが、肝心の電話会社やトークンキー開発会社も運び屋も信用できない状態です。

話した内容がマスメディアを通すと違っていたり、出版物が勝手に書き換えられたり、決算報告で大丈夫と思っていた銀行や企業が突然なくなったり、ホームセキュリティ会社の社員が隠しカメラを設置していたり、脅されているのか血迷ったのか公文書を改ざんしたりする政治家がいる世の中だと、なおさら確信が持てないかもしれません。

そう考えると、意外にリアルな話だと思います。

パスワード付き ZIP が、なぜか共通鍵暗号として全盛だった時代、メールを送ったら届いたか電話で確認するのが流行りました。

ちょうどその頃、プライバシーマークを取得するため「添付ファイルはパスワード付き ZIP でメールに添付して送り、パスワードは次のメールで同じアドレスに送る」のが企業で流行りました。今で言う失敗した「２段階・・認証」の走りです。

しかし、プライバシーマークに限らず ISO や JIS などもそうですが、規格の認証団体は以下のように要件（チェック事項）は定義するものの具体的な実装方法については言及しません。

「個人情報を含む添付ファイルを取扱う際に、セキュリティ対策（データの暗号化、パスワード設定など）の措置を講じること」（第23条）

そして、プライバシーマーク取得の要件を網羅するため昔の企業が独自解釈で取った手法が、パスワード付き ZIP + 別メールであり、「措置を講じている」としたのです。

この時代から「クライアントが本当に欲しかったもの」系の「嘘は言ってないし、要件は網羅しているよね」と、肩書きや体裁を優先しようとした過去の悪しき習慣の 1 つとも言えます。

もちろん、そんなのはダメちんなので、現在は公開鍵暗号と、ちゃんと・・・・した共通鍵暗号を組み合わせた方法が主流になりつつあります。

また、公開鍵は公開鍵基盤を通して安全に取得できるようになりました。つまり、取得した公開鍵を公開鍵基盤に問い合わせて正しい公開鍵であるか確認できるのです。

しかし「某国の、国が管理している公開鍵基盤」と言われて、本当にそれが「正しい公開鍵」であると確信が持てるのでしょうか。

その認証局、信用できますか？

ここで、先の「ビザンチン将軍問題／二人の将軍問題」がチラついてきます。

現在の SSL/TLS 通信は、認証局を銀行や政府のように「信用するしかない」という状態で動いています。つまり、証明書（公開鍵が正しいものであるかの証明書）を発行する組織や企業を信用するしかないのです。

もし、その組織や企業の担当者が洗脳されたり、幹部が敵対国と手を組んでいた場合、偽の公開鍵の証明書を発行する可能性はゼロではないのです。これは、某北の挑戦的な国の公開鍵基盤を某北の挑発的な国が使いたがらないように、お互いの公開鍵基盤を信用していないのと同じです。

世界の海底ケーブルですら、「どの国にケーブルが引き上げられるか」で揉めるのです。

「別にケーブルの中を通るデータが暗号化されてるんだったら、途中で見られてもいいじゃん」と言うわけには行かないのです。役人ですら、パスワード付き ZIP のパスワードを FAX で送ったり、http と https の違いや CC と BCC の違いを知らなかったり確認しないでフォームに大事な情報を入れちゃうようなご時世ですから。

つまり、「A から B へ重要な機密データを伝えたい」という時に、中間に位置する人がそもそも微妙、ということです。

このように「二人の将軍問題」はネットワークの問題だけでなく、中間に位置するものを信用できない状況で起きる現代の問題でもあるのです。

この「二人の将軍問題」を道徳でなく仕組みで解決できるかもしれないというのが話題のブロック・チェーンです。なんと「賄賂などの小銭で寝返る小悪党を味方にしちゃえばいいんじゃね？」という逆転の発想です。

ブロック・チェーンの概要

ブロック・チェーンは「分散型データベース」の一種です。「分散型」と言われるので P2P 型と思われるかもしれませんが、若干違います。

どちらかと言うと git（分散型バージョン管理システム）における「リポジトリの関係性」や「リポジトリ管理」の仕組み、つまりリポジトリ間のコミットやマージ（データの登録や同期）の概念に近しいものです。

ここでいう「リポジトリ」とは、データと変更履歴がストックされているディレクトリを言います。そして、ファイル・サーバーのようにローカル外でリポジトリを総括している先を「レジストリ」と言います。GitHub、GitLab、Gitee などはレジストリです。

さて、git の場合、メインとなるリポジトリがレジストリにあり、ユーザーはレジストリからローカルにリポジトリをクローン（コピー）して利用します。業界が違うので用語も異なりますが、DB のマスタを同期して利用するようなものです。

ユーザーがデータに変更を行いたい場合は、ローカルのリポジトリを編集し、その変更をメインのリポジトリにマージ（変更データを反映）します。

そして他のユーザーは、メインのリポジトリに変更があると、同期を行うことで変更に追随します。DB のマスターを更新するイメージに近いのがお分かりでしょうか。

実はブロック・チェーンも DB を管理するメインのマシンがあり、データの登録は「リクエスト → 確認 → マージ（反映）」という手続きを経て、そのメインのマシンが行います。そして同じブロック・チェーンの DB を持つマシンは、メインの変更をローカルに同期します。

「えー。じゃぁメインのマシンが落ちたらどうするの？」と思うかもしれません。

ですよねー。

しかし、git を使う一番のメリットは「同じデータが他の環境にもある」という点です。

つまり、メインとなるマシンが飛んでもリカバリできるという、「環境自体がバックアップになっている」という点も大きいと思われます。DB の場合は「運用でカバー」となるのですが、git やブロックチェーンの場合は運用が仕組みとして組み込まれています。

ブロックチェーンの場合は、それに加え「メインとなるマシンを変更する」というのが仕組みとして組み込まれています。

git やブロックチェーンの問題は速度です。

git の仕組みは「変更のリクエスト → 確認 → マージ（反映）→ 同期」といった手続きが必要なため、リアルタイムにデータが変更されるような環境には適しません。「git リポジトリを同期して DB として使う」と言われると、更新速度に懸念が出るのと同じです。

そして、ブロックチェーンも同じです。

DB への書き込み速度を求める場合は、ブロックチェーンなんかより、従来の DB や、身内だけで構成されたブロックチェーン（プライベート・ブロックチェーン）を使う方がいいのです。

ブロックチェーンを使う唯一のメリットは「堅牢な台帳が欲しい」というケースです。RDB のように、データをこねくり回したり、データの変更（列の値の変更）が重要なものには適しません。

ブロックチェーンの総選挙

ブロック・チェーンにも結局「メインのマシン」があり、メインのマシンに登録し、その他のフォロワーが同期すると述べました。問題は、そのメインのマシンがトラブルでダウンした場合です。

実は、このメインのマシンは「リーダー」と呼ばれ、選挙制（フォロワーの多数決）で適宜決まります。

現在のリーダーのマシン（ノード）が落ちると、即座に選挙が始まり次のリーダーを決定し、他のノードはフォロー先を変えるのです。

この時に使われる選挙アルゴリズムの 1 つが「Raft」と呼ばれるものです。ブロックチェーンの種類によって選挙アルゴリズムは異なりますが、raft は etcd などの分散キー・バリュー・ストア型の DB でも使われているアルゴリズムです。ちなみに etcd は Kubernetes などのクラスター型のアプリケーションでも利用されています。

• Raft | Raft 公式 @ GitHub
• Raft | EN @ Wikipedia
• etcd/raft | etcd.io @ GitHub

後述するブロックチェーンの「51% 問題」は、この「多数決」にあります。

つまり、フォロワーの過半数が結束すれば次のリーダーを意図的に決定することができるのです。そのため、Raft アルゴリズムだけでは「ビザンチン将軍問題」は解決できません。意図的に指定された特定のリーダーが、改竄かいざんデータを挿入する可能性もあるためです。

台帳とは

ブロック・チェーンを知る上で重要な用語の 1 つに「台帳」があります。

ブロック・チェーンは「分散管理台帳」とも呼ばれるのですが、経理や経理系のシステムに携わったことのある人でないと、「台帳」という単語は馴染みがないかもしれません。実は、「台帳」という単語を理解しないとピンとこないこともあります。

先にも触れましたが、「台帳は追記しかできないデータ・ベース（以下 DB）」です。一度書き込んだら変更できません。

そして、変更をしたい場合はデータの書き換えでなく「変更の追加」をするということです。つまり、「7」という値を「5」に修正したい場合は、「-2」という変更を追加して調整します。経理の台帳で言う「赤伝」（マイナス調整をするための伝票）です。

この仕組みは身近なところで見ることができます。銀行の通帳や国民基本台帳です。貯金額や住所変更は「書き換え」でなく「追記」することで更新します。

ビットコインなどの仮想通貨（暗号通貨）も、DB の最初に作成したコインを登録しておき、それをプラス、マイナスしているのです。

実は、変更のみ追加していく仕組みは git も似ています。

しかし git はデータを書き換えることが技術的にできるのに対し、ブロック・チェーンは仕組み上できません。いや、厳密にはできるのですが限りなく不可能です。これが分散台帳とも呼ばれる所以ゆえんです（なぜ変えられないかは後述します）。

git に慣れている人であれば、ブロック・チェーンは「絶対的に過去のデータを変更できない git のようなもの」と考えても差し支えないかもしれません。

しかし、git と決定的に違うのは「メインとなるマシンは投票で決まり、適宜変わる」という点です。GitHub が落ちたらフォーク先が選挙で GitLab にするか Gitea にするか決めて、フォーク元を一斉に変更するようなイメージです。

また、後述する「何を、どのように登録するか」も、投票や他のマシンの検証により決まります。そして投票で決まった内容が反映されていた場合のみ、他のマシンもローカルを同期します。

つまり、メインとなるノードは「投票で決まったデータの登録をするだけ」という役回りになります。

そのため、メインとなるマシンが落ちても、自動的に他のマシンが投票により決まるため、1 台でも DB を持つマシンがあれば「サービスが消えることがないデータ」を提供できることになります。

となると「どのようにデータを管理するのか」が気になるところですが、ここでハッシュ関数が出てきます。

ブロック・チェーンの構造

ブロック・チェーンの基本構造は割と単純で、「１つのデータが、前のデータのハッシュ値も持つ」というものです。

そして、後述する「プルーフ・オブ・ワーク」（もしくは「プルーフ・オブ・ステーク」）と言う概念とセットとなったものを「ブロック・チェーン」と言います。

ブロック・チェーンは「サトシ・ナカモト」なる日本人と思わしき謎の人物が提唱したと言うのは聞いたことがあると思います。

実際にそうなのですが、厳密には「従来からある 2 つの考え方を組み合わせたものから発想を得たもの」と言えます。以下がおそらくその 2 つです。

1. マークルの木（ハッシュ木）
2. マークルのパズル

ここで、先のハッシュ関数の基礎知識で「塩（salt）は後から足す」の話しに出てきたヒーロー・ロボットのような名前の「マークル・ダンガード」を思い出してください。

実は、この「マークル」はラルフ・マークル氏のマークルなのですが、個人的に「もっと評価されるべき」的な人物だと思います。（いや、業界では超有名人なので一般に認知されるべき人と言うか）

どうもマークル氏は、日本で言えば南部陽一郎さんのような、アイデアをポンポンと投げては他の人に影響させるタイプの人だったらしく、公開鍵暗号の基礎となるアイデアを作ったり、暗号学的ハッシュの元となるマークル・ダンガードを発明したり、ファインマン氏が予言＆提唱した量子コンピュータを「物質を原子レベルの大きさで制御しデバイスとして使う」という「コンピューターと分子ナノテクノロジーの融合のパイオニア」と呼ばれたかと思えば「人体冷凍保存の人」と言われたり。まぁ、それは変な人です。存命の方なので Youtube などでググれば色々な講演が聞けます。

さて、「１つのデータが、前のデータのハッシュ値も持つ」と言いましたが、この構造の概念自体は git のコミットハッシュなど、ブロックチェーン以前から存在しており、そのベースとなるのが「ハッシュ木」です。

そして、「プルーフ・オブ・ワーク」の元になるのが「マークルのパズル」です。

木と言うよりチェーン

ハッシュ木の場合は、木を逆にしたような構造で「子」となるブロックのハッシュを「親」が持つと言うものです。この構造は、複数のファイルや、分割したデータから 1 つのハッシュ値を作成する場合などに使われます。

ブロック・チェーンは、それをシンプルに 1 本にした感じのものです。

各ブロックには「データ」と「ハッシュ値」があり、ハッシュ値は 1 つ前のブロックのデータとハッシュ値をハッシュ化したものです。

このハッシュの値がブロックとブロックのつなぎとなりチェーンになっているため、ブロック・チェーンと呼ばれます。チェーンに見えますでしょうか。

実は、ブロック・チェーンは「データ」に工夫がされており、保存したいデータのフィールドと nonce と呼ばれるフィールドがあります。

nonce って、なんっスか？

nonce（ナンスもしくはノンス）とは「1 度だけ使われる数値」で、"Number used once" とも言われますが略語ではありません。

nonce は、nine（9）や none（なし）の語源にもなった nones から来ています。nones は、ローマ暦が 8 をベースにしていた時代に、都合が悪い時に使った謎の調整値のようなものです。今でいう閏年や閏秒みたいなものでしょうか。

そこから 8 の次の 9（nine）や、存在しないもの（none）に変化しました。転じて「一時的に調整のために使われるもの」を nonce と言うようになりました。〜 for the nonce のようにも使われ、日本語で言えば「とりまとりあえず、、〜なんとか」みたいな時に使う感じでしょうか。

ブロックチェーンでは、nonce は 1 つのブロックと次のブロックをつなげるためだけに 1 度だけ算出される数値です。

Qiita ユーザには下手な概念図で示すより、データで見た方がピンとくるかもしれません。

ブロック・チェーンのデータを JSON 形式で簡略表現すると以下のようになります。hash data nonce の１セットを１ブロックとします。

[
    {
        "hash": "<hash1>",
        "data": "<data1>",
        "nonce": "<nonce1>"
    },
    {
        "hash": "<hash2>",
        "data": "<data2>",
        "nonce": "<nonce2>"
    },
    ...
]

上記の hash、data、nonce の 3 つのキーの内容は以下の通り。

1. hash キーの値は、前のデータの hash と data と nonce の値をつなげてハッシュしたものです。（<hash2> = hash('sha256', <hash1> + <data1> + <nonce1>);)
2. data キーの値は「何かしらのデータ」で平文でも暗号文でも構いません。プログラムのスクリプトであっても構いません。なんなら WebAssembly の WASM バイナリだっていいのです。
3. "nonce" キーですが、これがブロック・チェーンのキモ・・です。

"nonce" は「キー・ストレッチング」の一種です。（「ストレッチング」については、文頭の「塩だけでなく胡椒も足そう」のコメント欄をご覧ください）

つまり "nonce" は、クラッキング（悪いこと目的の操作）に対する「面倒くささ」を加えるための、ひと手間です。この nonce の値を算出することを「マイニング」と呼んでいます。

マイニング（発掘）と呼ぶのは、この nonce の値を最初に見つけ、承認を得られた人は報酬がもらえるからです。ブロック・チェーンがビットコインの場合は、ビットコインがもらえます。

この nonce 値を見つけることが現金につながるだけでなく、みんなのマイニング作業や承認作業によって「データのハッシュ値が正確であるか」を複数人で確認しあっていることになるため、データが堅牢になって行きます。

^{🐒   たまにマイニングを仮想通貨（暗号通貨）そのものを発掘するような意味とも思える記述を見かけますが、違います。}

^{「金を発掘したら俺のもの」的な宣伝が多いのでわかりづらいのですが、どちらかと言うと「レアメタルを発掘したら報酬でお金がもらえる」イメージが近いと思います。ビットコインの場合は「nonce 値」がレアメタルで、「ビットコイン」が報酬のお金です。
仮想通貨自体は１コインごとに、コインの秘密鍵とコインの ID となるハッシュ値がセットになったようなデータで、各コインは 0〜1 の float 値を持っており分割可能です。ビットコインの場合は、1.00000000 まで分割可能です。このコインは、一般的に ICO と呼ばれるステップで作成（発行）され、ブロックチェーンの初期値として登録されます。そこから、ユーザーが購入もしくはもらうことでコインの移動が始まります。
コインの移動と言いましたが、実は物理的なコインが移動するわけではありません。口座振替に近く、「A の勘定から B の勘定へ N ぶんのコインが移動した」という記録がブロックチェーンに記録されることで「コインの移動」となります。そして勘定の口座となるのがユーザーの公開鍵で、公開鍵と紐づいたデータや秘密鍵をセットでウォレットと呼びます。
つまり、「B が A からコインを N ぶん受け取る」と言うのは、A の公開鍵に紐づいている値を N ぶん減らし、B の公開鍵に紐づいている値を N ぶん増やすという処理を両者が署名し、登録依頼をするとマイナーは、その整合性をチェックし nonce 探索を始め、nonce 値が見つかるとメインのブロックチェーン（ノード）に記録され、「取引成立」となります。そして、その取引の差分データが他のノードと同期されていきます。
このように、ウォレットの秘密鍵を持つ者でなければ別のウォレットに移動できません。逆に言えば、秘密鍵を無くしてしまうと、コインを使うどころか、自分のものであることを証明することも、現金化するために換金所のウォレットへも移動できなくなります。つまり、ウォレットの秘密鍵が盗まれてしまえば、移動できてしまうということでもあります。通帳と印鑑や、キャッシュカードと暗証番号が盗まれるようなもので、昨今の暗号資産の盗難は全てこれです。}

^{ノード
ブロックチェーンにおける「ノード」はブロックチェーンのピアのうち「DB の管理をしているピア」です。コイン取引所やメンテナやマイナー（マイニングをする人）などが「ノード」に該当します。各々のノードの DB は同期されており、これがブロック・チェーンを「分散台帳」とも呼ぶゆえん・・・です。「ノード」はネットワークの常時接続やディスク容量が必要といったデメリットもありますが、「ノード」になるメリットはブロックチェーン追加時に報酬のためのコインを作成（発行）することができる点と DB 追加の手数料がもらえる点です。そのため、初期の頃は、ノードとマイナー（マイニング）を兼任するサーバーも多く、これが「マイニング＝コインの発掘」というイメージを産んだ理由でもあります。}

^{いずれにしても、ブロック・チェーンは DB の１種であると考えて差し支えないと思います。そのため、ブロック・チェーンの仕組みは仮想通貨／暗号通貨でなくても活用できます。}

• ^{ビットコインのメールと論文 by サトシ・ナカモト}
• ^{ビットコイン論文からさぐる ブロックチェーンのヒント @ オブジェクトの広場}

ブロック・チェーンは "nonce" センスなゲーム

ブロック・チェーンにおける nonce は、一言で言うと「ハッシュ値の衝突を探すゲームで、最初に見つかった値」です。

このゲームとは「現在の data と hash に、nonce を加えてハッシュ化すると、最初の n 桁が 0（ゼロ）になる nonce の値を探す」といったものです。

// 1 つのブロック・データ
$data = 'something';
$hash = '34902903de8d4fee8e6afe868982f0dd';
$nonce = 'd9'; // <- 見つけた nonce 値

// md5 でハッシュ（$data.$hash.$nonce）
$result=hash(md5, 'something34902903de8d4fee8e6afe868982f0ddd9');

// ゲームの結果確認
echo $result; // -> 00603ea2b0f451d9531b6caeb0e96afb
// result の最初の 2 桁が 0 （ゼロ）なのでクリア！

その桁数や 0（ゼロ）の値などはブロックチェーンによってルールは異なりますが、いずれも nonce を加えてハッシュ化した時に出る値に対するルールです。

nonce を探すイメージを Bash で書いてみました。

#!/bin/bash

# RULE
VALUE_HEAD='0000'
LEN_HEAD=${#VALUE_HEAD}

# Function
function dechex() {
    printf '%x' $1
}

function isValidNonce() {
    [ "${1:0:$LEN_HEAD}" = "${VALUE_HEAD}" ]
    return $?
}

function hash() {
    algo=$1
    value=$2
    echo $(echo -n $value | openssl $algo | awk '{print $2}')
}

# Data
data='something'
hash='34902903de8d4fee8e6afe868982f0dd'
nonce=''

# Mining/Search nonce
counter=0
while true
do
    nonce=$(dechex $counter)
    string_to_hash="${data}${hash}${nonce}"
    hash_temp=$(hash 'md5' $string_to_hash)
    isValidNonce $hash_temp && {
        break
    }
    counter=$((counter+1))
done

echo "Nonce found: ${nonce}"

• オンラインで動作をみる @ paiza.IO

しかし、ブロックチェーンは「一度、生でブロックチェーンを見たら分かる」と言われるくらいなので、全体の流れをプログラムで見た方がピンとくるかもしれません。

PHP で簡単に書いてみました。（実際に触れるようにもしているので、そんなに根詰めて読む必要はありません。この記事は、ざっと流れがわかればおkで、むしろ「用語に見慣れるために読む」程度の意気込みでお読みください）

// ２つ前のブロック・データ
$block_chain[] = [
    'data'  => 'sample1',
    'hash'  => 'a4626f9d3e6802aebbff46697248e0b9',
    'nonce' => 'xxxxxx',
];
// １つ前のブロック・データ（Latest）
$block_chain[] = [
    'data'  => 'sample2',
    'hash'  => '3152851bf5419247cf948e871b0adfe8',
    'nonce' => '32648',
];

// 最初の４文字が 0 である
define('VALUE_HEAD', '0000');
define('LEN_HEAD', strlen(VALUE_HEAD));

/* 検証用の関数 */
function isValidNonce(string $nonce): bool
{
    // ルール：$nonce の頭 n 文字が VALUE_HEAD と同じ( n = LEN_HEAD )
    return (substr($nonce, 0, LEN_HEAD) === VALUE_HEAD);
}

function isValidHashInLatestBlock(array $block_chain): bool
{
    // 現在のブロックの長さ
    $len_block_chain = count($block_chain);

    // ２つ前のブロックのデータ取得
    $key_2block_ago = $len_block_chain - 2;

    $data_2block_ago  = $block_chain[$key_2block_ago]['data'];
    $hash_2block_ago  = $block_chain[$key_2block_ago]['hash'];
    $nonce_2block_ago = $block_chain[$key_2block_ago]['nonce'];

    // 期待するハッシュ値の算出
    $hash_previous_expect = hash('md5', $data_2block_ago. $hash_2block_ago . $nonce_2block_ago);

    // １つ前のブロックのハッシュ値取得
    $key_block_previous   = $len_block_chain - 1;
    $hash_previous_actual = $block_chain[$key_block_previous]['hash'];

    // １つ目のブロックのハッシュ値の検証
    return ($hash_previous_expect === $hash_previous_actual);
}

function getBlockLatest(array $block_chain):array
{
    $len_block_chain = count($block_chain)-1;
    return $block_chain[$len_block_chain];
}

/* １つ前のブロックの検証 */
if(! isValidHashInLatestBlock($block_chain)){
    echo 'Error: Not a valid hash value. Block-chain broken.' . PHP_EOL;
    exit(1);
}

/* 新規ブロックのデータ作成 */
// 追加したいデータ
$data_current = 'sample3';
// ブロックのハッシュ値を計算（１つ前のブロックより）
$block_previous = getBlockLatest($block_chain);
$hash_current   = hash('md5', $block_previous['data'] . $block_previous['hash'] . $block_previous['nonce']);
$block_current  = [
    'data' => $data_current,
    'hash' => $hash_current,
];
echo 'Request to add to the block-chain.' . PHP_EOL;
echo '  Data:' . $data_current . PHP_EOL;
echo '  Hash:' . $hash_current . PHP_EOL;

/* １つ前のブロックの検証 */
if(! isValidHashInLatestBlock($block_chain)){
    echo 'Error: Not a valid hash value. Block-chain broken.' . PHP_EOL;
    exit(1);
}

$data_current  = $block_current['data'];
$hash_current  = $block_current['hash'];
$nonce_current = '';
// Nonce 探索
$i = 0;
while( true ){
    $nonce_current = dechex($i);
    $hash_temp = hash('md5', $data_current . $hash_current . $nonce_current);
    if(isValidNonce($hash_temp)){
        echo 'Nonce found: ' . $hash_temp . PHP_EOL;
        break;
    }
    $i++;
}

/* マイニングの結果（これを検証依頼する） */
echo 'Block Data to add:' . PHP_EOL;
echo '  Data: ' . $data_current . PHP_EOL;
echo '  Hash: ' . $hash_current . PHP_EOL;
echo '  Nonce: ' . $nonce_current . PHP_EOL;

/* １つ前のブロックの検証 */
if(! isValidHashInLatestBlock($block_chain)){
    echo 'Error: Not a valid hash value. Block-chain broken.' . PHP_EOL;
    exit(1);
}

// 発見された nonce の検証
$hash_verify = hash('md5', $data_current . $hash_current . $nonce_current);

echo 'Hash result: ' . $hash_verify . PHP_EOL;
if(! isValidNonce($hash_verify)){
    echo '  Error: Nonce not valid.' . PHP_EOL;
    exit(1);
};

// ブロック・チェーンに追加
$block_chain[] = [
    'data'  => $data_current,
    'hash'  => $hash_current,
    'nonce' => $nonce_current,
];
echo '  Success: New data added to block-chain.' . PHP_EOL;

// ブロック・チェーンの内容表示
echo 'Current Block-Chain:' . PHP_EOL;
print_r($block_chain);

• オンラインで動作をみる @ paiza.IO

上記で重要なのが、マイナー（マイニングする人）の処理にある「Nonce 探索」の while ループの箇所と、データを追加する人の処理にある「発見された nonce の検証」のハッシュ値の計算箇所です。

マイニングの while ループの箇所の箇所ですが、一部のマッチが true になるのか、全文マッチが true になるか以外はマッチ対象が違うだけでハッシュ値の衝突を探す手法そのままです。つまり、総当たりで根性で探しているのです。

実際には文字列の比較でなく、FF000... で and 処理（ビットマスク）した方が速いなどありますが概念的に、こういうことです。😳

^{🐒   実際の「ブロック・チェーン」のデータは高速化なども配慮してもっと複雑です。しかし基本概念は同じです。}

^{また、ブロック・チェーンではデータの塊かたまりを「ブロック」と呼ぶのですが、ネットワークの「パケット」と「フレーム」のように、ブロックと呼ばれる区分けがレベル（レイヤー）によって違います。ここでは仕組みがわかりやすいように「登録したい１つのデータ」を「ブロック」と呼びます。参考として、ビットコインなどは「n 分間の取引データ」を１ブロックと時間単位で区切っています（現在は n=10）。そして登録される個々のデータを「トランザクション」と呼んでいます。}

どのような nonce の探し方であっても、平均して特定の時間前後かかるように 0（ゼロ）の長さのルールが自動調整されます。ビットコインの場合は、およそ 10 分前後になるように調整されます。

反面、探索された nonce の値のチェック（nonce を使ってハッシュ値を出して頭 n 桁が 0 であるかの確認）は、一瞬で終わってしまいます。