抗議の方法の1つは、さまざまな種類の請願書の提出と集団署名です。 しかし、請願書への署名者のリストは公開されているため、「政党の方針」に同意しない人々が政権によって脅かされ抑圧される状況がしばしばあります。
匿名で署名を収集できるシステムを作成することはできますが、同時に各投票を検証する機会が与えられますか？ この問題に対する私の解決策をご紹介します。
問題の声明
たとえば、研究所の学生、組織の従業員、または国の市民など、限られた人々の輪があります。 それらのいくつかは、メッセージに署名します（請願、集団控訴など）。 提案された署名アルゴリズムには、次の特性があります。- 各署名者が指定されたサークルに属していることを確認することができます。
- ほとんどの署名が異なる人物に属していることを確認することができます。
- この署名またはその署名が誰のものであるかを正確に判断する方法はありません。
- 特定の人が署名を残したかどうかを判断することはできません。
- 署名者は、彼の要求に応じて、匿名署名の代わりにパーソナライズされた署名を置くことができます。
- 匿名の署名者は、その後、彼の要求に応じて、署名した証拠を提供できます。
システムは、 非対称暗号化 、 デジタル署名アルゴリズム、およびキー認証に基づいています 。
準備段階
各参加者（図1- A、B、... Z内 ）は、パブリックとプライベートのキーペアを生成します。 これらのキーをパーソナライズしたものと呼びます。 公開鍵は、研究所の学部長、企業の人事部、または州の管理機関である認証センターによって公開および確認されます。 証明書の目的は、このキーが実際に指定された人のものであり、この人が集合署名に参加する権利を持っていることを確認することです。
図 1.公開鍵認証スキーム
この段階は、将来署名されるメッセージの数に関係なく、一度実行されます。 認定キーデータベースは、中央に保存することも、配布することもできます。
投票形成
各署名者は別のキーペアを生成します-いわゆる 匿名キー 。 秘密鍵を使用して、彼はメッセージに署名し、公開は匿名で公開します。 電子署名（EDS）と対応する公開鍵は1 票です。
図 2.投票スキーム
署名者が匿名性を拒否したい場合、署名者は自分のパーソナライズされたキーを使用して署名し、匿名キーをまったく生成しません。
音声チェック
投票の最初の検証は、オブザーバー（誰でも果たすことができる役割）が、対応する公開匿名キーを使用して各投票の署名をチェックするという事実から成ります。 したがって、オブザーバは、この音声がこの特定のメッセージ専用に形成されていることを確認します。 しかし、これまでのところ、署名者の独自性についても、示された人の輪に属しているかについても何も言えません。
図 3.初期音声チェックのスキーム
署名検証
その後、署名者の検証が行われます。 このチェックは、署名者の数と技術的能力に応じて、選択的または完全に行うことができます。オブザーバーは、匿名公開キーを識別子として使用して、特定の投票を検証するリクエストを発行します。 キーがリクエストで公開されている署名者（図4- A ）は、ランダムな制御メッセージを生成し、匿名で公開します。 原則として、オブザーバーはリクエストに添付してこのメッセージを生成することもできます。
次に、 Aは自分の匿名の秘密鍵で制御メッセージに署名します。 次に、 Aは自分自身を含む特定の人物グループを選択します（図4- A、B、C ）。 署名者がA以外のグループの誰かであるかどうかは関係なく、 また 、確立することは不可能です。 また 、グループメンバーの数に応じて、制御メッセージのデジタル署名をフラグメントに分割し、これらのフラグメントをそれらに分配します。
図のフラグメントへの分割は条件付きで示されています。 文字を並べ替えるだけでも、テキストを切り取るのは悪い決断です。 秘密共有アルゴリズムの 1つを使用するほうが良いです 。
グループの各メンバー（ A自身を含む）は、個人化された秘密鍵でフラグメントに署名し、公開します。
図 4.署名検証スキーム
したがって、オブザーバーは、声がグループ{A、B、C}の誰かによって形成されたという証拠を受け取りますが、誰を正確に言うことは不可能です。 これは、政権が報復を署名者に適用することを非常に困難にします。 グループサイズは任意に選択できます。グループサイズが大きいほど信頼性は高くなりますが、フラグメントの分散を整理するのは（技術的に）難しくなります。 音声の繰り返し検証を禁止する必要があります。そうしないと、各検証に参加するグループの共通部分を探すことで署名者を計算することが可能になります。 または、検証を繰り返してもグループが変更されないようにする必要があります。
署名者が匿名化を希望する場合、彼はすべて同じアクションを実行し、グループを収集するだけでなく、匿名およびパーソナライズされたプライベートキーで制御メッセージに署名します。
フラグメンテーションと署名
フラグメント分散アルゴリズムについて詳しく見ていきましょう。 次の要件が彼に課されています。- グループのメンバーと外部のオブザーバーは、誰が手順を開始したかを知ることができないはずです。
- Aを除くグループのすべてのメンバーが陰謀に関与している場合でも、イニシエーターがAであることを証明することはできません。
- グループに参加していない人は、手順を開始できないはずです。
最後の要件により、フラグメントの不適切な単純な匿名配布が行われます。 結局、その人は、「音声を生成」し、フラグメントを他の人に送信し、個人化されたキーで署名しないことによって検証を受けることが可能になります。
フラグメント分布図を図6に示します。 Aがイニシエーターであるとします。 彼は、個人用にカスタマイズされたキーでランダムなフラグメントに署名し、 Bのすべてのフラグメントを転送します。 まず、 Bは認証された公開鍵を使用してAの署名を検証し、 Aが自分が主張するものであることを確認して、署名されたフラグメントを公開します。
次に、 Bはメッセージから署名Aを削除し、次のフラグメントに自分の秘密キーで署名し、 Cのすべてのフラグメントを送信します。 同様に、 CはBの署名を検証し、このフラグメントを公開して、次の署名をします。
チェーンの最後で、メッセージは再びAに転送され、最後の参加者（ C ）の署名をチェックして、最後のフラグメントを公開します。
図 5.配布と署名のフラグメントのスキーム
開始者を除く各参加者の手順はまったく同じに見えるため、チェーンの開始位置と終了位置を判別する方法はありません。 BとCが共謀して転送シーケンスを決定したとしても、 AはCの後のチェーンにいる（それぞれBがイニシエーターである）と主張でき、 CとBは反対を証明する方法がありません。
タイミング攻撃を防ぐには、手順の完了後に署名付きフラグメントの公開を行うか、公開前にランダムな遅延を導入する必要があります。 また、グループのすべてのメンバーは、事前に公開キーと証明書をキャッシュして、認証サーバーへのアクセス時までに順序を確立できないようにする必要があります。
検証完了
署名されたフラグメントを受け取ったオブザーバーは、各署名を公開キーA 、 B 、およびCで検証します。 次に、彼はフラグメントから制御メッセージの署名を収集し、元の制御メッセージと検証された音声からの匿名公開キーを使用して検証します。 すべてのEDSの検証が成功した場合、検証は合格と見なされます。
図 6.検証の最終段階のスキーム
ソースデータ（音声、制御メッセージ、署名付きフラグメント）はパブリックドメインで公開されているため、オブザーバーによって実行されるすべての操作は、他の関係者が繰り返すことができます。
おわりに
提案されたアルゴリズムの既存の類似物の2日間の検索では結果が得られなかったという事実にもかかわらず、別の自転車を発明したことが判明したとしてもまったく驚かないでしょう。 これが本当なら、リンクに感謝します。 結局のところ、サイクリングは脳にとって素晴らしい運動です。 また、不正確さ、脆弱性、およびアルゴリズムを改善できる場所を検索してくれたコミュニティにも非常に感謝しています。ご清聴ありがとうございました！