ビットコインアルゴリズムからシュノア署名アルゴリズムへの進化は進歩なのでしょうか? |

歴史の車輪は前進しており、テクノロジーの進歩は決して止まらず、画期的なビットコイン プロトコルがテクノロジーのアップグレードを開始しました。そのプロトコルである Schnorr Signature (Schnorr Signature) と Taproot (ツリーのタップルート) の技術アップグレードは、Bitcoin Core 0.21.0 バージョンに統合されました。
ビットコインの未来はこれまで以上に明るいように見え、今やその容量だけでなく機能性においても他のすべてのブロックチェーンを超える機会が与えられています。
ビットコイン ECDSA 楕円曲線署名アルゴリズムが使用されていたとき、複数署名トランザクションの検証プロセスは非常に煩雑でしたが、現在では、トランザクション内のすべての署名と公開鍵を 1 つの署名と公開鍵に結合することが可能です。追跡不可能で簡単かつ高速ですか?
実際、これに先立ち、サトシ・ナカモトがビットコイン・プロトコルを設計したとき、署名アルゴリズムの署名長、オープンソースかどうか、特許を取得しているかどうか、長期間のセキュリティ検証に合格しているかどうかなど、さまざまな条件を考慮する必要がありました。十分な時間とパフォーマンス。当時、上記の条件を満たす電子署名アルゴリズムは ECDSA だけでなく、あらゆる面で ECDSA に劣らない電子署名アルゴリズムである Schnorr Signature も存在していました。ただし、2008 年以前は特許で保護されていたため、サトシ ナカモトがビットコイン プロトコルの設計時にこの署名アルゴリズムを使用せず、最終的に楕円曲線デジタル署名アルゴリズム (ECDSA) を選択したのはこのためと考えられます。カーブ secp256k1 は、 の提案により選択されました。
10年後の2018年7月、ビットコイン開発者のピーター・ウィレ氏はbip-schnorrを書き、ビットコインの署名アルゴリズムをschnorrに変更することを提案した。 Schnorr と ECDSA はどちらも secp236k1 曲線を使用した楕円曲線暗号化アルゴリズムですが、暗号特性における Schnorr 署名の利点により、ほぼ同じセキュリティに基づいて複数署名トランザクションを構築する方が便利です。
ビットコインで使用される Schnorr には、ECDSA に比べてさらにいくつかの重要な利点があります。
より安全: ランダムオラクルモデルで Schnorr 署名の安全性を証明するのは簡単ですが、ECDSA にはそのような証明はありません。
展性の問題なし: ECDSA 署名は展性があり、第三者は秘密キーを知らなくても既存の署名を直接変更でき、このトランザクションに対して署名を引き続き有効に保つことができます。ビットコインに対する展性攻撃は常に存在していましたが、従来のトランザクションの代わりに segwit トランザクションが使用されていた場合、SegWit がアクティブ化されるまで修正されませんでした。これについては、BIP62 および BIP66 で詳しく説明されています。
線形: Schnorr 署名アルゴリズムは線形です。この機能に基づいて、より効率的でプライベートなブロックチェーン システムを構築できます。 Schnorr 署名を使用する当事者は、それぞれの鍵の署名付き集合体を生成できます。たとえば、N 個の公開鍵を使用して署名する場合、ECDSA を使用すると、N 個の署名が存在し、検証も N 回実行する必要があります。 Schnorr を使用すると、線形特性により署名の重ね合わせを実行でき、最終的な重ね合わせ署名のみが保持されます。たとえば、同じトランザクション内の入力の数に関係なく、1 つの署名に重ね合わせることができ、1 回の検証で十分です。
Schnorr 署名アルゴリズムは、パフォーマンス、セキュリティ、ボリューム、スケーラビリティなど、ほぼすべての側面でビットコインの既存の署名アルゴリズム ECDSA よりも優れており、Schnorr Sig は ECDSA と同じ楕円曲線、つまりアップグレードされた変更が非常に小さい secp256k1 曲線を使用できます。
Q&A
Q: Schnorr 署名は、n 個中 m 個のマルチ署名に使用できますか?
A: もちろんできます。マルチシグは、n 個の署名のうち m 個のパターンにすぎません。署名アルゴリズムに関係なく。
Q: Schnorr のグループ署名機能は、n 個中 m 個の署名を作成またはシミュレートできますか?
A: それはできません。グループ内に N 個の公開鍵がある場合、対応する N 個の署名が存在する必要があり、そのすべてが必須です。全員が署名を生成するときは、ハッシュ関数にグループ公開鍵 P を代入します。
Q: 署名メカニズムのセキュリティを測定するにはどうすればよいですか?
A: それは主に 2 つに依存します: 1. 署名アルゴリズム自体 2. 楕円曲線。現在、Schnorr と ECDSA はどちらも同じレベルの曲線 secp256k1 を使用しています。署名アルゴリズム自体のセキュリティに関しては、Schnorr は現在 ECDSA よりも優れたセキュリティ証明書を持っています。
BCH による Schnorr 署名アルゴリズムの試験的実装
2019 年 5 月 16 日の時点で、BCH はすでにハードフォーク アップグレードを開始していました。アップグレードの主な内容は、Schnorr署名のアップグレードで最も期待されている機能であるSchnorr署名アルゴリズムとSegregated Witnessの回復であり、Segregated Witnessの回復原理は、Segregated Witnessのアドレスに誤って送信されたBCHを回収する修復技術である。
開発者 Mark Lundeberg ユーザーは、Schnorr 署名の使用を開始するために新しいアドレスを生成する必要はありません。このアップグレードによって BCH にもたらされる利点は次のとおりです。
1. 署名データの有効性の向上:署名は64バイトのデータであるため、通常の70バイトと比較して、トランザクションのバイト数を4%削減できます署名データの有効性(Schnorr署名によりブロックチェーンのストレージが削減されます)帯域幅が少なくとも 25% 向上し、BCH ネットワークがより高速かつ効率的になります)。アップグレード後は、Schnorr 署名により、BCH に通常の支払いチャネルを非表示にする機能が提供されます。
2. プライバシーの向上: アップグレード前は、プライバシーを向上させるために多くのユーザーが意図的に複数の署名を使用してトランザクションを送信しており、Schnorr 署名によりすべてのユーザーの署名が他の署名と同じに見えるため、この構造によりトランザクションのプライバシーが大幅に増加します。 Schnorr によって提供されるプロパティと、BCH 開発者やウォレットなどのインフラストラクチャ プロバイダによって追加されたいくつかの拡張機能により、プライバシーとスケーラビリティがさらに強化されます。
3. スパム トランザクション攻撃への対抗: 過去にもスパム トランザクション攻撃がありました。攻撃者は、できる限り多くのトランザクション スペースを通じてビットコインを輻輳させようと考えています。彼らの手法の 1 つは、複数のソースからトランザクションを頻繁に送信することで、このトランザクションを発生させることです。トランザクションには数十の署名が含まれており、多くのスペースを占有します。これがECDSA署名によって残された隠れた危険です。 Schnorr はそのようなスパム攻撃を回避できます。各トランザクションの署名が 1 つだけの場合、ブロックはより多くのトランザクションに対応でき、スパム発信者が攻撃を作成してより多くの人と競合したい場合は、より多くのトランザクションを送信する必要があるため、攻撃のコストは比較的高くなります。通常、署名が占めるスペースはトランザクションの最大部分であるため、攻撃者には何のメリットもありません。
もちろん、良い面だけを見ることはできず、すべてが不足し、両極端は逆転します。特に、量子コンピューターの開発により、一部の先見の明のある人々ができるだけ早く解決策を見つけるよう促されており、一部のアルゴリズムに対する量子コンピューターの攻撃に対処するために、NIST は 2017 年にポスト量子暗号の標準化プロセスを開始しました。 - 量子署名方式が推進されており、ポスト量子暗号化基盤によってサポートされている反量子アルゴリズムの 1 つで、署名長が最も短い署名反量子署名方式 - レインボー署名が最も有望です。
2017年8月、Jin Liuと数学者のJintai Ding教授はABCMintの設立準備を進め、スイスのチューリッヒ近郊の暗号化バレーに登録した。デジタル通貨 ABC の基本的な署名は虹の署名です。彼らのビジョンは、反量子コンピュータ クラッキング アルゴリズムの研究と応用を世界的にサポートすることです。研究には、世界中のアルゴリズムの発見、クラッキング、改善における数学者のサポートが含まれます。このアルゴリズムは主流のデジタル暗号通貨に適用されます。
彼らは、ECDSAからSchnorr署名へのSchnorr署名を使用するビットコインの提案BIP340は、ビットコインの大きな後退であると信じています。私たちは、コンピュータセキュリティの専門家が提案するアルゴリズムの選択と改善には楽観的ではなく、数学者が提案するアルゴリズムの選択と改善を好む シュノア署名には大きな問題があり、ライトコインなどで長期間使用されるべきである走る。
簡単に言うと、分散化自体がマルチシグネチャから逸脱しています。
以下にいくつかの簡単なアルゴリズムを示します。
1 楕円曲線デジタル署名アルゴリズム (ECDSA)
楕円曲線デジタル署名アルゴリズム (ECDSA、楕円曲線デジタル署名アルゴリズム) は、楕円曲線暗号 (ECC) を使用したデジタル署名アルゴリズム (DSA) のシミュレーションです。 (楕円曲線暗号 (ECC) は 1985 年にニール コブリッツとビクター ミラーによって発明されました)、ECDSA は、NIST のデジタル署名標準 (DSS) の要求に応えて、1992 年にスコットとヴァンストンによって最初に提案されました。
ビットコインは現在、ECDSA 楕円曲線デジタル署名アルゴリズムを使用しています。メッセージ m に署名するには、メッセージをハッシュし、このハッシュを数値として扱う必要があります: z = hash(m)。ランダムまたはランダムな検索番号 k も必要です。私たちは乱数ジェネレーターを信頼したくないので (バグが多すぎて、不正な RGN に関連するバグも多数あります)、通常は RFC6979 を使用し、シークレットと署名するメッセージに基づいて決定的な K 値を計算します。
秘密鍵 pk を使用すると、r (ランダム点の x 座標 R = k×G) と s = (z+r⋅pk)/k の 2 つの数値から構成されるメッセージ m の署名を生成できます。次に、公開鍵 P = pk×G を使用して、点 (z/s)×G+(r/s)×P の x 座標が r に等しいことを確認することで、誰でも署名を検証できます。
署名検証には反転 (1/s) と 2 点乗算が含まれており、これらの演算は計算コストが高くなります。ビットコインでは、すべてのノードがすべてのトランザクションを検証する必要があります。これは、トランザクションをブロードキャストするときに、何千ものコンピュータが署名を検証する必要があることを意味します。たとえ署名プロセスがより困難であっても、検証プロセスを簡素化することは非常に有益です。
第 2 に、各ノードは各署名を個別に検証する必要があります。 m-of-n マルチ署名トランザクション ノードの場合、同じ署名を複数回検証する必要がある場合があります。たとえば、7-of-11 マルチシグ入力のトランザクションには 7 つの署名が含まれており、ネットワーク内のすべてのノードに対して 7-11 の署名検証が必要です。また、そのようなトランザクションは多くのスペースを占有し、多額の費用を支払わなければなりません。
シュノアの署名
Schnorr 署名アルゴリズムは、ドイツの数学者で暗号学者の Claus Schnorr によって提案されました。そして 1990 年に米国特許 4,995,082 という特許を申請しましたが、この特許は 2008 年 2 月に期限切れになりました。このアルゴリズムは現在無料で利用できます。
Schnorr 署名は少し異なる方法で生成されます。2 つのスカラー (r, s) の代わりに点 R とスカラー s を使用します。 ECDSA と同様に、R は楕円曲線上のランダムな点です (R=K×G)。署名の 2 番目の部分は少し異なる方法で計算されます。
s = k + hash(P,R,m) ⋅ pk. ここで、pk は秘密鍵、P = pk×G は公開鍵、m はメッセージです。この署名は、s×G = R + hash(P,R,m)×P をチェックすることで検証できます。
この方程式は線形であるため、方程式は相互に加算および減算でき、依然として有効であるため、Schnorr 署名に関するいくつかの大きな利点が得られます。
3 Schnorr 署名のバッチ検証
ビットコイン ブロックチェーン内のブロックを検証するには、ブロック内のすべての署名が有効であることを確認する必要があります。
ECDSA 署名アルゴリズムの場合、各署名を個別に検証する必要があります。つまり、ブロック内に 1000 個の署名がある場合、1000 回の反転と 2000 回のドット乗算を計算する必要があり、合計で約 3000 回の重い計算タスクになります。
また、Schnorr 署名を使用すると、すべての署名検証式を合計できるため、計算能力をいくらか節約できます。 1000 個の署名を持つブロックの場合、以下を検証する必要があります。
(s1+s2+…+s1000)×G=(R1+…+R1000)+(hash(P1,R1,m1)×P1+hash(P2,R2,m2)×P2+…+hash(P1000,R1000,m1000)×P1000)
ここには、大量の加算 (計算能力はほぼ無料) と 1001 ポイントの乗算があります。各署名に対して約 1 回の重い計算を計算する必要があります。
4 Schnorr 署名の鍵集約
私たちはビットコインを安全に保ちたいので、おそらく少なくとも 2 つの異なる秘密鍵を使用してビットコインを制御したいと考えています。たとえば、1 つはラップトップまたは携帯電話上にあり、もう 1 つはハードウェア ウォレット/コールド ウォレット上にあります。したがって、それらのいずれかが侵害された場合でも、私たちはビットコインを制御することができます。
現在、これは 2-of-2 マルチ署名スクリプトを介して実行されており、トランザクションに 2 つの別個の署名を含める必要があります。一方、schnorr 署名では、秘密鍵のペア (pk1、pk2) を使用して、共有公開鍵 P=P1+P2=pk1×G+pk2×G に対応する共有署名を生成できます。この署名を生成するには、各デバイスで乱数 (k1,k2) を選択し、ランダム ポイント Ri=ki×G を生成し、それらを加算して公開ハッシュ (P,R1+R2,m) を計算する必要があります。各デバイスから s1 と s2 を取得します (si = ki + hash(P,R,m) ⋅ pki)。次に、これらの署名を合計し、ペア (R, s) = (R1+R2, s1+s2) を共有公開鍵 p の署名として使用できます。他の人にはそれが集約された署名であるかどうかわかりませんが、見た目は通常の schnorr 署名とまったく同じです。
この構造には 3 つの問題があります。まず、ユーザー インターフェイスの観点から、トランザクションを行うには、数ラウンドの通信を行い、公開 R を計算し、署名する必要があります。 2 つの秘密鍵を使用すると、これはコールド ウォレットへの 1 回のアクセスで実行できます。オンライン ウォレットで署名のないトランザクションを準備し、k1 を選択し、署名のないトランザクションとともに R1=K1×G を書き留めます。次に、このデータをコールド ウォレットに転送し、署名します。すでに R1 を持っているので、一度にコールド ウォレットでトランザクションに署名できます。コールド ウォレットから R2 と s2 を取得し、それらをオンライン ウォレットに戻します。オンライン ウォレットは、以前に選択した (k1、R1) でトランザクションに署名し、署名を結合して、署名されたトランザクションをブロードキャストします。これは現在の状況と非常に似ていますが、3 番目の秘密キーを追加すると、すべてがより複雑になります。あなたが財産を持っており、それは世界中の安全な場所に保管されている 10 個の秘密鍵によって管理されており、取引を行う必要があるとします。現時点では、これらすべての場所を 1 回通過するだけで済みますが、キー集約を使用している場合は、すべての RI を組み立ててから署名するために、これを 2 回行う必要があります。この場合、集約せずに個々の署名を保持する方が良いため、3 ラウンドの通信が必要になります。
乱数 ki とそれに対応する Ri=ki×G を選択し、そのハッシュ ti=hash(Ri) だけを全員に伝えます。そうすれば、他の乱数を学習しても考えが変わらないと誰もが確信できます。
すべての数値をまとめて、共通の R を計算します。
サイン;
2 番目の問題は、既知の悪意のあるキー攻撃です。これについては、この論文とこの記事の両方で詳しく説明されているので、詳細には触れません。そのアイデアは、デバイスの 1 つ (オンライン ウォレットなど) がハッキングされ、その公開鍵が (p1-p2) であるふりをした場合、その秘密鍵 pk1 で共有資金を制御できるというものです。簡単な解決策は、デバイスをセットアップするときに、対応する秘密キーを使用して公開キーに署名する必要があることです。
3 番目の重要な質問があります。決定論的な k で署名することはできません。攻撃する簡単な方法があります。決定論的な K を使用すると、ハッカーが秘密鍵を取得できます。攻撃は次のようになります。誰かが私たちのラップトップにハッキングし、2 つの秘密鍵のうちの 1 つ (pk1 など) を完全に制御しました。私たちのビットコインは pk1 と pk2 からの集約された署名を必要とするため、安全だと感じるかもしれません。そこで、通常どおりトランザクションを実行し、署名されていないトランザクションと R1 値を準備し、それらをハードウェア ウォレットに転送して、そこで署名しようとします。次に、(r2, s2) を返します。そして...オンラインウォレットに問題が発生しました。署名もブロードキャストもできません。再試行しますが、ハッキングされたコンピューターは今度は別のランダム値 R1' を使用します。ハードウェア ウォレットで同じトランザクションに再度署名し、値 (r2、s2) をハッキングされたコンピューターに戻します。その後、何か悪いことが起こり、ビットコインが失われてしまいました。
この攻撃では、ハッカーは同じトランザクションに対する有効な署名のペア (R1, s1, R2, s2) と (R1', s1', R2, s2') を取得します。ここで、R2 は同じですが、R = R1 です。 +R2 と R'=R1'+R2 は異なります。これは、ハッカーが 2 番目の秘密キーを計算できることを意味します: s2-s2'=(hash(P,R1+R2,m)-hash(P,R1 '+R2, m))⋅pk2 および pk2=(s2-s2')/(ハッシュ(P,R1+R2,m)-ハッシュ(P,R1'+R2,m))。これはキー集約の最も不便な機能だと思います。キー集約を使用するには、どこにでも優れた乱数ジェネレーターが必要です。


