クレイグ・ライトが、自分がサトシ・ナカモトであることを皆に納得させるためには、何をする必要があるでしょうか?

数時間前、BBC、GQ、エコノミストがサトシ・ナカモトが再び発見されたと報じる記事を掲載した。このサトシ・ナカモトは、昨年 12 月に発見された人物です。ニュースが報道されたとき、私の最初の反応はフェイクニュースだと思った。なぜなら、クレイグ・ライトには犯罪歴があるからだ。昨年、彼は PGP (注: PGP Pretty Good Privacy、RSA 公開鍵暗号化システムに基づく電子メール暗号化ソフトウェア) 署名を偽造し、期限切れのメタデータを使用して署名を完成させましたが、これは後に全員に発見されました。偽の学位に関するニュース報道もありました。

しかし今回はビットコインのコア開発者であるギャビン・アンダーソン氏のブログがあります。ブログの中で、ギャビン・アンダーソンはクレイグ・ライトがサトシ・ナカモトであると確信している (http://gavinandresen.ninja/satoshi)。ギャビン氏はブログでこう述べている。「私はクレイグ・スティーブン・ライト氏がビットコインを発明した人物だと信じています。」ビットコインを発明したのはクレイグ・スティーブン・ライト氏だと信じています。

これを見ると、ただこう言いたいのです。「何が起こったのですか?」ギャビンも騙されたのだろうか？しかし、読者がギャビンに抱いている信頼に基づいて、何かが起こったに違いないと私は信じています。 。

しかし、いくつかの公開メディアの報道では、クレイグ・ライト氏が署名に以前採掘したビットコインアドレスに対応する秘密鍵を使用したかどうかは明確に明らかにされていない。こうなると、彼は本当にサトシ・ナカモトなのだろうかと疑問に思う人もいるだろう。あるいはギャビンのブログがハッキングされた（これは後でわかる）

クレイグ・ライトが与えた署名は次の通りであると報告されています: MEUCIQDBKn1Uly8m0UyzETObUSL4wYdBfd4ejvtoQfVcNCIK4AIgZmMsXNQWHvo6KDd2Tu6euEl13VTC3ihl6XUlhcU+fM4=

16 進数に変換すると、次のようになります。

3045022100c12a7d54972f26d14cb311339b5122f8c187417dde1e8efb6841f55c34220ae0

022066632c5cd4161efa3a2837764eee9eb84975dd54c2de2865e9752585c53e7cce

このトランザクションには次の署名メッセージが見つかります:

出典: : bit.ly/2c5eFv

この取引は、2009 年 1 月 12 日にブロック 248 で発生しました。

これは、Craig Wright が単に公開トランザクションを選択し、この公開鍵アドレスの秘密鍵を所有していると主張したことを示しています。このようなアプローチは説得力がないため、非常に疑わしいです。

また、最初のビットコイン取引が 170 番目のブロックで発生したことも重要です。このトランザクションは Satoshi から Hal Finney に送信されました。クレイグ・ライト氏が過去 170 ブロックのビットコイン アドレスの秘密鍵を所有していることを証明したり、秘密鍵を使用してメッセージに署名したりしない限り、クレイグ・ライト氏がサトシ・ナカモト氏であることを確認できます。

ブロック170の取引

https://blockexplorer.com/block/00000000d1145790a8694403d4063f323d499e655c83426834d4ce2f8dd4a2ee

クレイグ・ライト氏が公開署名を選択し、自分がその署名の所有者であると主張することがなぜ信頼できないのかを説明しましょう。クレイグ・ライトがサトシであると信じてもらうために、彼は何をする必要がありますか?

まず、暗号化における公開鍵、秘密鍵、デジタル署名の基本原理を見てみましょう。

 デジタル署名は、現実世界の手書き署名に類似している必要があります。デジタル署名に必要な 2 つの特性を設計するために、手書き署名をシミュレートします。まず、あなたが署名できる限り、誰でもあなたの署名を検証できます。 2 つ目のポイントは、署名が特定の文書に結び付けられ、署名していない場所を示すために偽造されないようにすることです。手書きの署名の場合、誰かがあなたの署名を別途切り取って新しい文書に貼り付けることはできないからです。

では、暗号化を通じてこれらの特性をどのように構築するのでしょうか?まず、デジタル署名スキームと関連するセキュリティ プロパティのいくつかをより深く理解できるように、現在のトピックにもう少し焦点を当ててみましょう。

generateKeysと サイン ランダムアルゴリズムを使用できます。実際、 generatekeys  異なる人が異なる公開鍵と秘密鍵を生成する必要があるため、ランダム化するのが最善です。確認する 検証関数はその逆を行います。  関数は決定論的であることが望ましいです。

それでは、デジタル署名の 2 つの要件について詳しく見ていきましょう。 1 つ目は比較的簡単です。すべての署名は検証可能でなければなりません。私が自分の秘密鍵でメッセージに署名し、誰かが私の署名されたメッセージを私の公開鍵で検証する必要がある場合、検証の結果は正しいはずです。この特性は、デジタル署名の非常に基本的な特性です。

偽造不可能性: 2 番目の特性は、通常の計算能力では、他人が署名を偽造できないことです。つまり、あなたの公開鍵と他のメッセージへの署名の一部を知っている相手がいる場合、その相手はあなたが署名していないメッセージの署名を偽造することはできません。偽造不可能性は、暗号技術でよく見られる古典的なゲームに似ており、暗号技術におけるセキュリティ証明の例としてよく使用されるゲームでもあります。

偽造不可能ゲームでは、署名を偽造できると主張するハッカーがいて、挑戦者はこのハッカーをテストしたいと考えています。最初に行う必要があるのは、generatekeys 関数を使用して秘密鍵と公開鍵のペアを生成することです。秘密鍵はハッカーに渡され、公開鍵はハッカーとハッカーの両方に渡されます。この方法では、ハッカーは公開されている情報の一部しか知らず、署名を偽造することが任務となります。署名を要求された側は秘密鍵を知っているため、メッセージに署名できます。

直感的に言えば、このチャレンジ ゲームは現実世界のいくつかのルールに準拠しています。現実世界の攻撃者は、一部の文書で潜在的な被害者の実際の署名も確認します。また、攻撃者は被害者を操作して、一見無害に見えても攻撃者にとって何らかの役に立つ文書に署名させることもできます。

このゲームをモデル化するために、攻撃者がいくつかの実際の署名付きメッセージにアクセスできるようにし、また、かなりの数の実際の署名付きメッセージにアクセスできるようにします。攻撃者は 100 万個の本物の署名付きメッセージにアクセスできると想定しますが、280 個にはアクセスできません。

攻撃者が本物の署名付きメッセージを十分に確認したら、これまで見たことのないメッセージ M の署名を偽造することができます。メッセージ M の唯一の要件は、攻撃者がそれを以前に見たことがないことです。 (攻撃者がこのメッセージを以前に見たことがある場合、このメッセージを簡単に送り返すことができるからです)。攻撃を受けた側は、検証機能を実行して、メッセージ M 上の攻撃者の署名が本物かつ有効かどうかを判断します。検証が成功すると、攻撃者がゲームに勝利します。

図1 偽造不可能なゲーム。ハッカー攻撃者と挑戦される側が一緒にゲームをプレイします。ハッカーがこれまでに見たことのないメッセージに署名できれば、ハッカーがゲームに勝ちます。いずれにせよ、挑戦を受けた側がゲームに勝利し、デジタル署名方式が偽造不可能であることが証明されます。

デジタル署名方式が偽造不可能であると言う場合、ハッカーがどのようなアルゴリズムを使用しても、署名の偽造に成功する確率は非常に低く、実際のアプリケーションでは無視できるほど小さいことを意味します。

 実際の問題は、実際のアプリケーションでは、デジタル署名の分野にアルゴリズムを適用するには、多くの実用的な問題を解決する必要があるということです。たとえば、多くの署名アルゴリズムはランダムです (Bitcoin ネットワークで使用されるものなど)。そのため、非常に優れたランダムソースが必要になります。優れたランダム ソースは、アルゴリズムのセキュリティにとって非常に重要です。

 実際のアプリケーションで考慮する必要があるもう 1 つの問題は、メッセージの長さです。実際の署名アプリケーションでは、有効な長さの文字列にのみ署名できるためです。しかし、この問題には簡単な解決策があります。メッセージ自体に署名するのではなく、メッセージのハッシュに署名するのです。 256 ビット出力のハッシュ関数を使用すると、任意の長さのメッセージに署名できます。前述したように、ハッシュ関数は衝突を防ぐため、メッセージのハッシュ値をメッセージ ダイジェストとして使用してメッセージに署名することができます。

もう 1 つの興味深いアプリケーションは、ハッシュ ポインターに署名できることです。ハッシュ ポインターに署名すると、その署名によってハッシュ ポインター自体だけでなく、ハッシュ ポインターが指すデータ構造全体を保護できます。例えば、ブロックチェーンの開始点にあるハッシュポインターにデジタル署名すると、ブロックチェーンに署名することと同等になります。

楕円曲線デジタル署名アルゴリズム (ECDSA): 次に、詳細をいくつか見てみましょう。ビットコイン ネットワークは、楕円曲線デジタル署名アルゴリズムと呼ばれる特別なデジタル署名方式を使用します。楕円曲線デジタル署名アルゴリズムは米国政府の標準です。これは以前の DSA 署名アルゴリズムのアップグレード版であり、楕円曲線を利用します。これらのアルゴリズムは長年にわたって暗号的に分析およびテストされており、安全で信頼できるものと考えられています。

具体的には、ビットコイン ネットワークは楕円曲線 secp256k1 を使用しており、ランダム衝突テストの 128 ビットのセキュリティ保護 (つまり、このアルゴリズムを解読する難易度は非常に高く、2128 回実行するのとほぼ同じ) を提供できます。このプロトコルは標準ですが、ビットコイン ネットワーク外ではほとんど使用されません。その他の楕円曲線署名アルゴリズム (TLS での Web ブラウザーでの値の安全な送信など) では、「secp256r1」曲線が使用される可能性が高くなります。これは、ビットコインの元の開発者であるサトシ・ナカモトが、現在では変更が困難な暗号化曲線を選択したためです。

ECDSA の仕組みについては、非常に複雑な数学が関係しており、このトピックとは特に関係がないため、ここでは詳しく説明しません。さらに詳しく知りたい場合は、弊社が推奨する参考書をいくつか読んでみてください。しかし、基本的な署名プロセスを理解することは非常に役立ちます。

秘密鍵: 256 ビット 公開鍵 (非圧縮): 512 ビット 公開鍵 (圧縮): 257 ビット 署名するメッセージ: 256 ビット 署名: 512 ビット

ECDSA は 256 ビットのメッセージにしか署名できないことに注意してください。ただし、メッセージは署名前にハッシュされるため、これは大きな問題ではありません。つまり、任意の長さのメッセージに署名できます。

ECDSA 署名アルゴリズムでは、乱数ソースの品質が非常に重要です。乱数ソースの品質が低いと、秘密鍵が漏洩する可能性があるためです。直感的に理解できるように、質の低いランダムソースを使用して秘密鍵を生成すると、秘密鍵が安全でない可能性があります。 ECDSA の場合、メッセージに署名するために不良なランダム性ソースを使用すると、完全に有効な秘密鍵を使用していても、秘密鍵が漏洩する可能性があります。秘密鍵を公開すると、ハッカーが署名を偽造する可能性があります。したがって、不適切なランダム ソースはシステムのセキュリティに大きな影響を与える可能性があるため、公開キーと秘密キーを生成するには適切なランダム ソースを使用するように特に注意する必要があります。

この時点で、クレイグ・ライトが公開した署名は単なるトリックであったことがはっきりとわかります。彼は公開署名メッセージを選択し、それが自分のものであると主張した。もし彼が本当にこのアドレス（12cbQLTFMXRnSzktFkuoG3eHoMeFtpTu3S）の秘密鍵を持っているなら、彼はサトシ・ナカモトのはずです。 1 彼は自分自身を証明するために上記のビットコインを移動することができます。 2 アドレスの秘密鍵を使用して、署名: i am satoshi などのメッセージに署名し、それを全員に検証させることができます。これら両方ができないのなら、どうして彼がサトシ・ナカモトだと信じられるのでしょうか?