コールサイン
【課題】ピアツーピアネットワークなどに使用される、暗号文によりセキュリティ保護されている短い簡単に覚えられるコールサインを生成する方法を提供する。
【解決手段】公開鍵およびパーソナライゼーション情報文字列からなる区別された修飾子を決定すること、暗号化一方向関数を通じて公開鍵およびパーソナライゼーション情報文字列とともにハッシュされた場合に、結果が、多数の０から始まる、区別されたハッシュ値となる区別されたｓａｌｔを見つけること、および区別されたｓａｌｔを公開鍵およびパーソナライゼーション情報文字列からなる区別された修飾子とともにハッシングすること、ハッシュから先行０の個数を見つけること、ハッシュからビットの個数を取り出すこと、先行０の個数およびビットの個数のビットの英数字表現を見つけることにより、コールサインを生成する。
【解決手段】公開鍵およびパーソナライゼーション情報文字列からなる区別された修飾子を決定すること、暗号化一方向関数を通じて公開鍵およびパーソナライゼーション情報文字列とともにハッシュされた場合に、結果が、多数の０から始まる、区別されたハッシュ値となる区別されたｓａｌｔを見つけること、および区別されたｓａｌｔを公開鍵およびパーソナライゼーション情報文字列からなる区別された修飾子とともにハッシングすること、ハッシュから先行０の個数を見つけること、ハッシュからビットの個数を取り出すこと、先行０の個数およびビットの個数のビットの英数字表現を見つけることにより、コールサインを生成する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザをコンピュータネットワークに識別させるための比較的短い「コールサイン」に関する。
【背景技術】
【０００２】
鍵と暗号識別（「ＩＤｓ」）は、コンピュータシステムなど、ユーザの検証を必要とする多くのアプリケーションにおいて重要な役割を果たす。ピアツーピアコンピュータシステムの実施例では、ユーザ識別（「ＩＤ」）は、ＩＤが電子メールなどで電子的に提示される場合にユーザがネットワークにアクセスする権利を有することを検証する、システム管理者への証明書（ｖｅｒｉｆｉｅｒ）として使用することが可能である。それとは別に、ＩＤは、音声または筆記により伝達することもできる。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
以前には、ＩＤは、名刺を使用して、または口頭で、手作業により提示されていた。ＩＤは、通常、簡単に覚えられない２進数の長い数列である。ＩＤは、暗号化プロセスを使用してセキュリティ保護されるようにできる。しかし、保護されているＩＤは、通常、さらに長く、また簡単に回覧することも難しい。そのため、さらに、ユーザは暗号化でＩＤを保護する場合に使い勝手をあきらめる。
【０００４】
以下では、読者が基本的な理解を得られるように、開示について簡単に説明する。この「発明の開示」は、開示の広い範囲にわたる概要ではなく、また本発明の鍵となる／重要な意味を持つ要素を識別しない、または本発明の範囲を線引きすることもない。後で述べる詳細な説明の前置きとして、本明細書で開示されているいくつかの概念を簡略化した形式で述べることのみを目的とする。
【課題を解決するための手段】
【０００５】
本発明は、ユーザをコンピュータネットワークに識別させるための比較的短い「コールサイン」を実現する。このネットワークは、ネットワーク内の個々のコンピュータが他のネットワークの場合と比べてセキュリティを厳しくする必要のあるピアツーピアネットワークであってよい。コールサインは、ネットワークへの参加を求めるコールサインを提示する人に関する情報を組み込む。コールサインは、短く、覚えやすいが、従来のＩＤは、通常長く、覚えにくい。コールサインは、さらに、事前に計算される「ｓａｌｔ」値も組み込み、これにより、それ自身と個人情報のハッシュで、英字および数字を含むコールサインに容易に変換できる固定長の結果を出力する。個人情報以外の情報は、アプリケーションに応じてハッシングに取り込むことができる。
【０００６】
当業者であれば、暗号文によりセキュリティ保護されている短い簡単に覚えられるＩＤを持つことが望ましいことを理解するであろう。この種のコールサインは、必ず、覚えられるくらい十分に短いが、それでも、十分なセキュリティを提供し、ピアツーピアまたは他のネットワークの利便性を高めることができる。
【０００７】
本発明の付随する特徴の多くは、添付の図面に関して考察される以下の詳細な説明を参照することにより容易に理解できるため明白であろう。
【０００８】
以下の説明は、本開示の一部をなす、以下で手短に説明されている、図面の様々な部位を参照することで最もよく理解できるであろう。
【発明を実施するための最良の形態】
【０００９】
付属の図面に関して以下で述べる詳細な説明は、本発明のこの実施形態の説明として意図しており、本発明が構成または利用されうる唯一の形態を表すことを意図していない。この説明では、本発明の機能、および例示されている実施形態に関して本発明を構成し、動作させるステップの順序を規定する。ただし、同じ、または同等の機能および順序は、本発明の精神および範囲内に包含されることも意図している異なる実施形態により達成することが可能である。
【００１０】
本発明は、本明細書では、ピアツーピアコンピュータネットワークシステム内に実装されるものとして説明され、例示されているが、説明されているシステムは一実施例として提示されているのであり、限定するものとして提示されているのではない。当業者であれば、本発明は、様々な異なる種類のコンピュータシステムによるアプリケーションに好適であることを理解するであろう。
【００１１】
図１は、ピアツーピアネットワークまたは同等のネットワーク例にアクセスするために使用される標準的なセキュリティ保護されたユーザ識別を示す図である。ピアツーピアコンピュータネットワークは、サーバコンピュータなしで機能しうるコンピュータのネットワークであり、そのセキュリティに対する責任は、ネットワーク内のそれぞれのピアコンピュータが負う。周知のように、ユーザのアクセス権を識別し、検証するために使用される識別子１０１は、通常、極めて長い。このような２進数は、通常、１６０ビット長（１０２）であり、これは、４０桁の１６進数に等しい。識別子１０１の他の実施例としては、４０個の１６進数により表される数と任意長の文字列の２つの構成要素を含むＰＮＲＰ名がある。このような識別は、マシン以外では、容易に伝達することはできない。
【００１２】
多くのコンピュータネットワークは、「ピアツーピア」名前解決のプロセスで通常使用されるピア名の生成を必要とする場合がある。現在実装されているように、ピアツーピア名前解決プロトコル（ＰＮＲＰ）は、通常、ユーザに扱いやすい（十分なセキュリティ機能を持たない傾向がある）短いピア名を使用するか、またはユーザに扱いにくい（通常は、より高いレベルのセキュリティ機能を持つ）長い２進数列を含む長いピア名を使用することに制約される。当業者であれば、任意の種類のコンピュータネットワーク、またはセキュリティ保護され、短縮された識別ツールが望まれているシステムに、短縮された識別子を適用可能であることを理解するであろう。
【００１３】
長いピア名は、通常、暗号化プロセスを適用することにより、セキュリティ保護することが可能である。しかし、そのような長い名前は、通常、ユーザに扱いやすいものではない。長い名前は、通常、覚えておいてコンピュータネットワークへのアクセス権を得るために入力するのが難しい。つまり、最新技術では、通常、ユーザに対し利便性とセキュリティの択一選択を迫るのである。ピアツーピアネットワーク内で、安全な方法により、短く覚えやすい識別子を使用してコンピュータを識別する手段を実現することが望ましい。
【００１４】
（Ｉ．０の個数が明示されているコールサインの第１の実施形態およびそれらを生成する方法）
図２は、コールサインを発生する方法の第１の実施形態により生成される短縮されたコールサイン識別子２０２の表現を示す図である。特に、この本実施形態では、コールサイン内の「０の個数フィールド」を使用する。本明細書で説明されているピアツーピア識別（「コールサイン」）に対するセキュリティ保護されたコールサインを生成するシステムおよび方法を使用することで、ピアツーピアネットワーク（「Ｐ２Ｐ」）、および当業者に知られている他の同等のネットワークアプリケーションに使用することができる覚えやすいセキュリティコードまたはコールサイン２０２を生成する。特に、コールサインを構成する際に使用される特定の情報、および適用される暗号機能により、コールサインを様々なアプリケーションで使用することができる。例えば、コールサインおよびそれらのコールサインを生成する方法の一実施形態をピアツーピア名前解決プロトコル（ＰＮＲＰ）に適用することができる。他のアプリケーションは、限定はしないが、 を含むことができる。
【００１５】
ピアツーピア識別に通常使用されるコールサインを生成する方法により、ユーザのＩＤを安全に伝達するという難題を解決する。セキュリティは、セキュリティ保護されたプロセスを使用して、ユーザに覚えやすい、また入力しやすい短いコールサインを構成することにより実現される。そのようなコールサインに対し、暗号化プロセスにより強力な保護を行うことができる。例えば、「ＺＡ４−３Ｙ−４Ｗ−ＺＦ４」などのピアツーピア識別のコールサイン２０２は、短く、セキュリティ保護されている。このようなコールサインを覚えるのは、社会保障番号を覚えるよりも少し難しいだけである。
【００１６】
例示されているコールサイン例２０２は、１０個の英数字を含む。当業者であれば、それよりも多い、または少ない文字を含むコールサインを生成できることを理解するであろう。１０個のコールサイン文字はそれぞれ、５個の２進数ビット２０３を表す。これらのセグメントは、５つのビットセグメントに分割されているさらに長い２進数の一部分である。当業者であれば、５ビットよりも多い、または少ない長さの２進数を表すために同等の実施形態で使用できることを理解するであろう。
【００１７】
コールサインの桁の最初の桁は、この実施例を見るとわかるように、文字「Ｚ」である。この実施例では、第１の桁は、コールサインを復号化する際に使用される０の個数を伝達するように定義されている。ここで、文字Ｚは、５ビット２進数１１１１１である、１０進数３１を表すように定義されている。当業者であれば、本発明の同等の実施形態において、０の個数を識別する桁の配置、およびコールサイン内の０の個数は、異なっていてもよい。同様に、実施例では、「Ｚ」の代わりに任意のビットパターンまたは文字を選択できる。
【００１８】
このコールサインの残りの９個の英数字は、２進数の残り部分を表す。これらの桁は、（「Ｌ」）として指定される。この実施例では、Ｌは、長さが４５ビットである。２進数Ｌは、ユーザ識別を暗号化するために使用される暗号化プロセスの結果から取り出したものである。２桁目から１０桁目までの中の残りＬビットは、残りの９つの英数字にマッピングされる５ビットセグメントに分割される。当業者であれば、２進数の英数字へのマッピングは、テーブルルックアップ、公式、または当業者に知られているその他の同等な方法により実行できることを理解するであろう。当業者であれば、さらに、１０個の文字の順序付けは、同等な実施形態でも異なることがあることも理解するであろう。
【００１９】
０の個数および数Ｌをコールサインから復号化した後、２進数に対し暗号化処理が実行されて、ユーザのＩＤを再作成する。ユーザの識別が確立されたら、コールサインを保持している人に、ネットワークへのアクセス権およびその他の特権を付与することができる。
【００２０】
（区別された修飾子からのコールサインの第１の実施形態の生成）
名前を付けるべきエンティティは、従来通り生成された公開鍵／秘密鍵のペアＫ／Ｐ、およびパーソナライゼーション情報文字列、またはデジタルＩＤ、Ｘを所有していると仮定する。パーソナライゼーション情報文字列は、名前を付けるべきエンティティの自然な属性で構成することができる。例えば、パーソナライゼーション情報文字列は、一般名、会社名、市名、および電子メールアドレスなどの組合せを含むことができる。従来通り構成された公開鍵Ｋは、バイナリ文字列により表すことができ、パーソナライゼーション情報文字列は、テキスト文字列により表すことができる。
【００２１】
図３に、コールサインの構成を示す。コールサイン生成プロセスの第１のステップは、Ｓが暗号化一方向関数（「Ｈ（ｘ）」）３０８を通じてＫ３１０とＸ３０９とともにハッシュされた場合（３０７）に、結果が、多数の０から始まる、「区別された」ハッシュ値（「Ｈ」）３０１となる、「区別された」「ｓａｌｔ」値Ｓを見つけることである。コールサインを生成する後続のステップでは、特定の個数の０が必要である。区別されたｓａｌｔ値を見つける際に、与えられた時間間隔にわたって多数の値を試すことができ、所望の個数の０を生成する区別されたｓａｌｔ値が保持される。区別されたｓａｌｔ値により、ユーザが認証用のコールサインを提示した場合にコールサインが検証手順をパスするようにできる。
【００２２】
当業者であれば、先行０の代わりに特定のビットパターンを使用できることを理解するであろう。例えば、他の実施形態では、先行１、または最小個数の「０１１０」グループなどを利用することもできる。コールサインを生成する際に求めているのは、コールの一部が所定のパターンと一致していることであるが、コールサインを構成し、パターンを持たない傾向のあるビットの残りはコールサインの残りの桁を構成する。それとは別に、所定のパターンは、区別されたハッシュ値を生成するために使用されるハッシュ関数ではなく２次的な関数から得ることも可能である。
【００２３】
ハッシングは、ハッシングアルゴリズムと呼ばれる数学的関数を任意の量のデータに適用することにより固定サイズの結果を出力する暗号化プロセスでよく使用されるプロセスである。これらの実施形態で使用されるハッシュ関数は、当業者に知られている型である。標準的なハッシングアルゴリズムとしては、ＭＤ２、ＭＤ４、ＭＤ５、およびＳＨＡ−１がある。
【００２４】
これらの実施形態で使用されるハッシュ関数は、一方向暗号化ハッシュ関数として特徴付けることができる。当業者であれば理解するように、一方向ハッシュ関数は、通常、複数の一意的な特性を持つが、それは、任意長のメッセージ入力から固定長のハッシュ値または結果を計算するのは容易であり、固定長のハッシュ値が与えられた場合、任意長のメッセージを計算することは難しく、また任意長のメッセージ入力が与えられた場合、同じ固定長のハッシュ値を生成する他のメッセージを見つけることは困難であるからである。
【００２５】
区別されたｓａｌｔ値およびその他の文字列から出力される区別されたハッシュＨ３０１は、そのハッシュにより生成される数のＭＳＢ側の多数の０（または他の同等の定義済みビットパターン）から始まる。当業者であれば、他の同等の実施形態において、複数の０（またはその他の同等の定義済みビットパターン）をＬＳＢ桁またはその他の位置に配置できること、または説明されているハッシュまたは他の関数の順序特性をインジケータとして使用することが可能であることを理解するであろう。区別されたｓａｌｔ値および最終的な区別されたハッシュは、異なるｓａｌｔ値で評価される一方向ハッシュ関数の反復を通じて見つけられる。多数の先行０を伴うハッシュを生じるｓａｌｔ値は、区別されたハッシュとして保持される。一定の時間Ｔが経過するまで試行を繰り返す。当業者であれば、本発明の複数の実施形態では、攻撃者がＴの倍数の時間をかけて同じ個数の０を見つけ、４０ビットまたは４５ビットと照合しなければならないという想定の下で、ある固定時間「Ｔ」の間に０を見つけようとすることを理解するであろう。区別されたｓａｌｔ値を見つけるための探索プロセスの一実施形態は、以下のように書くことができる。
見つける０の個数を初期化する：Ｚ＝０
時間Ｔの間、以下を実行する：
新しいｓａｌｔ値Ｖを選択する
ＨＶ＝一方向ハッシュ（Ｋ，Ｘ，Ｖ）を計算する
ＨＶ内の先行０の個数、Ｙを計算する
（Ｙ＞Ｚ）ならば
Ｓ＝Ｖ，Ｈ＝ＨＶ，Ｚ＝Ｙ
指定された時間Ｔの終わりに、区別されたｓａｌｔ値Ｓおよび区別されたＨが見つかる。
【００２６】
区別されたハッシュＨは、暗号に関して強力な一方向関数を通じてＫ、Ｘ、およびＳのハッシュとして定義される。
区別されたハッシュ＝Ｈ＝Ｈ（Ｋ，Ｘ，Ｓ）
【００２７】
２進数である区別されたハッシュＨから論理コールサインが作成される。区別されたハッシュ３０１は、所定の個数のビット（「Ｍ」）からなる。Ｍは、区別されたハッシュの先行０（「Ｚ」）」３０２、および最後の先行０（または先行０のＬＳＢ）の直後にある区別されハッシュ値Ｈの予め選択された個数のビット（「Ｌ」）３０３を含む。
【００２８】
０の個数が決定された後、次のステップは、コールサインのコンテンツ内に含める区別されたハッシュＨからの残りのビットの個数を決定することである。（区別されたｓａｌｔ値を見つける際に使用される）パラメータＴおよびＬは、セキュリティおよびスケーリング考慮事項を考慮して選択される。上記のプロセスは、試行が実行される期間Ｔ、および選択されたビットの個数Ｌの２つのパラメータを持つ。これらのパラメータは、所定の数のエントリへのスケーリングを考慮し、ハッカーによるスプーフィング攻撃を難しくし、将来もセキュリティが保たれコールサインを将来にわたって使い続けられるようにすることにより、決定される。将来にわたって使い続けられるには、通常、ムーアの法則を考慮し、コンピュータの速度が向上してもコールサインの偽造不可能性が無効にならないようにすることである。これらのパラメータを選択する際にさらに考慮することは、ハッカーからの「カタログ」攻撃に抵抗することである。
【００２９】
（第１の実施形態における０の個数の符号化）
０の個数が判明した後、その個数をコールサインの中に符号化する方法も見つけなければならない。十分なセキュリティを備える短いコールサインを生成するために、短いデジタルまたは英数字文字列に符号化できるようにビットの総数を十分小さな値に抑える。符号化するビットの総数は、数Ｌと、０の個数Ｚを符号化するために必要なビットの数との総和である。通常、数Ｚは、１２８よりも小さく、７ビットで符号化することができる。
【００３０】
他の実施形態では、ヌルビットの実際の個数を符号化する代わりに、４ビットを使用するヌルオクテットの個数、または５ビットを使用するヌル「４ビットニブル」の個数を符号化することが可能である。十分な数のニブルを見つける修正されたプロセスは以下のとおりである。
【００３１】
見つける０の個数を初期化する：Ｚ＝０
時間Ｔの間、以下を実行する：
新しいｓａｌｔ値Ｖを選択する
ＨＶ＝一方向ハッシュ（Ｋ，Ｘ，Ｖ）を計算する
ＨＶ内の先行ニブルの個数、Ｙを計算する
（Ｙ＞Ｚ）ならば
Ｓ＝Ｖ，Ｈ＝ＨＶ，Ｚ＝Ｙ
例えば、２４個の先行０は、通常、１ＧＨｚのＣＰＵを搭載する従来のＰＣ上で、この方法により、１分未満で得ることができる。
【００３２】
以下に示されるように、コールサインを構成する先行０の後に続くビットのグループである、数Ｌは、４０ビット未満となることは滅多にないであろう。先行０の個数Ｚに対する実用的な範囲は、２４から８８までの間である。２４から８７までの間の値は、以下の公式を使用して符号化できる。
Ｚ＝２４＋Ｒ
【００３３】
この公式では、Ｒは、０から６３までの間で変化する数値である。これと同等のことであるが、以下の公式を使用することもできる。
Ｚ＝２４＋２＊Ｐ
【００３４】
Ｐは、０のペアの個数を符号化する０から３１までの範囲の数値である。０から３１までの間の数は、単一の英数字文字として符号化できるため、かなり実用的である。単一の英数字文字に符号化できる十分な個数の０を見つける修正されたプロセスは以下のとおりである。
【００３５】
見つける０のペアの個数を初期化する：Ｚ＝０
以下を繰り返す：
新しいｓａｌｔ値Ｖを選択する
ＨＶ＝一方向ハッシュ（Ｋ，Ｘ，Ｖ）を計算する
ＨＶ内の先行ペアの個数、Ｙを計算する
（Ｙ＞Ｚ）ならば
Ｓ＝Ｖ，Ｈ＝ＨＶ，Ｐ＝Ｚ
Ｚが２４よりも大きくなり、また時間Ｔが経過するまで
Ｚ＝Ｚ−１２を設定する
次のトレードオフは、値Ｌおよび時間Ｔの選択である。後でその選択について説明する。
【００３６】
カジュアルなやり取りに適しているコールサインは、０の個数Ｚの符号化およびＬ個の選択されたビットの符号化を含む、論理コールサインのデジタルまたは英数字符号化を使用することにより得られる。コールサインを構成するＺ＋Ｌビット３０４は、いくつかの５ビットセグメントに分割できる。それぞれの５ビットセグメントは、英数字文字により表される。英数字文字は、その後、コールサイン３０５に組み立てられる。そして、最後に、１つまたは複数のセパレータが追加され、最終的なコールサイン３０６が形成される。また、先行「Ｑ」を削除するなどのコールサイン短縮化規則を採用することもできる。
【００３７】
図４に、コールサインを決定するプロセスを示す。ステップ４０１で、区別された修飾子が構成される。ステップ４０２で、区別されたｓａｌｔ値が見つけられる。ステップ４０３で、区別されたｓａｌｔ（Ｓ）、パーソナライゼーション情報文字列（Ｘ）、および公開鍵（Ｋ）がＭ個のビットにハッシングされる。ステップ４０４で、ハッシュから先行０の個数が見つけられる。ステップ４０５で、ハッシュから先行０の個数（Ｚ）が取り出される。ステップ４０６で、ハッシュからビットの個数（Ｌ）が取り出され、コールサインに入れられる。そして最後に、ステップ４０７で、ＺおよびＬ個のビットの英数字表現を見つけてコールサインが形成される。
【００３８】
（コールサイン検証手順）
第三者がコールサインを受け取ると、コールサインの意図された所有者に、公開鍵Ｋ、パーソナライゼーション情報文字列Ｘ、および区別されたｓａｌｔＳの値の提示を要求することにより、コードサイン、公開鍵、およびパーソナライゼーション情報文字列の間の関連を検証する。第三者は、証明書を使用して、Ｋ、Ｘ、およびＳから区別されたハッシュを計算する。その後、先行０の個数がコールサインの中に表されている値Ｚと一致することを検証し、値Ｚが所定の最小値以上であることを検証し、コールサインの中に符号化されているＬ個のビットがハッシュ値の中の対応するビットと一致することを検証する。追加予防策として、ベリファイアは、パーソナライゼーション情報文字列Ｘが予想される自然な値に対応するかどうかを「目視」検査する。
【００３９】
すでに述べたように、パラメータＴおよびＬは、セキュリティおよびスケーリングを考慮したうえで選択される。上記のプロセスは、試行が実行される期間Ｔ、および選択されたビットの個数Ｌの２つのパラメータを持つ。これらのパラメータは、所定の個数のエントリに合わせてスケーリングする必要性、スプーフィングが簡単にできてしまうことのないようにする必要性、および将来にわたって使い続けられるようにする必要性、つまり、ムーアの法則に耐える必要性によって決まる。さらに考慮すべきなのは、「カタログ」攻撃に対する抵抗力である。
【００４０】
（起こり得るスプーフィング攻撃を考慮したＬおよびＴの選択）
公開鍵を短い署名にリンクするプロセスでは、攻撃者が同じ署名が得られる他の公開鍵を見つける、スプーフィング攻撃に注意しなければならない。
【００４１】
一般的な防御方法は、公開鍵を生成することの難しさに依存することである。署名が公開鍵とある種の固定されたテキストのハッシュであり、署名がＬビット長の場合、攻撃者は、一致するものを見つけるのに２＾Ｌ個の公開鍵を生成しなければならない。当業者であれば、公開鍵を生成する作業は、非常に費用のかかる演算である、２つの長い素数を見つける作業を伴うことを理解するであろう。しかし、標準の鍵生成ソフトウェアを使用して一致する鍵を見つけようとするのは無能な攻撃者だけであろう。その代わりに、攻撃者は、以下のようなプロセスを使用することもありえる。
第１の素数を取得する。
素数をリストに追加する。
以下を繰り返す：
新しい素数Ｐを取得する。
リストに含まれる各素数Ｑについて以下を繰り返す：
Ｎ＝Ｐ＊Ｑ（単純乗算）を計算する
Ｎに関連付けられている公開鍵Ｋを計算する
ハッシュ（Ｋ，パーソナライゼーション情報）を計算する
Ｉｆ（ハッシュがターゲットに一致する）
／／われわれの勝ち
ＲＥＴＵＲＮ（Ｐ，Ｑ）
ＥＮＤ ｉｆ
ＥＮＤ Ｆｏｒ
Ｉｆ リストのサイズ＜最大サイズ
Ｐをリストに追加する
Ｅｎｄ ｌｉｓｔ
Ｅｎｄ ｒｅｐｅａｔ
【００４２】
このプロセスでは、サイズＭの最大リストの場合、素数計算は平均してＭ回ループする毎に１回発生するだけである。大きなＭを選択することにより、攻撃者はコアループの実行時間に対する素数生成の影響を効果的に最小限に抑えるが、最後にはハッシュ関数のコストに支配されることになる。公開鍵生成の複雑度に依存することは、効率的な防御手段とはいえない。
【００４３】
Ｚ個の先行０を含むハッシュを見つけるために、ジェネレータは、約２＾（Ｚ）回の演算を実行しなければならず、したがって、対応するハッシュを見つけるために、攻撃者は約２＾（Ｚ＋Ｌ）回の演算を実行しなければならなくなる。ＺおよびＬの十分に大きな値を選択することにより、コールサインに対するスプーフィングが困難であることを保証し、しかも素数の生成に関して仮定を設けなくてよい。
【００４４】
他のよく知られている防御は、「Ｎのべき乗ハッシュ」と呼べるものを取得するために、ハッシュ関数のコストを、例えば、標準ハッシュを数回実行することを要求して高める方法である。暗号化の考慮事項とは無関係に、ハッシュ関数のコスト増大が対称的であることが欠点であり、コールサインの生成およびその検証の両方に適用される。これは望ましい特性ではない。スプーフィング攻撃を阻止するために生成に多量の計算を必要とする可能性のある、非対称なセットアップが望まれることもあるが、リーダーに過度の負荷をかけないために検証は非常に高速である。
【００４５】
コールサインプロセスでは、ジェネレータが、十分な数の先行０を見つけるため何回も試行を実行する必要がある。これは、長い生成時間を必要とする場合があるが、検証時間には影響を及ぼさず、単純ハッシュ比較よりもわずかに遅いだけである。
【００４６】
（将来にわたって使い続けられるようにすることとムーアの法則とを考慮したＬおよびＴの選択）
時が経つうちに計算能力が進化することも、通常は、ハッシングアルゴリズムの暗号強度の評価の際に考慮される。ムーアの法則によれば、与えられたコストに関して利用可能な計算能力は、ほぼ１年半毎に倍になり、３年毎に４倍になる。つまり、他はすべて同じであるとすると、攻撃者が利用できる計算能力の大きさは、１年半毎に倍になるということである。別の言い方をすると、現在１００万年かかる攻撃も、今から３０年後には１年以内で済むようになるということである。現在破ることが不可能なように見えるコードも、十分に難しくするか、「将来にわたって使い続けられるようにする」のでない限り、将来的にはいとも簡単に攻撃される可能性がある。
【００４７】
将来の攻撃からコールサインを保護するために、最初の０の個数を、ムーアの法則に従うように選択する。これを行うことにより、ムーアの法則はコールサインのセキュリティに役立つ。長いコールサインが生成されるようにコードのオーバーディメンショニング（ｏｖｅｒ−ｄｉｍｅｎｓｉｏｎｉｎｇ）を行う代わりに、ムーアの法則に従って最初の０の個数を選択する。現在使用されているコードが含む０の個数は比較的少ないかもしれないが、数年以内に使用されるコードが含む先行０の個数は増えていることだろう。
【００４８】
新しいマシン上で新しいコードが生成される場合、今から３年後に生成プロセスに同じだけの時間を費やして、０が２つ付加されたハッシュを見つける。当業者であれば、生成のコストは２＾（Ｚ）に比例し、攻撃のコストは２＾（Ｚ＋Ｌ）に比例することを理解するであろう。生成に固定された時間を費やすようにすると、攻撃者側は攻撃をかけるのにその時間の２＾Ｌ倍の時間を費やす必要がある。つまり、攻撃は、３０年後も現在と同じくらい難しいということである。例えば、生成期間Ｔが１分に設定され、長さＬが４０ビットに設定された場合、スプーフィングされた値の生成は、現行マシンでは、ほぼ２００万年分の計算を必要とし、今後３０年間同様に生成されるコールサインも、スプーフィングには類似のマシン上で２００万年分の計算を必要とする。
【００４９】
しかし、この議論が適用されるのは、コールサインが短い期間にしか使用されない場合のみである。２００３年に１分かけて生成された４０ビットのコールサインを破るには、２００３年に利用可能な複数のコンピュータを使って２００万年分の計算をするか、つまり１年間、そのような２００万台のコンピュータを並列使用する必要がある。２０３３年に１分かけて生成された４０ビットのコールサインを破る場合も、その年に利用できる複数のコンピュータを使用して２００万年分の計算をする必要がある。しかし、２０３３年の複数のコンピュータは、２００３年のコールサインをわずか２年以内に破ることができる。
【００５０】
そのため、コールサインには、何らかの形の陳腐化が生じる。ある特定の年に生成されたコールサインは、おそらく、かなりの年数の間、使用されないであろう。コールサインの全体的回復力は、生成に費やされた時間とビットの個数Ｌとに依存する。生成プロセスを長くとることで回復力を高められ、生成時間Ｔを倍にする毎に、ムーアの法則の繰り返しから保護される。さらに他の実施形態では、本当に強いサインは、生成プロセスを長時間にわたって実行することにより形成することができる。
【００５１】
さらに他の実施形態では、有効期限をコールサインに関連付けることにより妥当な保護が実現される。これは、相手の実際の公開鍵を見つけるために、コールサインがブートストラップメカニズムとして使用される場合に特に魅力的である。公開鍵が見つけられた後、コールサインの中に表されている圧縮情報ではなく、完全な情報を使用できる。完全な情報は、陳腐化に対する脆弱性がかなり低い。
【００５２】
（自然な衝突の可能性を考慮したＬおよびＴの選択）
攻撃がない場合でも、短いコードには問題があって、それは２人のユーザが同じコールサインになる鍵、パーソナライゼーション情報文字列、およびｓａｌｔ値の組合せをたまたま選択した場合に生じる「自然な」衝突の可能性である。
【００５３】
コールサインで使用されるビット長Ｌは、コールサインを短くしておくために制限されるが、コンピュータユーザの母集団（「Ｐ」）は非常に大きなものとなりうる。例えば、当業者に知られている方法を使用して衝突の確率が５０％未満となるようにＰ＝１０＾１０の母集団内のコンピュータユーザ毎に少なくとも１つのコールサインを割り当てると、長さＬは６７ビットを越えることになる。衝突の確率が１％未満でなければならないとすれば、Ｌは７３ビットよりも大きくなければならない。
【００５４】
このように大きなビット列は、１５英数字コールサインで符号化されるであろう。このような長さは、コールサインの実用的な長さを超えている。つまり、衝突の可能性を完全に排除することは、パーソナライゼーション情報文字列に電子メールアドレスなどの一意的なトークンが埋め込まれており、この一意的なトークンがコールサインと一緒に安全に転送された場合にしか実用的でない。
【００５５】
コールサイン長は制約されており、衝突が発生するので、衝突を検出する方法が採用される。衝突は、コールサインの解決を使って解決される。衝突がある場合、リーダーはコールサインに関連する公開鍵、パーソナライゼーション情報文字列、およびｓａｌｔ値の複数のバージョンを取得し、そのすべてが第１レベルの検証プロセスをパスする。リーダーは、パーソナライゼーション情報文字列に基づいて「正しい」または「予想される」バージョンを選択する。衝突解決プロセスは、以下のステップまたはその同等の手順を実行することにより繰り返すことができる。
１）コールサインの探索を開始する。
２）コールサインに関連する公開鍵、パーソナライゼーション情報文字列、およびｓａｌｔ値を取り出す。
３）そのような利用可能なエントリがない場合、探索は失敗として終了する。
４）一方向関数を使用して検証を実行する。失敗した場合には、ステップ２を繰り返す。
５）パーソナライゼーション情報文字列が予想される値と一致した場合、探索は成功し終了する。
６）パーソナライゼーション情報文字列が一致しない場合、ステップ２を繰り返す。
【００５６】
解決プロセスが効率的な場合、鍵は、衝突解決メカニズムと親和性のある衝突の頻度を維持できる十分な長さであればよい。例えば、パーソナライゼーション情報文字列の長いリストを延々と調べるのは不効率である。当業者であれば、衝突がかなりまれなことであり、２＾ＬがＰよりも十分に大きい、つまりＬ＞ｌｏｇ２ Ｐならば、２、３の一致するエントリを伴うだけであることを理解するであろう。
【００５７】
（ＬおよびＴを選択する際の定量化）
コールサインの第１の実施形態は、一組の英数字文字からなる。それぞれの文字は、５ビットの情報を符号化したものである。長さを考慮した場合については、コールサインの第１の実施形態は、長さ１０文字を超える英数字であってはならない。１０個の文字のうちの１つは、０の個数Ｚを符号化したものである。残り９文字は、Ｌビットを符号化したもので、１文字につき５ビットを使用した場合には、Ｌを４５ビットとする。Ｌ＝３５、４０、または４５ビットのコールサインの他の実施形態も可能である。第１の実施形態について、４５ビットのうちのＬに到達した際に、上記の基準は、当業者に知られている方法を使用して定量化されている。Ｌの値には、値のうちどれにアクセス可能かを知るための定量化可能な測定基準を割り当てることができ、同様に、０の探索に費やされなければならない時間Ｔも定量化されている。
【００５８】
前のセクションでは、スプーフィング攻撃、カタログ攻撃、自然な衝突、および年月のたつうちに高まる計算能力について述べたが、以下の基準で要約される。合計Ｚ＋Ｌは、スプーフィングを防止できるように十分大きくなければならない。０の個数Ｚは、計算時間Ｔに対応する。積Ｔ＊２＾Ｌは、数回のムーアの法則の繰り返しを考慮した場合であっても、スプーフィングを防止できるように十分大きくなければならない。パーソナライゼーション情報文字列は、カタログ攻撃を阻止できるように十分一意的なものでなければならない。長さＬは、ポータブルな母集団サイズを与えた場合に、名前衝突の発生がまれであるように十分に長くとらなければならない。
【００５９】
（スプーフィング攻撃を考慮したＬおよびＴの選択における定量化）
図５は、スプーフィング攻撃を無効化することに基づく長さＬおよび時間Ｔの選択を示す表である。この表は、サインを破るのに何年分の計算が必要になるかを、ビット数（３５、４０、または４５）および費やされる計算時間Ｔ（１５、６０、２４０、９６０、または３８４０秒）の関数として示している。この表では、二重下線および太字の値は、１００，０００年未満である。鍵を破るのに必要な計算は、コンピュータネットワークに容易に分散させることができる。当業者であれば、以前には１００，０００台のコンピュータで構成されるネットワークを使用すれば暗号チャレンジを破ることができたことを理解するだろう。コールサインをそのようなネットワークへの少なくとも１年のクラッキングに抵抗するようにするために、３５ビットのＬは、０の探索が少なくとも４分間持続しない限り最良の選択とはいえない。
【００６０】
１０，０００，０００年よりも大きな値は、一重下線付きの斜体であり、これらの値は、１００，０００台の現在のコンピュータのネットワーク上で１００年分の計算を必要とする。表からわかるように、４５ビットのＬであれば一般的には安全である。１６分以上の０に対する探索時間（Ｔ）と組み合わせて４５ビットのＬを使用すると、１０年間有効であり続ける可能性のあるコールサインが得られる。
【００６１】
（カタログ攻撃を考慮したＬおよびＴの選択における定量化）
図６は、Ｌビットから形成される様々なコールサインおよびＴ秒間に計算される区別されるｓａｌｔｓ値に対するコールサインの脆弱性を示す表である。コールサインのような短いコードは、スプーフィング攻撃の一変種である、「カタログ」攻撃を受ける可能性がある。この攻撃では、一人の攻撃者または複数の攻撃者のグループは、多数のコールサイン「ソリューション」を生成し、それらをデータベース、つまりカタログに格納する。それぞれのソリューションは、攻撃者に知られている公開鍵およびコールサインの特定の値をリンクする。当業者であれば、この表は、さらに、１００，０００台のコンピュータのネットワークにより１年で構築可能なカタログのサイズを示すことを理解するであろう。「脆弱性」の欄は、カタログが少なくとも１つの有効なコールサインを含むためにネットワーク内に存在していなければならないカタログ化された名前の出現回数を示す。
【００６２】
当業者であれば、カタログ攻撃は、ポピュラーなパーソナライゼーション情報文字列に対してのみ適用可能であることを理解するであろう。パーソナライゼーション情報文字列がユーザの名前と名字のみを含んでいた場合、カタログ攻撃はほとんど効力を持たないであろう。
【００６３】
他の実施形態では、パーソナライゼーション情報文字列に追加トークンを含めることにより、一般名の出現頻度を減らし、コールサインのセキュリティを強化することが可能である。例えば、市および国の名前をパーソナライゼーション情報文字列に追加することができる。すると、カタログ攻撃は、パーソナライゼーション情報の中に同じ追加トークンを持つユーザしかターゲットにできない。例えば、同じ名前と名字を持ち、同一市内に居住するユーザである。当業者であれば、これらのユーザは比較的小さな母集団を形成することを理解するであろう。当業者であれば、市内にそのようなユーザが数百人以上いることは滅多にないことを理解するであろう。この表から、４５ビットのビット長Ｌと４分（２４０秒）の持続時間Ｔとの組合せで、本出願において十分なセキュリティが確保されることがわかる。
【００６４】
さらに他の実施形態では、パーソナライゼーション情報文字列は、電子メールアドレスなどの一意的なトークンを含み、このトークンがコールサインの一部として安全に受け渡された場合、カタログ攻撃は無効化される。このようなカタログ攻撃を成功させるのは、スプーフィング攻撃と同じくらい難しい。
【００６５】
（不愉快な識別子の回避）
コールサインを生成するのは運任せなので、「ＩＡＭ−ＳＯ−ＤＵＭＢ」などの非常に望ましくないコールサインが生じる可能性がある。ランダムに選択されるため、禁句の４文字語など、明らかに不快感を与える単語を含むコールサインが生じることすらある。
【００６６】
これらの出現を排除する最も確実な方法は、提案されたコールサインをユーザに提示し、ユーザに、提案された値を受け入れてもらうか、または他の値を要求してもらうことである。計算を１６個の順次ステップとして設計すると、他のコールサインを素早く再生成しやすい。コールサインが拒絶された場合、他の実施形態では、完全に新規の計算に要する時間のわずか１／１６の時間を使用し、手順の本当に最後のステップを繰り返すことで十分である。コールサインが最終のハッシュステップにより導かれる設計が維持されている場合、さらに他の実施形態では、その段階で最終のｓａｌｔ値を導入し、乱数を単純に選んで新しいコールサインを導くようにすることが可能である。
【００６７】
さらに他の実施形態では、生成プロセスに「望ましくないキーワード」のリストを含めるステップを追加することにより望ましくないコールサインに対する保護を埋め込む。キーワードを含めるこのような保護は、コード自体をいくぶん不快なものとする。しかし、他の実施形態では、２進数値の英数字符号化が問題となる。そこで、実際のキーワードではなく、符号化された２進数値をプログラムに含めることができる。これらは、存在するが、読み取り不可能な形式である。
【００６８】
（ＩＩ．要求された０の個数が証明書により設定されるコールサインの第２の実施形態およびそれらを生成する方法）
第１の実施形態では、いくつか改善余地がある。コールサインの中の０の個数を符号化する必要がない場合があり、したがって、より短いコールサイン、または等しく長いが有効ビットの大きい方の数Ｌを含むコールサインを考慮する。また、英数字符号化とともに望ましくない結果が生じることがある。そのため、不注意で、不快な言葉を含む「読み取り可能な」文字列が生じる可能性がある。コールサイン生成プロセスにより、そのような単語が回避されるようにしなければならない。
【００６９】
（第２の実施形態における０の個数の符号化）
第１の実施形態の０の個数の符号化は妥協である。０の個数は、常に、２４よりも大きく、９８よりも小さく、また０の個数ではなくペアの個数を符号化することで十分な精度が得られると想定する。
【００７０】
より基本的なこととして、コールサイン内の０の個数の符号化では、コールサインの所有者は、必要な０の個数を決定しなければならないという点が挙げられる。第１の実施形態では、区別されたｓａｌｔを探すのに費やされる時間は固定されており、またその時間内に見つけられる０の個数は、「ムーアの法則に従い」、その年のコンピュータの平均能力を表すと仮定している。しかし、制限時間が固定されているため、コールサインを生成するために使用されるコンピュータの能力とそのコールサインの強度との間に依存関係が生じる。第２の実施形態では、０の必要な個数は、コールサインの受信者により決定されると仮定する。
【００７１】
この実施形態では、検証コード内にチェックを符号化する。コールサインの受信者は、公開鍵Ｋ、識別子Ｘ、および区別されたｓａｌｔＳを取得し、その後、ハッシュ内の０の個数Ｚが、年Ｙおよび有効ビットの個数Ｌの関数である、最小値よりも大きいことを検証する。
Ｚ＞Ｚ０−Ｌ＋（Ｙ−２００３）／Ｘ
【００７２】
この公式では、数Ｚ０は、２００３年に十分強度があると考えられた鍵の長さを表すように設定されている。係数Ｘは、平均的なコンピュータの能力が倍になるのに要する年数を示す。実用的な実装に関して、ムーアの法則に従ってＸの値を１．５に設定し、Ｚ０の値を６２に設定すると、以下の公式が得られる。
Ｚ＞６２−Ｌ＋（Ｙ−２００３）／１．５
【００７３】
この公式では、数６２は、１００，０００年分の計算が十分な障害となると仮定して計算された値である。実際、「バー」は、コールサインが使用される背景状況にかなり依存することがある。財務用途では、さらに大きな値、例えば、６６（１，０００，０００年）を必要とする場合がある。軍事用途だと、なおいっそう条件が厳しい。
【００７４】
図７に、第２の実施形態によるコールサインの構成を示す。コールサインは０の個数を符号化しないため、第１の実施形態と同じハッシュ関数を使用することはできない。コールサインを構成するＬ個のビットは、区別されたハッシュ内の固定位置に置かれるが、０は他の固定位置の後に数えられる。
【００７５】
（ＩＩＩ．コールサインのパッセージのＡＳＣＩＩへの英数字符号化）
図８および図９に、コールサインの英数字符号化を示す。コールサインを作成する際に、互いに区別しやすく、転記の誤りを生じがちでないコールサインの英字および／または数字を選ぶことが望ましい。ピア識別子には、英数字表現が割り当てられる。これらの実施形態で選択された符号化例では、結果として得られるコールサインの中で、数０および１または英字ＯおよびＩを使用しない。当業者であれば、これらの英字は、互いに混同しやすい傾向があるため使用されないが、他の実施形態ではそれらの文字を使用できることを理解するであろう。当業者であれば、さらに、他の実施形態では、他の文字を排除するか、または追加することができることも理解するであろう。当業者であれば、発明の他の実施形態は、実際には、ローマ字とアラビア数字に限定されないことを理解するであろう。当業者であれば、さらに、すべての数字またはすべての文字は、所望の数の記号が生成できる限り使用できることを理解するであろう。実施例では、不要な文字を削除することで、８個の数字と２４個の英字を残し、図に示されているように３２個の記号が得られる。
【００７６】
上述のように、コールサインを生成する際に、このプロセスでは、コールサイン内で使用するために選ばれたそれぞれの文字について０から３１までの数値を割り当てて、３２個の利用可能な記号を出力する。コンピュータによりコールサインが読み取られると、コールサインの各文字は、コンピュータメモリ内で数値を割り当てられる。コールサインがコンピュータから出力されるときに、コンピュータ内でコールサインを構成するそれぞれの数に対し、ユーザに出力されるコールサインを構成する数字または英字を割り当てる。コールサインを構成する文字の組合せは、コールサイン生成手順により選択される。その後、コールサイン検証手順によりその有効性がチェックされる。
【００７７】
（ＩＶ．ピア名解決プロトコル（ＰＮＲＰ）内で適用されるコールサイン）
図１０は、ピアツーピアコールサインの一実施形態を利用するピアツーピアネットワークのブロック図である。ピアツーピアネットワーク技術では、１つまたは複数の分散ネットワーク上でリアルタイム通信を実現する。ピアツーピアネットワーキングは、サーバレス技術である。ピアツーピアネットワークでは、個々のＰＣは、インターネットサービスを使用せずに、データの交換、資源の共有、他のユーザの特定、通信、および協働をリアルタイムで行うことができる。ＰＣは、通常、ＰＣがピアツーピアネットワークに結合されている場合にピアツーピア通信を可能にするアプリケーションソフトウェアを備える。この種のネットワークでは、ピアコンピュータはそれぞれ、独自のセキュリティの維持を受け持つ。そのため、認定ユーザの検証および衝突しているアドレスの解決は、サーバベースのネットワークといくぶん異なる方法で実行されるタスクである。
【００７８】
ピアグループに接続し、その後、ピアグループに参加することは、ユーザを識別する際にセキュリティ対策を利用するピアネットワークでの一般的なタスクである。グループに参加するには、ピアコンピュータは、ピアグループの所有者から招待を受ける。グループ所有者から招待を受け取るには、仮グループメンバがまず、ピア名および公開鍵である識別資料をグループ所有者に受け渡さなければならない。この情報は、電子メール、ファイル共有、ＸＭＬなどを使用して受け渡される。グループ所有者は、次に、招待を仮グループメンバに発行する。
【００７９】
仮グループメンバは、その情報を受け取ると、招待情報を使用して、グループに接続する。グループに接続するために、仮グループメンバは、ＰＮＲＰとグループＩＤを使用して、グループメンバのアドレスを解決し、そのグループメンバを通じてピアネットワークに接続する。
【００８０】
仮グループメンバと現在のグループメンバとの間の相互認証は、通常は、信頼できるＷｅｂを通じて実行される。相互認証の後、仮グループメンバが、単一の隣接者を持つ新しいグループメンバとなる。隣接者は、接続を受け入れ、認証が実行されたピアネットワークからのコンピュータである。
【００８１】
特に、ピアツーピアコンピュータネットワークへの接続に関して、ピアツーピアネットワークは、ネットワーキング用の一組のネットワーキングアプリケーションプログラムインターフェース（「ＡＰＩ」）を提供する、インフラストラクチャネットワーキングソフトウェアを含む。これらのピアツーピアアプリケーションは、協働通信、コンテンツ配信などに関係する場合がある。ピアツーピアインフラストラクチャＡＰＩソフトウェアは、ピア名解決プロトコル、マルチポイント通信、分散データ管理、セキュリティ保護されたピアＩＤ、およびセキュリティ保護されたピアツーピアグループなどのコンポーネントを含むことができる。
【００８２】
ピアツーピア名前解決プロトコル（ＰＮＲＰ）を使用すると、ピアツーピアネットワーク内のピアは、通常であればサーバベースのネットワーク内では必要になるようなサーバを必要とせずに、「ピア名」を解決することができる。ＰＮＲＰでは、ピアコンピュータは、ネットワーク内の他のコンピュータ、つまりピアを識別することができる。ピア名解決プロトコルは、複数のエンドポイント、または衝突の生じうるネットワーク内の複数のノードへの名前のピアツーピア解決を可能にするアプリケーションプログラムインターフェース（ＡＰＩ）を備える。
【００８３】
ピア名解決プロトコル（ＰＮＲＰ）ＡＰＩは、コンピュータノードがピアツーピアネットワーク内で互いに見つけ合うことができるようにすることにより参加ピアのグループが互いにやり取りできるようにする名前−ＩＰ解決プロトコルである。通常であればピアツーピアネットワーク内で提供されるタスクとしては、ピア名の登録および登録解除、ピア名の解決、およびピアのグループの列挙がある。当業者であれば理解するように、ピア名の解決は、互いに衝突しないピア名を見つけることを含む。互いに衝突しない名前を見つけることに加えて、見つかった名前は十分なセキュリティが対策され、ユーザがそのピア名を覚えられることが望ましい。
【００８４】
ピア名は、コンピュータ、ユーザ、グループ、またはサービスを識別できる安定した名前である。ピア名は、通常、ピアがセキュリティ保護されているかどうかを示す権限および単に文字列である分類子を含む。当業者であれば理解するように、セキュリティ保護されたピア名では、通常、セキュリティ保護されたハッシュアルゴリズム（ＳＨＡ−１）またはＭＤ５アルゴリズムを使用して、１２８ビットＰＮＲＰ識別子を導き、公開鍵Ｋを分類子Ｃにハッシングし、ピア名のセキュリティ保護された伝送を実現することができる。第３の実施形態では、Ｃは識別子Ｘ、ｓａｌｔ Ｓ、およびハッシングアルゴリズムの識別を含む。
【００８５】
暗号鍵は、ネットワーク通信内のセキュリティ対策のための当業者に知られている仕組みである。暗号鍵は、一般的に、アクセスの許可およびソースの識別の検証のためピアツーピア環境で使用される。暗号鍵を使用すると、鍵を所有している人は、その鍵が関連付けられているデータにアクセスしたり、または鍵所有者の電子署名を作成したりすることができる。公開鍵アルゴリズムは、通常、Ｋ／Ｐと表される、公開鍵と秘密鍵からなるペアを備える。秘密鍵は、メッセージの受信者への識別子として使用できるため、秘密に保ち、セキュリティ保護されなければならない。公開鍵は、自由に配布でき、他人がメッセージを自由に復号化できる。鍵ペアの公開鍵は、デジタル証明書とともに配布されることが多い。鍵ペアの一方の鍵がメッセージの暗号化に使用される場合、そのペアの他方の鍵は、メッセージの復号化に使用される。
【００８６】
これらの鍵は、長くなる傾向があり、通常は、少なくとも２５６個の１６進数である。そのため、それらを受け渡し、特に公開鍵を受け渡すのは、面倒な場合がある。インスタントメッセージングまたは電子メールは、使用できるが、改ざんを受けやすく、鍵の検証を望ましいものとする。また、鍵の検証のプロセスに、鍵を受け取る人が、送信者が鍵を送信する相手として意図している人であるかどうかの検証を含むことも望ましい。
【００８７】
（ＩＶ．ピアツーピア名前解決プロトコルに適用されるようなコールサインの第３の実施形態）
ピアツーピア名前解決プロトコル（「ＰＮＲＰ」）では、ピアはサービスを伴わずに「ピア名」を解決することができる。ＰＮＲＰピア名は、第１に、公開鍵のＳＨＡ−１ハッシュである「ａｕｔｈｏｒｉｔｙ」とＵｎｉｃｏｄｅテキスト文字列である「ｑｕａｌｉｆｉｅｒ」の２つのフィールドで構成される。ＰＮＲＰは、以下のような暗号ハッシング関数を使用して、これら２つのフィールドから１２８ビットＰＮＲＰ−ＩＤを導く。
ＰＮＲＰ−ＩＤ＝ｈａｓｈ（ａｕｔｈｏｒｉｔｙ，ｈａｓｈ（ｑｕａｌｉｆｉｅｒ））
【００８８】
この第３の実施形態は、ＰＮＲＰを「コールサイン」で強化する。ＰＮＲＰのコールサインを生成するために、ユーザは、「区別された修飾子」を生成する。権限、区別されたｓａｌｔ値、および区別された修飾子の組合せの結果として、多数の０から始まるＰＮＲＰ−ＩＤが得られる。コールサインは、このＰＮＲＰ−ＩＤから導かれる。新しいＰＮＲＰ ＡＰＩを使用することにより、ユーザは、コールサインに一致するＰＮＲＰエントリを列挙し、その後、関連付けられている権限および修飾子を取得することができる。
【００８９】
（区別されたＰＮＲＰ修飾子）
区別された修飾子は、区切り記号「／／」および「／」により区切った、パーソナライゼーション情報文字列、二次ハッシュ関数の識別子、および区別されたｓａｌｔ値から形成される。当業者であれば、パーソナライゼーション情報文字列の内容は、コールサインが使用されるアプリケーションによって異なることがあることを理解するであろう。例えば、ＰＮＲＰコールサインの実施例では一意的なパーソナライゼーション情報文字列を使用するが、他のアプリケーションでは、異なるパーソナライゼーション文字列を必要とする場合がある。
【００９０】
当業者であれば、これらの文字列は、区切り記号または当業者に知られているその他の同等の方法により区切られることを理解するであろう。当業者であれば、さらに、文字列の順序および使用される区切り記号は異なっていてもよいことも理解するであろう。
【００９１】
使用されるハッシュ関数は、さらに、区別された修飾子に含まれ、区切り記号により区切られる。当業者が理解するように、ハッシュ関数は当業者に知られている、十分なセキュリティ対策が施される型のものであればよい。例えば、ＳＨＡ−１ハッシュ関数またはその同等の関数がある。
【００９２】
ｓａｌｔは、コールサイン生成プロセス時に選択される。ｓａｌｔは、ピア名の二次ハッシュを実行することにより選択され、これにより、ハッシングされた結果は十分な数の０から始まる。ｓａｌｔ自体は、ＡＳＣＩＩ英数字からなる。正式な構文は以下のとおりである。
区別された修飾子＝＜パーソナライゼーション＞”／／”＜ハッシュ関数＞”／”＜ｓａｌｔ＞
区別された修飾子の例を以下に示す。
【００９３】
Qualifier:JonSmith<jsmith@yuhoo.com>//SHA1/A5E5F3Z4YWZTRF0TW9RTQ
ｓａｌｔは、権限および修飾子の二次ハッシュが多数の０から始まるように選択される。
【００９４】
（コールサインの第３の実施形態の生成）
コールサイン生成手順の目的は、ピア名および関連するコールサインが検証手順にパスできるようにする区別された修飾子を見つけることである。これは、適切な「区別されたｓａｌｔ」を見つけることを含むので、ピア名の二次ハッシュは、適切な数の０から始まる。
【００９５】
検証のセクションで示されているように、０の適切な個数は時間の経過とともに変わる。式
Ｚ＞１７＋（Ｙ−２００３）／１．５
は、それらの目的のために使用される。
【００９６】
生成目的に関して、値Ｙは、現在の年に設定すべきではなく、むしろ、コールサインが有効である期間の最終年に設定すべきである。既定では、これは、現在の年＋１０に設定される。
【００９７】
生成は、以下のように進行する。
１）検証手順において予想されるようにこの権限の正準形式を使用して、ＰＮＲＰに従って、ＰＮＲＰ名前権限の値を初期化する。
２）ユーザ名に応じてパーソナライゼーション情報Ｘの値を初期化する。
３）既定ＳＨＡ−１により、有効な二次ハッシュ関数を選択し、対応する識別子Ｉに注目する。
４）０の適切な個数Ｚを選択する。
５）数Ｎが数Ｚ以上になるまで以下を繰り返す：
ａ．Ｓａｌｔ Ｓを選ぶ。
ｂ．権限に基づくピア名および仮の区別された修飾子をＸ、Ｉ、およびＳに基づいて構成する。
ｃ．関数Ｉに従ってピア名のハッシュを計算する。
ｄ．このハッシュ内の０の個数（Ｎ）を測定する。
６）ピア名に関連付けられたＰＮＲＰ識別子を計算する。
７）ＰＮＲＰ識別子の最上位４５ビットに基づいてコールサインを構成する。
８）コールサインが不快な単語を含まないか検証し、もし含んでいれば、ステップ５を繰り返す。
【００９８】
ステップ５は、最新のコンピュータ上で約１５秒続くことが予想される。
【００９９】
生成関数の最後のステップは、コールサイン内の文字のランダムな集まりから何らかの不快な言葉が生じないかチェックすることを目的としている。これは、提案されたコールサインを使用することを受け入れるかどうかをユーザに問い合わせることにより実装できる。
【０１００】
（第３の実施形態で生成されるコールサインの検証）
コールサイン検証手順では、ピア識別子とコールサインとを比較し、二次ハッシュが十分な数Ｚの先行０を含むことを検証する。先行０の個数を検証することにより、コールサインに対する第三者によるスプーフィングが難しくなる。第１近似では、コールサインの暗号強度は、長さがＺ＋４５の対称鍵の強度に等しい。Ｚの値は、時間の経過とともに変化する場合がある。ムーアの法則から、コンピュータはますます強力になることが予測されるので、Ｚに対する長さ要件は増大する傾向にある。予見可能な将来にわたってムーアの法則が成立すると仮定した場合、先行０の個数Ｚに対する値は、現在の年Ｙの関数であると考えることができる。
Ｚ＞１７＋（Ｙ−２００３）／１．５
【０１０１】
当業者であれば、上の不等式の中で使用される値１７は、選択されたセキュリティと計算とのトレードオフの関係に対応し、また条件がきつい環境ほど、選択される値は大きくなる可能性があることを理解するであろう。
【０１０２】
コールサインを検証するために使用される二次ハッシュ関数は、時間の経過とともに変化しうる。現在の実装では、当業者に知られているハッシュ関数ＳＨＡ１が使用される。他の実施形態では、受け入れ可能なハッシュ関数のリストは、使用できるようにコンピュータメモリに保持することができる。特に、セキュリティが向上するようにハッシュ関数の開発が続けられることも予想される。本発明の実施形態は、新しいハッシュ関数が現れたときの将来の使用を規定することにより新しいハッシュ関数の開発に対応できる。
【０１０３】
検証は、以下のように進行する。
１）ピア名に関連付けられたＰＮＲＰ識別子を計算する。
２）ＰＮＲＰ識別子の最上位４５ビットとコールサイン内に符号化されている４５ビットとを比較する。
３）４５ビットが一致しない場合、検証は失敗である。
４）区別されたｓａｌｔから二次ハッシュ関数の識別子を抽出する。
５）ハッシュ関数識別子がない、または証明書が受け付けない、または有効な値として認識されない場合、検証は失敗である。
６）ピア名全体の正準化されたバージョンのハッシュを指定された二次ハッシュ関数とともに計算する。
７）その結果得られたハッシュ内の先行０の個数を測定する。０の個数がターゲット値Ｚよりも小さい場合、検証は失敗である。
８）識別文字列がコールサインにより指定された人またはエンティティの理にかなった説明となっていることを検証し、そうでなければ、検証は失敗である。
９）ステップ１から８がパスした場合、検証は成功である。
【０１０４】
ピア名の「正準化されたバージョン」を得るには、通常１６進数からなるピア名の権限部分が必ず数字と大文字Ａ、Ｂ、Ｃ、Ｄ、Ｅ、およびＦのみで符号化されているようにする。ステップ８は、通常、人間による対話操作を伴うことに注意されたい。
【０１０５】
（コールサインからのＰＮＲＰレコードの取り出し）
場合によっては、コールサインに関連付けられたＰＮＲＰレコード、したがって関連付けられたピア名を取り出すのが有益である。そうするには、ＰＮＲＰ識別子がコールサインと同じ４５ビットから始まるすべてのＰＮＲＰレコードを取り出し、対応するピア名を取り出し、検証手順のステップ１から７をパスできないピア名を取り除き、検証手順のステップ８を使用して、予想されるＩＤと一致する名前のみを残す。
【０１０６】
独占的権利または特権を主張する本発明の実施形態は、特許請求の範囲で定められる。
【図面の簡単な説明】
【０１０７】
【図１】ピアツーピアコンピュータネットワークにアクセスするために使用される標準的なセキュリティ保護されたユーザ識別を示す図である。
【図２】コールサインを発生する方法の第１の実施形態により生成される短縮されたコールサイン識別子の表現を示す図である。
【図３】コールサインの構成を示す図である。
【図４】コールサインを決定するプロセスを示す流れ図である。
【図５】Ｌビットから形成される様々なコールサインおよびＴ秒間に計算される区別されるｓａｌｔｓ値に対するコールサインの脆弱性を示す表である。
【図６】衝突頻度と４５ビットのビット長Ｌに対する集団の大きさとの対比を示す表である。
【図７】第２の実施形態によるコールサインの構成を示す図である。
【図８】コールサインの英数字符号化を示す図である。
【図９】コールサインの英数字符号化を示す図である。
【図１０】コールサインの第３の実施形態に使用されるようなコールサインを生成するプロセスを示す流れ図である。
【符号の説明】
【０１０８】
２０２ コールサイン識別子
【技術分野】
【０００１】
本発明は、ユーザをコンピュータネットワークに識別させるための比較的短い「コールサイン」に関する。
【背景技術】
【０００２】
鍵と暗号識別（「ＩＤｓ」）は、コンピュータシステムなど、ユーザの検証を必要とする多くのアプリケーションにおいて重要な役割を果たす。ピアツーピアコンピュータシステムの実施例では、ユーザ識別（「ＩＤ」）は、ＩＤが電子メールなどで電子的に提示される場合にユーザがネットワークにアクセスする権利を有することを検証する、システム管理者への証明書（ｖｅｒｉｆｉｅｒ）として使用することが可能である。それとは別に、ＩＤは、音声または筆記により伝達することもできる。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
以前には、ＩＤは、名刺を使用して、または口頭で、手作業により提示されていた。ＩＤは、通常、簡単に覚えられない２進数の長い数列である。ＩＤは、暗号化プロセスを使用してセキュリティ保護されるようにできる。しかし、保護されているＩＤは、通常、さらに長く、また簡単に回覧することも難しい。そのため、さらに、ユーザは暗号化でＩＤを保護する場合に使い勝手をあきらめる。
【０００４】
以下では、読者が基本的な理解を得られるように、開示について簡単に説明する。この「発明の開示」は、開示の広い範囲にわたる概要ではなく、また本発明の鍵となる／重要な意味を持つ要素を識別しない、または本発明の範囲を線引きすることもない。後で述べる詳細な説明の前置きとして、本明細書で開示されているいくつかの概念を簡略化した形式で述べることのみを目的とする。
【課題を解決するための手段】
【０００５】
本発明は、ユーザをコンピュータネットワークに識別させるための比較的短い「コールサイン」を実現する。このネットワークは、ネットワーク内の個々のコンピュータが他のネットワークの場合と比べてセキュリティを厳しくする必要のあるピアツーピアネットワークであってよい。コールサインは、ネットワークへの参加を求めるコールサインを提示する人に関する情報を組み込む。コールサインは、短く、覚えやすいが、従来のＩＤは、通常長く、覚えにくい。コールサインは、さらに、事前に計算される「ｓａｌｔ」値も組み込み、これにより、それ自身と個人情報のハッシュで、英字および数字を含むコールサインに容易に変換できる固定長の結果を出力する。個人情報以外の情報は、アプリケーションに応じてハッシングに取り込むことができる。
【０００６】
当業者であれば、暗号文によりセキュリティ保護されている短い簡単に覚えられるＩＤを持つことが望ましいことを理解するであろう。この種のコールサインは、必ず、覚えられるくらい十分に短いが、それでも、十分なセキュリティを提供し、ピアツーピアまたは他のネットワークの利便性を高めることができる。
【０００７】
本発明の付随する特徴の多くは、添付の図面に関して考察される以下の詳細な説明を参照することにより容易に理解できるため明白であろう。
【０００８】
以下の説明は、本開示の一部をなす、以下で手短に説明されている、図面の様々な部位を参照することで最もよく理解できるであろう。
【発明を実施するための最良の形態】
【０００９】
付属の図面に関して以下で述べる詳細な説明は、本発明のこの実施形態の説明として意図しており、本発明が構成または利用されうる唯一の形態を表すことを意図していない。この説明では、本発明の機能、および例示されている実施形態に関して本発明を構成し、動作させるステップの順序を規定する。ただし、同じ、または同等の機能および順序は、本発明の精神および範囲内に包含されることも意図している異なる実施形態により達成することが可能である。
【００１０】
本発明は、本明細書では、ピアツーピアコンピュータネットワークシステム内に実装されるものとして説明され、例示されているが、説明されているシステムは一実施例として提示されているのであり、限定するものとして提示されているのではない。当業者であれば、本発明は、様々な異なる種類のコンピュータシステムによるアプリケーションに好適であることを理解するであろう。
【００１１】
図１は、ピアツーピアネットワークまたは同等のネットワーク例にアクセスするために使用される標準的なセキュリティ保護されたユーザ識別を示す図である。ピアツーピアコンピュータネットワークは、サーバコンピュータなしで機能しうるコンピュータのネットワークであり、そのセキュリティに対する責任は、ネットワーク内のそれぞれのピアコンピュータが負う。周知のように、ユーザのアクセス権を識別し、検証するために使用される識別子１０１は、通常、極めて長い。このような２進数は、通常、１６０ビット長（１０２）であり、これは、４０桁の１６進数に等しい。識別子１０１の他の実施例としては、４０個の１６進数により表される数と任意長の文字列の２つの構成要素を含むＰＮＲＰ名がある。このような識別は、マシン以外では、容易に伝達することはできない。
【００１２】
多くのコンピュータネットワークは、「ピアツーピア」名前解決のプロセスで通常使用されるピア名の生成を必要とする場合がある。現在実装されているように、ピアツーピア名前解決プロトコル（ＰＮＲＰ）は、通常、ユーザに扱いやすい（十分なセキュリティ機能を持たない傾向がある）短いピア名を使用するか、またはユーザに扱いにくい（通常は、より高いレベルのセキュリティ機能を持つ）長い２進数列を含む長いピア名を使用することに制約される。当業者であれば、任意の種類のコンピュータネットワーク、またはセキュリティ保護され、短縮された識別ツールが望まれているシステムに、短縮された識別子を適用可能であることを理解するであろう。
【００１３】
長いピア名は、通常、暗号化プロセスを適用することにより、セキュリティ保護することが可能である。しかし、そのような長い名前は、通常、ユーザに扱いやすいものではない。長い名前は、通常、覚えておいてコンピュータネットワークへのアクセス権を得るために入力するのが難しい。つまり、最新技術では、通常、ユーザに対し利便性とセキュリティの択一選択を迫るのである。ピアツーピアネットワーク内で、安全な方法により、短く覚えやすい識別子を使用してコンピュータを識別する手段を実現することが望ましい。
【００１４】
（Ｉ．０の個数が明示されているコールサインの第１の実施形態およびそれらを生成する方法）
図２は、コールサインを発生する方法の第１の実施形態により生成される短縮されたコールサイン識別子２０２の表現を示す図である。特に、この本実施形態では、コールサイン内の「０の個数フィールド」を使用する。本明細書で説明されているピアツーピア識別（「コールサイン」）に対するセキュリティ保護されたコールサインを生成するシステムおよび方法を使用することで、ピアツーピアネットワーク（「Ｐ２Ｐ」）、および当業者に知られている他の同等のネットワークアプリケーションに使用することができる覚えやすいセキュリティコードまたはコールサイン２０２を生成する。特に、コールサインを構成する際に使用される特定の情報、および適用される暗号機能により、コールサインを様々なアプリケーションで使用することができる。例えば、コールサインおよびそれらのコールサインを生成する方法の一実施形態をピアツーピア名前解決プロトコル（ＰＮＲＰ）に適用することができる。他のアプリケーションは、限定はしないが、 を含むことができる。
【００１５】
ピアツーピア識別に通常使用されるコールサインを生成する方法により、ユーザのＩＤを安全に伝達するという難題を解決する。セキュリティは、セキュリティ保護されたプロセスを使用して、ユーザに覚えやすい、また入力しやすい短いコールサインを構成することにより実現される。そのようなコールサインに対し、暗号化プロセスにより強力な保護を行うことができる。例えば、「ＺＡ４−３Ｙ−４Ｗ−ＺＦ４」などのピアツーピア識別のコールサイン２０２は、短く、セキュリティ保護されている。このようなコールサインを覚えるのは、社会保障番号を覚えるよりも少し難しいだけである。
【００１６】
例示されているコールサイン例２０２は、１０個の英数字を含む。当業者であれば、それよりも多い、または少ない文字を含むコールサインを生成できることを理解するであろう。１０個のコールサイン文字はそれぞれ、５個の２進数ビット２０３を表す。これらのセグメントは、５つのビットセグメントに分割されているさらに長い２進数の一部分である。当業者であれば、５ビットよりも多い、または少ない長さの２進数を表すために同等の実施形態で使用できることを理解するであろう。
【００１７】
コールサインの桁の最初の桁は、この実施例を見るとわかるように、文字「Ｚ」である。この実施例では、第１の桁は、コールサインを復号化する際に使用される０の個数を伝達するように定義されている。ここで、文字Ｚは、５ビット２進数１１１１１である、１０進数３１を表すように定義されている。当業者であれば、本発明の同等の実施形態において、０の個数を識別する桁の配置、およびコールサイン内の０の個数は、異なっていてもよい。同様に、実施例では、「Ｚ」の代わりに任意のビットパターンまたは文字を選択できる。
【００１８】
このコールサインの残りの９個の英数字は、２進数の残り部分を表す。これらの桁は、（「Ｌ」）として指定される。この実施例では、Ｌは、長さが４５ビットである。２進数Ｌは、ユーザ識別を暗号化するために使用される暗号化プロセスの結果から取り出したものである。２桁目から１０桁目までの中の残りＬビットは、残りの９つの英数字にマッピングされる５ビットセグメントに分割される。当業者であれば、２進数の英数字へのマッピングは、テーブルルックアップ、公式、または当業者に知られているその他の同等な方法により実行できることを理解するであろう。当業者であれば、さらに、１０個の文字の順序付けは、同等な実施形態でも異なることがあることも理解するであろう。
【００１９】
０の個数および数Ｌをコールサインから復号化した後、２進数に対し暗号化処理が実行されて、ユーザのＩＤを再作成する。ユーザの識別が確立されたら、コールサインを保持している人に、ネットワークへのアクセス権およびその他の特権を付与することができる。
【００２０】
（区別された修飾子からのコールサインの第１の実施形態の生成）
名前を付けるべきエンティティは、従来通り生成された公開鍵／秘密鍵のペアＫ／Ｐ、およびパーソナライゼーション情報文字列、またはデジタルＩＤ、Ｘを所有していると仮定する。パーソナライゼーション情報文字列は、名前を付けるべきエンティティの自然な属性で構成することができる。例えば、パーソナライゼーション情報文字列は、一般名、会社名、市名、および電子メールアドレスなどの組合せを含むことができる。従来通り構成された公開鍵Ｋは、バイナリ文字列により表すことができ、パーソナライゼーション情報文字列は、テキスト文字列により表すことができる。
【００２１】
図３に、コールサインの構成を示す。コールサイン生成プロセスの第１のステップは、Ｓが暗号化一方向関数（「Ｈ（ｘ）」）３０８を通じてＫ３１０とＸ３０９とともにハッシュされた場合（３０７）に、結果が、多数の０から始まる、「区別された」ハッシュ値（「Ｈ」）３０１となる、「区別された」「ｓａｌｔ」値Ｓを見つけることである。コールサインを生成する後続のステップでは、特定の個数の０が必要である。区別されたｓａｌｔ値を見つける際に、与えられた時間間隔にわたって多数の値を試すことができ、所望の個数の０を生成する区別されたｓａｌｔ値が保持される。区別されたｓａｌｔ値により、ユーザが認証用のコールサインを提示した場合にコールサインが検証手順をパスするようにできる。
【００２２】
当業者であれば、先行０の代わりに特定のビットパターンを使用できることを理解するであろう。例えば、他の実施形態では、先行１、または最小個数の「０１１０」グループなどを利用することもできる。コールサインを生成する際に求めているのは、コールの一部が所定のパターンと一致していることであるが、コールサインを構成し、パターンを持たない傾向のあるビットの残りはコールサインの残りの桁を構成する。それとは別に、所定のパターンは、区別されたハッシュ値を生成するために使用されるハッシュ関数ではなく２次的な関数から得ることも可能である。
【００２３】
ハッシングは、ハッシングアルゴリズムと呼ばれる数学的関数を任意の量のデータに適用することにより固定サイズの結果を出力する暗号化プロセスでよく使用されるプロセスである。これらの実施形態で使用されるハッシュ関数は、当業者に知られている型である。標準的なハッシングアルゴリズムとしては、ＭＤ２、ＭＤ４、ＭＤ５、およびＳＨＡ−１がある。
【００２４】
これらの実施形態で使用されるハッシュ関数は、一方向暗号化ハッシュ関数として特徴付けることができる。当業者であれば理解するように、一方向ハッシュ関数は、通常、複数の一意的な特性を持つが、それは、任意長のメッセージ入力から固定長のハッシュ値または結果を計算するのは容易であり、固定長のハッシュ値が与えられた場合、任意長のメッセージを計算することは難しく、また任意長のメッセージ入力が与えられた場合、同じ固定長のハッシュ値を生成する他のメッセージを見つけることは困難であるからである。
【００２５】
区別されたｓａｌｔ値およびその他の文字列から出力される区別されたハッシュＨ３０１は、そのハッシュにより生成される数のＭＳＢ側の多数の０（または他の同等の定義済みビットパターン）から始まる。当業者であれば、他の同等の実施形態において、複数の０（またはその他の同等の定義済みビットパターン）をＬＳＢ桁またはその他の位置に配置できること、または説明されているハッシュまたは他の関数の順序特性をインジケータとして使用することが可能であることを理解するであろう。区別されたｓａｌｔ値および最終的な区別されたハッシュは、異なるｓａｌｔ値で評価される一方向ハッシュ関数の反復を通じて見つけられる。多数の先行０を伴うハッシュを生じるｓａｌｔ値は、区別されたハッシュとして保持される。一定の時間Ｔが経過するまで試行を繰り返す。当業者であれば、本発明の複数の実施形態では、攻撃者がＴの倍数の時間をかけて同じ個数の０を見つけ、４０ビットまたは４５ビットと照合しなければならないという想定の下で、ある固定時間「Ｔ」の間に０を見つけようとすることを理解するであろう。区別されたｓａｌｔ値を見つけるための探索プロセスの一実施形態は、以下のように書くことができる。
見つける０の個数を初期化する：Ｚ＝０
時間Ｔの間、以下を実行する：
新しいｓａｌｔ値Ｖを選択する
ＨＶ＝一方向ハッシュ（Ｋ，Ｘ，Ｖ）を計算する
ＨＶ内の先行０の個数、Ｙを計算する
（Ｙ＞Ｚ）ならば
Ｓ＝Ｖ，Ｈ＝ＨＶ，Ｚ＝Ｙ
指定された時間Ｔの終わりに、区別されたｓａｌｔ値Ｓおよび区別されたＨが見つかる。
【００２６】
区別されたハッシュＨは、暗号に関して強力な一方向関数を通じてＫ、Ｘ、およびＳのハッシュとして定義される。
区別されたハッシュ＝Ｈ＝Ｈ（Ｋ，Ｘ，Ｓ）
【００２７】
２進数である区別されたハッシュＨから論理コールサインが作成される。区別されたハッシュ３０１は、所定の個数のビット（「Ｍ」）からなる。Ｍは、区別されたハッシュの先行０（「Ｚ」）」３０２、および最後の先行０（または先行０のＬＳＢ）の直後にある区別されハッシュ値Ｈの予め選択された個数のビット（「Ｌ」）３０３を含む。
【００２８】
０の個数が決定された後、次のステップは、コールサインのコンテンツ内に含める区別されたハッシュＨからの残りのビットの個数を決定することである。（区別されたｓａｌｔ値を見つける際に使用される）パラメータＴおよびＬは、セキュリティおよびスケーリング考慮事項を考慮して選択される。上記のプロセスは、試行が実行される期間Ｔ、および選択されたビットの個数Ｌの２つのパラメータを持つ。これらのパラメータは、所定の数のエントリへのスケーリングを考慮し、ハッカーによるスプーフィング攻撃を難しくし、将来もセキュリティが保たれコールサインを将来にわたって使い続けられるようにすることにより、決定される。将来にわたって使い続けられるには、通常、ムーアの法則を考慮し、コンピュータの速度が向上してもコールサインの偽造不可能性が無効にならないようにすることである。これらのパラメータを選択する際にさらに考慮することは、ハッカーからの「カタログ」攻撃に抵抗することである。
【００２９】
（第１の実施形態における０の個数の符号化）
０の個数が判明した後、その個数をコールサインの中に符号化する方法も見つけなければならない。十分なセキュリティを備える短いコールサインを生成するために、短いデジタルまたは英数字文字列に符号化できるようにビットの総数を十分小さな値に抑える。符号化するビットの総数は、数Ｌと、０の個数Ｚを符号化するために必要なビットの数との総和である。通常、数Ｚは、１２８よりも小さく、７ビットで符号化することができる。
【００３０】
他の実施形態では、ヌルビットの実際の個数を符号化する代わりに、４ビットを使用するヌルオクテットの個数、または５ビットを使用するヌル「４ビットニブル」の個数を符号化することが可能である。十分な数のニブルを見つける修正されたプロセスは以下のとおりである。
【００３１】
見つける０の個数を初期化する：Ｚ＝０
時間Ｔの間、以下を実行する：
新しいｓａｌｔ値Ｖを選択する
ＨＶ＝一方向ハッシュ（Ｋ，Ｘ，Ｖ）を計算する
ＨＶ内の先行ニブルの個数、Ｙを計算する
（Ｙ＞Ｚ）ならば
Ｓ＝Ｖ，Ｈ＝ＨＶ，Ｚ＝Ｙ
例えば、２４個の先行０は、通常、１ＧＨｚのＣＰＵを搭載する従来のＰＣ上で、この方法により、１分未満で得ることができる。
【００３２】
以下に示されるように、コールサインを構成する先行０の後に続くビットのグループである、数Ｌは、４０ビット未満となることは滅多にないであろう。先行０の個数Ｚに対する実用的な範囲は、２４から８８までの間である。２４から８７までの間の値は、以下の公式を使用して符号化できる。
Ｚ＝２４＋Ｒ
【００３３】
この公式では、Ｒは、０から６３までの間で変化する数値である。これと同等のことであるが、以下の公式を使用することもできる。
Ｚ＝２４＋２＊Ｐ
【００３４】
Ｐは、０のペアの個数を符号化する０から３１までの範囲の数値である。０から３１までの間の数は、単一の英数字文字として符号化できるため、かなり実用的である。単一の英数字文字に符号化できる十分な個数の０を見つける修正されたプロセスは以下のとおりである。
【００３５】
見つける０のペアの個数を初期化する：Ｚ＝０
以下を繰り返す：
新しいｓａｌｔ値Ｖを選択する
ＨＶ＝一方向ハッシュ（Ｋ，Ｘ，Ｖ）を計算する
ＨＶ内の先行ペアの個数、Ｙを計算する
（Ｙ＞Ｚ）ならば
Ｓ＝Ｖ，Ｈ＝ＨＶ，Ｐ＝Ｚ
Ｚが２４よりも大きくなり、また時間Ｔが経過するまで
Ｚ＝Ｚ−１２を設定する
次のトレードオフは、値Ｌおよび時間Ｔの選択である。後でその選択について説明する。
【００３６】
カジュアルなやり取りに適しているコールサインは、０の個数Ｚの符号化およびＬ個の選択されたビットの符号化を含む、論理コールサインのデジタルまたは英数字符号化を使用することにより得られる。コールサインを構成するＺ＋Ｌビット３０４は、いくつかの５ビットセグメントに分割できる。それぞれの５ビットセグメントは、英数字文字により表される。英数字文字は、その後、コールサイン３０５に組み立てられる。そして、最後に、１つまたは複数のセパレータが追加され、最終的なコールサイン３０６が形成される。また、先行「Ｑ」を削除するなどのコールサイン短縮化規則を採用することもできる。
【００３７】
図４に、コールサインを決定するプロセスを示す。ステップ４０１で、区別された修飾子が構成される。ステップ４０２で、区別されたｓａｌｔ値が見つけられる。ステップ４０３で、区別されたｓａｌｔ（Ｓ）、パーソナライゼーション情報文字列（Ｘ）、および公開鍵（Ｋ）がＭ個のビットにハッシングされる。ステップ４０４で、ハッシュから先行０の個数が見つけられる。ステップ４０５で、ハッシュから先行０の個数（Ｚ）が取り出される。ステップ４０６で、ハッシュからビットの個数（Ｌ）が取り出され、コールサインに入れられる。そして最後に、ステップ４０７で、ＺおよびＬ個のビットの英数字表現を見つけてコールサインが形成される。
【００３８】
（コールサイン検証手順）
第三者がコールサインを受け取ると、コールサインの意図された所有者に、公開鍵Ｋ、パーソナライゼーション情報文字列Ｘ、および区別されたｓａｌｔＳの値の提示を要求することにより、コードサイン、公開鍵、およびパーソナライゼーション情報文字列の間の関連を検証する。第三者は、証明書を使用して、Ｋ、Ｘ、およびＳから区別されたハッシュを計算する。その後、先行０の個数がコールサインの中に表されている値Ｚと一致することを検証し、値Ｚが所定の最小値以上であることを検証し、コールサインの中に符号化されているＬ個のビットがハッシュ値の中の対応するビットと一致することを検証する。追加予防策として、ベリファイアは、パーソナライゼーション情報文字列Ｘが予想される自然な値に対応するかどうかを「目視」検査する。
【００３９】
すでに述べたように、パラメータＴおよびＬは、セキュリティおよびスケーリングを考慮したうえで選択される。上記のプロセスは、試行が実行される期間Ｔ、および選択されたビットの個数Ｌの２つのパラメータを持つ。これらのパラメータは、所定の個数のエントリに合わせてスケーリングする必要性、スプーフィングが簡単にできてしまうことのないようにする必要性、および将来にわたって使い続けられるようにする必要性、つまり、ムーアの法則に耐える必要性によって決まる。さらに考慮すべきなのは、「カタログ」攻撃に対する抵抗力である。
【００４０】
（起こり得るスプーフィング攻撃を考慮したＬおよびＴの選択）
公開鍵を短い署名にリンクするプロセスでは、攻撃者が同じ署名が得られる他の公開鍵を見つける、スプーフィング攻撃に注意しなければならない。
【００４１】
一般的な防御方法は、公開鍵を生成することの難しさに依存することである。署名が公開鍵とある種の固定されたテキストのハッシュであり、署名がＬビット長の場合、攻撃者は、一致するものを見つけるのに２＾Ｌ個の公開鍵を生成しなければならない。当業者であれば、公開鍵を生成する作業は、非常に費用のかかる演算である、２つの長い素数を見つける作業を伴うことを理解するであろう。しかし、標準の鍵生成ソフトウェアを使用して一致する鍵を見つけようとするのは無能な攻撃者だけであろう。その代わりに、攻撃者は、以下のようなプロセスを使用することもありえる。
第１の素数を取得する。
素数をリストに追加する。
以下を繰り返す：
新しい素数Ｐを取得する。
リストに含まれる各素数Ｑについて以下を繰り返す：
Ｎ＝Ｐ＊Ｑ（単純乗算）を計算する
Ｎに関連付けられている公開鍵Ｋを計算する
ハッシュ（Ｋ，パーソナライゼーション情報）を計算する
Ｉｆ（ハッシュがターゲットに一致する）
／／われわれの勝ち
ＲＥＴＵＲＮ（Ｐ，Ｑ）
ＥＮＤ ｉｆ
ＥＮＤ Ｆｏｒ
Ｉｆ リストのサイズ＜最大サイズ
Ｐをリストに追加する
Ｅｎｄ ｌｉｓｔ
Ｅｎｄ ｒｅｐｅａｔ
【００４２】
このプロセスでは、サイズＭの最大リストの場合、素数計算は平均してＭ回ループする毎に１回発生するだけである。大きなＭを選択することにより、攻撃者はコアループの実行時間に対する素数生成の影響を効果的に最小限に抑えるが、最後にはハッシュ関数のコストに支配されることになる。公開鍵生成の複雑度に依存することは、効率的な防御手段とはいえない。
【００４３】
Ｚ個の先行０を含むハッシュを見つけるために、ジェネレータは、約２＾（Ｚ）回の演算を実行しなければならず、したがって、対応するハッシュを見つけるために、攻撃者は約２＾（Ｚ＋Ｌ）回の演算を実行しなければならなくなる。ＺおよびＬの十分に大きな値を選択することにより、コールサインに対するスプーフィングが困難であることを保証し、しかも素数の生成に関して仮定を設けなくてよい。
【００４４】
他のよく知られている防御は、「Ｎのべき乗ハッシュ」と呼べるものを取得するために、ハッシュ関数のコストを、例えば、標準ハッシュを数回実行することを要求して高める方法である。暗号化の考慮事項とは無関係に、ハッシュ関数のコスト増大が対称的であることが欠点であり、コールサインの生成およびその検証の両方に適用される。これは望ましい特性ではない。スプーフィング攻撃を阻止するために生成に多量の計算を必要とする可能性のある、非対称なセットアップが望まれることもあるが、リーダーに過度の負荷をかけないために検証は非常に高速である。
【００４５】
コールサインプロセスでは、ジェネレータが、十分な数の先行０を見つけるため何回も試行を実行する必要がある。これは、長い生成時間を必要とする場合があるが、検証時間には影響を及ぼさず、単純ハッシュ比較よりもわずかに遅いだけである。
【００４６】
（将来にわたって使い続けられるようにすることとムーアの法則とを考慮したＬおよびＴの選択）
時が経つうちに計算能力が進化することも、通常は、ハッシングアルゴリズムの暗号強度の評価の際に考慮される。ムーアの法則によれば、与えられたコストに関して利用可能な計算能力は、ほぼ１年半毎に倍になり、３年毎に４倍になる。つまり、他はすべて同じであるとすると、攻撃者が利用できる計算能力の大きさは、１年半毎に倍になるということである。別の言い方をすると、現在１００万年かかる攻撃も、今から３０年後には１年以内で済むようになるということである。現在破ることが不可能なように見えるコードも、十分に難しくするか、「将来にわたって使い続けられるようにする」のでない限り、将来的にはいとも簡単に攻撃される可能性がある。
【００４７】
将来の攻撃からコールサインを保護するために、最初の０の個数を、ムーアの法則に従うように選択する。これを行うことにより、ムーアの法則はコールサインのセキュリティに役立つ。長いコールサインが生成されるようにコードのオーバーディメンショニング（ｏｖｅｒ−ｄｉｍｅｎｓｉｏｎｉｎｇ）を行う代わりに、ムーアの法則に従って最初の０の個数を選択する。現在使用されているコードが含む０の個数は比較的少ないかもしれないが、数年以内に使用されるコードが含む先行０の個数は増えていることだろう。
【００４８】
新しいマシン上で新しいコードが生成される場合、今から３年後に生成プロセスに同じだけの時間を費やして、０が２つ付加されたハッシュを見つける。当業者であれば、生成のコストは２＾（Ｚ）に比例し、攻撃のコストは２＾（Ｚ＋Ｌ）に比例することを理解するであろう。生成に固定された時間を費やすようにすると、攻撃者側は攻撃をかけるのにその時間の２＾Ｌ倍の時間を費やす必要がある。つまり、攻撃は、３０年後も現在と同じくらい難しいということである。例えば、生成期間Ｔが１分に設定され、長さＬが４０ビットに設定された場合、スプーフィングされた値の生成は、現行マシンでは、ほぼ２００万年分の計算を必要とし、今後３０年間同様に生成されるコールサインも、スプーフィングには類似のマシン上で２００万年分の計算を必要とする。
【００４９】
しかし、この議論が適用されるのは、コールサインが短い期間にしか使用されない場合のみである。２００３年に１分かけて生成された４０ビットのコールサインを破るには、２００３年に利用可能な複数のコンピュータを使って２００万年分の計算をするか、つまり１年間、そのような２００万台のコンピュータを並列使用する必要がある。２０３３年に１分かけて生成された４０ビットのコールサインを破る場合も、その年に利用できる複数のコンピュータを使用して２００万年分の計算をする必要がある。しかし、２０３３年の複数のコンピュータは、２００３年のコールサインをわずか２年以内に破ることができる。
【００５０】
そのため、コールサインには、何らかの形の陳腐化が生じる。ある特定の年に生成されたコールサインは、おそらく、かなりの年数の間、使用されないであろう。コールサインの全体的回復力は、生成に費やされた時間とビットの個数Ｌとに依存する。生成プロセスを長くとることで回復力を高められ、生成時間Ｔを倍にする毎に、ムーアの法則の繰り返しから保護される。さらに他の実施形態では、本当に強いサインは、生成プロセスを長時間にわたって実行することにより形成することができる。
【００５１】
さらに他の実施形態では、有効期限をコールサインに関連付けることにより妥当な保護が実現される。これは、相手の実際の公開鍵を見つけるために、コールサインがブートストラップメカニズムとして使用される場合に特に魅力的である。公開鍵が見つけられた後、コールサインの中に表されている圧縮情報ではなく、完全な情報を使用できる。完全な情報は、陳腐化に対する脆弱性がかなり低い。
【００５２】
（自然な衝突の可能性を考慮したＬおよびＴの選択）
攻撃がない場合でも、短いコードには問題があって、それは２人のユーザが同じコールサインになる鍵、パーソナライゼーション情報文字列、およびｓａｌｔ値の組合せをたまたま選択した場合に生じる「自然な」衝突の可能性である。
【００５３】
コールサインで使用されるビット長Ｌは、コールサインを短くしておくために制限されるが、コンピュータユーザの母集団（「Ｐ」）は非常に大きなものとなりうる。例えば、当業者に知られている方法を使用して衝突の確率が５０％未満となるようにＰ＝１０＾１０の母集団内のコンピュータユーザ毎に少なくとも１つのコールサインを割り当てると、長さＬは６７ビットを越えることになる。衝突の確率が１％未満でなければならないとすれば、Ｌは７３ビットよりも大きくなければならない。
【００５４】
このように大きなビット列は、１５英数字コールサインで符号化されるであろう。このような長さは、コールサインの実用的な長さを超えている。つまり、衝突の可能性を完全に排除することは、パーソナライゼーション情報文字列に電子メールアドレスなどの一意的なトークンが埋め込まれており、この一意的なトークンがコールサインと一緒に安全に転送された場合にしか実用的でない。
【００５５】
コールサイン長は制約されており、衝突が発生するので、衝突を検出する方法が採用される。衝突は、コールサインの解決を使って解決される。衝突がある場合、リーダーはコールサインに関連する公開鍵、パーソナライゼーション情報文字列、およびｓａｌｔ値の複数のバージョンを取得し、そのすべてが第１レベルの検証プロセスをパスする。リーダーは、パーソナライゼーション情報文字列に基づいて「正しい」または「予想される」バージョンを選択する。衝突解決プロセスは、以下のステップまたはその同等の手順を実行することにより繰り返すことができる。
１）コールサインの探索を開始する。
２）コールサインに関連する公開鍵、パーソナライゼーション情報文字列、およびｓａｌｔ値を取り出す。
３）そのような利用可能なエントリがない場合、探索は失敗として終了する。
４）一方向関数を使用して検証を実行する。失敗した場合には、ステップ２を繰り返す。
５）パーソナライゼーション情報文字列が予想される値と一致した場合、探索は成功し終了する。
６）パーソナライゼーション情報文字列が一致しない場合、ステップ２を繰り返す。
【００５６】
解決プロセスが効率的な場合、鍵は、衝突解決メカニズムと親和性のある衝突の頻度を維持できる十分な長さであればよい。例えば、パーソナライゼーション情報文字列の長いリストを延々と調べるのは不効率である。当業者であれば、衝突がかなりまれなことであり、２＾ＬがＰよりも十分に大きい、つまりＬ＞ｌｏｇ２ Ｐならば、２、３の一致するエントリを伴うだけであることを理解するであろう。
【００５７】
（ＬおよびＴを選択する際の定量化）
コールサインの第１の実施形態は、一組の英数字文字からなる。それぞれの文字は、５ビットの情報を符号化したものである。長さを考慮した場合については、コールサインの第１の実施形態は、長さ１０文字を超える英数字であってはならない。１０個の文字のうちの１つは、０の個数Ｚを符号化したものである。残り９文字は、Ｌビットを符号化したもので、１文字につき５ビットを使用した場合には、Ｌを４５ビットとする。Ｌ＝３５、４０、または４５ビットのコールサインの他の実施形態も可能である。第１の実施形態について、４５ビットのうちのＬに到達した際に、上記の基準は、当業者に知られている方法を使用して定量化されている。Ｌの値には、値のうちどれにアクセス可能かを知るための定量化可能な測定基準を割り当てることができ、同様に、０の探索に費やされなければならない時間Ｔも定量化されている。
【００５８】
前のセクションでは、スプーフィング攻撃、カタログ攻撃、自然な衝突、および年月のたつうちに高まる計算能力について述べたが、以下の基準で要約される。合計Ｚ＋Ｌは、スプーフィングを防止できるように十分大きくなければならない。０の個数Ｚは、計算時間Ｔに対応する。積Ｔ＊２＾Ｌは、数回のムーアの法則の繰り返しを考慮した場合であっても、スプーフィングを防止できるように十分大きくなければならない。パーソナライゼーション情報文字列は、カタログ攻撃を阻止できるように十分一意的なものでなければならない。長さＬは、ポータブルな母集団サイズを与えた場合に、名前衝突の発生がまれであるように十分に長くとらなければならない。
【００５９】
（スプーフィング攻撃を考慮したＬおよびＴの選択における定量化）
図５は、スプーフィング攻撃を無効化することに基づく長さＬおよび時間Ｔの選択を示す表である。この表は、サインを破るのに何年分の計算が必要になるかを、ビット数（３５、４０、または４５）および費やされる計算時間Ｔ（１５、６０、２４０、９６０、または３８４０秒）の関数として示している。この表では、二重下線および太字の値は、１００，０００年未満である。鍵を破るのに必要な計算は、コンピュータネットワークに容易に分散させることができる。当業者であれば、以前には１００，０００台のコンピュータで構成されるネットワークを使用すれば暗号チャレンジを破ることができたことを理解するだろう。コールサインをそのようなネットワークへの少なくとも１年のクラッキングに抵抗するようにするために、３５ビットのＬは、０の探索が少なくとも４分間持続しない限り最良の選択とはいえない。
【００６０】
１０，０００，０００年よりも大きな値は、一重下線付きの斜体であり、これらの値は、１００，０００台の現在のコンピュータのネットワーク上で１００年分の計算を必要とする。表からわかるように、４５ビットのＬであれば一般的には安全である。１６分以上の０に対する探索時間（Ｔ）と組み合わせて４５ビットのＬを使用すると、１０年間有効であり続ける可能性のあるコールサインが得られる。
【００６１】
（カタログ攻撃を考慮したＬおよびＴの選択における定量化）
図６は、Ｌビットから形成される様々なコールサインおよびＴ秒間に計算される区別されるｓａｌｔｓ値に対するコールサインの脆弱性を示す表である。コールサインのような短いコードは、スプーフィング攻撃の一変種である、「カタログ」攻撃を受ける可能性がある。この攻撃では、一人の攻撃者または複数の攻撃者のグループは、多数のコールサイン「ソリューション」を生成し、それらをデータベース、つまりカタログに格納する。それぞれのソリューションは、攻撃者に知られている公開鍵およびコールサインの特定の値をリンクする。当業者であれば、この表は、さらに、１００，０００台のコンピュータのネットワークにより１年で構築可能なカタログのサイズを示すことを理解するであろう。「脆弱性」の欄は、カタログが少なくとも１つの有効なコールサインを含むためにネットワーク内に存在していなければならないカタログ化された名前の出現回数を示す。
【００６２】
当業者であれば、カタログ攻撃は、ポピュラーなパーソナライゼーション情報文字列に対してのみ適用可能であることを理解するであろう。パーソナライゼーション情報文字列がユーザの名前と名字のみを含んでいた場合、カタログ攻撃はほとんど効力を持たないであろう。
【００６３】
他の実施形態では、パーソナライゼーション情報文字列に追加トークンを含めることにより、一般名の出現頻度を減らし、コールサインのセキュリティを強化することが可能である。例えば、市および国の名前をパーソナライゼーション情報文字列に追加することができる。すると、カタログ攻撃は、パーソナライゼーション情報の中に同じ追加トークンを持つユーザしかターゲットにできない。例えば、同じ名前と名字を持ち、同一市内に居住するユーザである。当業者であれば、これらのユーザは比較的小さな母集団を形成することを理解するであろう。当業者であれば、市内にそのようなユーザが数百人以上いることは滅多にないことを理解するであろう。この表から、４５ビットのビット長Ｌと４分（２４０秒）の持続時間Ｔとの組合せで、本出願において十分なセキュリティが確保されることがわかる。
【００６４】
さらに他の実施形態では、パーソナライゼーション情報文字列は、電子メールアドレスなどの一意的なトークンを含み、このトークンがコールサインの一部として安全に受け渡された場合、カタログ攻撃は無効化される。このようなカタログ攻撃を成功させるのは、スプーフィング攻撃と同じくらい難しい。
【００６５】
（不愉快な識別子の回避）
コールサインを生成するのは運任せなので、「ＩＡＭ−ＳＯ−ＤＵＭＢ」などの非常に望ましくないコールサインが生じる可能性がある。ランダムに選択されるため、禁句の４文字語など、明らかに不快感を与える単語を含むコールサインが生じることすらある。
【００６６】
これらの出現を排除する最も確実な方法は、提案されたコールサインをユーザに提示し、ユーザに、提案された値を受け入れてもらうか、または他の値を要求してもらうことである。計算を１６個の順次ステップとして設計すると、他のコールサインを素早く再生成しやすい。コールサインが拒絶された場合、他の実施形態では、完全に新規の計算に要する時間のわずか１／１６の時間を使用し、手順の本当に最後のステップを繰り返すことで十分である。コールサインが最終のハッシュステップにより導かれる設計が維持されている場合、さらに他の実施形態では、その段階で最終のｓａｌｔ値を導入し、乱数を単純に選んで新しいコールサインを導くようにすることが可能である。
【００６７】
さらに他の実施形態では、生成プロセスに「望ましくないキーワード」のリストを含めるステップを追加することにより望ましくないコールサインに対する保護を埋め込む。キーワードを含めるこのような保護は、コード自体をいくぶん不快なものとする。しかし、他の実施形態では、２進数値の英数字符号化が問題となる。そこで、実際のキーワードではなく、符号化された２進数値をプログラムに含めることができる。これらは、存在するが、読み取り不可能な形式である。
【００６８】
（ＩＩ．要求された０の個数が証明書により設定されるコールサインの第２の実施形態およびそれらを生成する方法）
第１の実施形態では、いくつか改善余地がある。コールサインの中の０の個数を符号化する必要がない場合があり、したがって、より短いコールサイン、または等しく長いが有効ビットの大きい方の数Ｌを含むコールサインを考慮する。また、英数字符号化とともに望ましくない結果が生じることがある。そのため、不注意で、不快な言葉を含む「読み取り可能な」文字列が生じる可能性がある。コールサイン生成プロセスにより、そのような単語が回避されるようにしなければならない。
【００６９】
（第２の実施形態における０の個数の符号化）
第１の実施形態の０の個数の符号化は妥協である。０の個数は、常に、２４よりも大きく、９８よりも小さく、また０の個数ではなくペアの個数を符号化することで十分な精度が得られると想定する。
【００７０】
より基本的なこととして、コールサイン内の０の個数の符号化では、コールサインの所有者は、必要な０の個数を決定しなければならないという点が挙げられる。第１の実施形態では、区別されたｓａｌｔを探すのに費やされる時間は固定されており、またその時間内に見つけられる０の個数は、「ムーアの法則に従い」、その年のコンピュータの平均能力を表すと仮定している。しかし、制限時間が固定されているため、コールサインを生成するために使用されるコンピュータの能力とそのコールサインの強度との間に依存関係が生じる。第２の実施形態では、０の必要な個数は、コールサインの受信者により決定されると仮定する。
【００７１】
この実施形態では、検証コード内にチェックを符号化する。コールサインの受信者は、公開鍵Ｋ、識別子Ｘ、および区別されたｓａｌｔＳを取得し、その後、ハッシュ内の０の個数Ｚが、年Ｙおよび有効ビットの個数Ｌの関数である、最小値よりも大きいことを検証する。
Ｚ＞Ｚ０−Ｌ＋（Ｙ−２００３）／Ｘ
【００７２】
この公式では、数Ｚ０は、２００３年に十分強度があると考えられた鍵の長さを表すように設定されている。係数Ｘは、平均的なコンピュータの能力が倍になるのに要する年数を示す。実用的な実装に関して、ムーアの法則に従ってＸの値を１．５に設定し、Ｚ０の値を６２に設定すると、以下の公式が得られる。
Ｚ＞６２−Ｌ＋（Ｙ−２００３）／１．５
【００７３】
この公式では、数６２は、１００，０００年分の計算が十分な障害となると仮定して計算された値である。実際、「バー」は、コールサインが使用される背景状況にかなり依存することがある。財務用途では、さらに大きな値、例えば、６６（１，０００，０００年）を必要とする場合がある。軍事用途だと、なおいっそう条件が厳しい。
【００７４】
図７に、第２の実施形態によるコールサインの構成を示す。コールサインは０の個数を符号化しないため、第１の実施形態と同じハッシュ関数を使用することはできない。コールサインを構成するＬ個のビットは、区別されたハッシュ内の固定位置に置かれるが、０は他の固定位置の後に数えられる。
【００７５】
（ＩＩＩ．コールサインのパッセージのＡＳＣＩＩへの英数字符号化）
図８および図９に、コールサインの英数字符号化を示す。コールサインを作成する際に、互いに区別しやすく、転記の誤りを生じがちでないコールサインの英字および／または数字を選ぶことが望ましい。ピア識別子には、英数字表現が割り当てられる。これらの実施形態で選択された符号化例では、結果として得られるコールサインの中で、数０および１または英字ＯおよびＩを使用しない。当業者であれば、これらの英字は、互いに混同しやすい傾向があるため使用されないが、他の実施形態ではそれらの文字を使用できることを理解するであろう。当業者であれば、さらに、他の実施形態では、他の文字を排除するか、または追加することができることも理解するであろう。当業者であれば、発明の他の実施形態は、実際には、ローマ字とアラビア数字に限定されないことを理解するであろう。当業者であれば、さらに、すべての数字またはすべての文字は、所望の数の記号が生成できる限り使用できることを理解するであろう。実施例では、不要な文字を削除することで、８個の数字と２４個の英字を残し、図に示されているように３２個の記号が得られる。
【００７６】
上述のように、コールサインを生成する際に、このプロセスでは、コールサイン内で使用するために選ばれたそれぞれの文字について０から３１までの数値を割り当てて、３２個の利用可能な記号を出力する。コンピュータによりコールサインが読み取られると、コールサインの各文字は、コンピュータメモリ内で数値を割り当てられる。コールサインがコンピュータから出力されるときに、コンピュータ内でコールサインを構成するそれぞれの数に対し、ユーザに出力されるコールサインを構成する数字または英字を割り当てる。コールサインを構成する文字の組合せは、コールサイン生成手順により選択される。その後、コールサイン検証手順によりその有効性がチェックされる。
【００７７】
（ＩＶ．ピア名解決プロトコル（ＰＮＲＰ）内で適用されるコールサイン）
図１０は、ピアツーピアコールサインの一実施形態を利用するピアツーピアネットワークのブロック図である。ピアツーピアネットワーク技術では、１つまたは複数の分散ネットワーク上でリアルタイム通信を実現する。ピアツーピアネットワーキングは、サーバレス技術である。ピアツーピアネットワークでは、個々のＰＣは、インターネットサービスを使用せずに、データの交換、資源の共有、他のユーザの特定、通信、および協働をリアルタイムで行うことができる。ＰＣは、通常、ＰＣがピアツーピアネットワークに結合されている場合にピアツーピア通信を可能にするアプリケーションソフトウェアを備える。この種のネットワークでは、ピアコンピュータはそれぞれ、独自のセキュリティの維持を受け持つ。そのため、認定ユーザの検証および衝突しているアドレスの解決は、サーバベースのネットワークといくぶん異なる方法で実行されるタスクである。
【００７８】
ピアグループに接続し、その後、ピアグループに参加することは、ユーザを識別する際にセキュリティ対策を利用するピアネットワークでの一般的なタスクである。グループに参加するには、ピアコンピュータは、ピアグループの所有者から招待を受ける。グループ所有者から招待を受け取るには、仮グループメンバがまず、ピア名および公開鍵である識別資料をグループ所有者に受け渡さなければならない。この情報は、電子メール、ファイル共有、ＸＭＬなどを使用して受け渡される。グループ所有者は、次に、招待を仮グループメンバに発行する。
【００７９】
仮グループメンバは、その情報を受け取ると、招待情報を使用して、グループに接続する。グループに接続するために、仮グループメンバは、ＰＮＲＰとグループＩＤを使用して、グループメンバのアドレスを解決し、そのグループメンバを通じてピアネットワークに接続する。
【００８０】
仮グループメンバと現在のグループメンバとの間の相互認証は、通常は、信頼できるＷｅｂを通じて実行される。相互認証の後、仮グループメンバが、単一の隣接者を持つ新しいグループメンバとなる。隣接者は、接続を受け入れ、認証が実行されたピアネットワークからのコンピュータである。
【００８１】
特に、ピアツーピアコンピュータネットワークへの接続に関して、ピアツーピアネットワークは、ネットワーキング用の一組のネットワーキングアプリケーションプログラムインターフェース（「ＡＰＩ」）を提供する、インフラストラクチャネットワーキングソフトウェアを含む。これらのピアツーピアアプリケーションは、協働通信、コンテンツ配信などに関係する場合がある。ピアツーピアインフラストラクチャＡＰＩソフトウェアは、ピア名解決プロトコル、マルチポイント通信、分散データ管理、セキュリティ保護されたピアＩＤ、およびセキュリティ保護されたピアツーピアグループなどのコンポーネントを含むことができる。
【００８２】
ピアツーピア名前解決プロトコル（ＰＮＲＰ）を使用すると、ピアツーピアネットワーク内のピアは、通常であればサーバベースのネットワーク内では必要になるようなサーバを必要とせずに、「ピア名」を解決することができる。ＰＮＲＰでは、ピアコンピュータは、ネットワーク内の他のコンピュータ、つまりピアを識別することができる。ピア名解決プロトコルは、複数のエンドポイント、または衝突の生じうるネットワーク内の複数のノードへの名前のピアツーピア解決を可能にするアプリケーションプログラムインターフェース（ＡＰＩ）を備える。
【００８３】
ピア名解決プロトコル（ＰＮＲＰ）ＡＰＩは、コンピュータノードがピアツーピアネットワーク内で互いに見つけ合うことができるようにすることにより参加ピアのグループが互いにやり取りできるようにする名前−ＩＰ解決プロトコルである。通常であればピアツーピアネットワーク内で提供されるタスクとしては、ピア名の登録および登録解除、ピア名の解決、およびピアのグループの列挙がある。当業者であれば理解するように、ピア名の解決は、互いに衝突しないピア名を見つけることを含む。互いに衝突しない名前を見つけることに加えて、見つかった名前は十分なセキュリティが対策され、ユーザがそのピア名を覚えられることが望ましい。
【００８４】
ピア名は、コンピュータ、ユーザ、グループ、またはサービスを識別できる安定した名前である。ピア名は、通常、ピアがセキュリティ保護されているかどうかを示す権限および単に文字列である分類子を含む。当業者であれば理解するように、セキュリティ保護されたピア名では、通常、セキュリティ保護されたハッシュアルゴリズム（ＳＨＡ−１）またはＭＤ５アルゴリズムを使用して、１２８ビットＰＮＲＰ識別子を導き、公開鍵Ｋを分類子Ｃにハッシングし、ピア名のセキュリティ保護された伝送を実現することができる。第３の実施形態では、Ｃは識別子Ｘ、ｓａｌｔ Ｓ、およびハッシングアルゴリズムの識別を含む。
【００８５】
暗号鍵は、ネットワーク通信内のセキュリティ対策のための当業者に知られている仕組みである。暗号鍵は、一般的に、アクセスの許可およびソースの識別の検証のためピアツーピア環境で使用される。暗号鍵を使用すると、鍵を所有している人は、その鍵が関連付けられているデータにアクセスしたり、または鍵所有者の電子署名を作成したりすることができる。公開鍵アルゴリズムは、通常、Ｋ／Ｐと表される、公開鍵と秘密鍵からなるペアを備える。秘密鍵は、メッセージの受信者への識別子として使用できるため、秘密に保ち、セキュリティ保護されなければならない。公開鍵は、自由に配布でき、他人がメッセージを自由に復号化できる。鍵ペアの公開鍵は、デジタル証明書とともに配布されることが多い。鍵ペアの一方の鍵がメッセージの暗号化に使用される場合、そのペアの他方の鍵は、メッセージの復号化に使用される。
【００８６】
これらの鍵は、長くなる傾向があり、通常は、少なくとも２５６個の１６進数である。そのため、それらを受け渡し、特に公開鍵を受け渡すのは、面倒な場合がある。インスタントメッセージングまたは電子メールは、使用できるが、改ざんを受けやすく、鍵の検証を望ましいものとする。また、鍵の検証のプロセスに、鍵を受け取る人が、送信者が鍵を送信する相手として意図している人であるかどうかの検証を含むことも望ましい。
【００８７】
（ＩＶ．ピアツーピア名前解決プロトコルに適用されるようなコールサインの第３の実施形態）
ピアツーピア名前解決プロトコル（「ＰＮＲＰ」）では、ピアはサービスを伴わずに「ピア名」を解決することができる。ＰＮＲＰピア名は、第１に、公開鍵のＳＨＡ−１ハッシュである「ａｕｔｈｏｒｉｔｙ」とＵｎｉｃｏｄｅテキスト文字列である「ｑｕａｌｉｆｉｅｒ」の２つのフィールドで構成される。ＰＮＲＰは、以下のような暗号ハッシング関数を使用して、これら２つのフィールドから１２８ビットＰＮＲＰ−ＩＤを導く。
ＰＮＲＰ−ＩＤ＝ｈａｓｈ（ａｕｔｈｏｒｉｔｙ，ｈａｓｈ（ｑｕａｌｉｆｉｅｒ））
【００８８】
この第３の実施形態は、ＰＮＲＰを「コールサイン」で強化する。ＰＮＲＰのコールサインを生成するために、ユーザは、「区別された修飾子」を生成する。権限、区別されたｓａｌｔ値、および区別された修飾子の組合せの結果として、多数の０から始まるＰＮＲＰ−ＩＤが得られる。コールサインは、このＰＮＲＰ−ＩＤから導かれる。新しいＰＮＲＰ ＡＰＩを使用することにより、ユーザは、コールサインに一致するＰＮＲＰエントリを列挙し、その後、関連付けられている権限および修飾子を取得することができる。
【００８９】
（区別されたＰＮＲＰ修飾子）
区別された修飾子は、区切り記号「／／」および「／」により区切った、パーソナライゼーション情報文字列、二次ハッシュ関数の識別子、および区別されたｓａｌｔ値から形成される。当業者であれば、パーソナライゼーション情報文字列の内容は、コールサインが使用されるアプリケーションによって異なることがあることを理解するであろう。例えば、ＰＮＲＰコールサインの実施例では一意的なパーソナライゼーション情報文字列を使用するが、他のアプリケーションでは、異なるパーソナライゼーション文字列を必要とする場合がある。
【００９０】
当業者であれば、これらの文字列は、区切り記号または当業者に知られているその他の同等の方法により区切られることを理解するであろう。当業者であれば、さらに、文字列の順序および使用される区切り記号は異なっていてもよいことも理解するであろう。
【００９１】
使用されるハッシュ関数は、さらに、区別された修飾子に含まれ、区切り記号により区切られる。当業者が理解するように、ハッシュ関数は当業者に知られている、十分なセキュリティ対策が施される型のものであればよい。例えば、ＳＨＡ−１ハッシュ関数またはその同等の関数がある。
【００９２】
ｓａｌｔは、コールサイン生成プロセス時に選択される。ｓａｌｔは、ピア名の二次ハッシュを実行することにより選択され、これにより、ハッシングされた結果は十分な数の０から始まる。ｓａｌｔ自体は、ＡＳＣＩＩ英数字からなる。正式な構文は以下のとおりである。
区別された修飾子＝＜パーソナライゼーション＞”／／”＜ハッシュ関数＞”／”＜ｓａｌｔ＞
区別された修飾子の例を以下に示す。
【００９３】
Qualifier:JonSmith<jsmith@yuhoo.com>//SHA1/A5E5F3Z4YWZTRF0TW9RTQ
ｓａｌｔは、権限および修飾子の二次ハッシュが多数の０から始まるように選択される。
【００９４】
（コールサインの第３の実施形態の生成）
コールサイン生成手順の目的は、ピア名および関連するコールサインが検証手順にパスできるようにする区別された修飾子を見つけることである。これは、適切な「区別されたｓａｌｔ」を見つけることを含むので、ピア名の二次ハッシュは、適切な数の０から始まる。
【００９５】
検証のセクションで示されているように、０の適切な個数は時間の経過とともに変わる。式
Ｚ＞１７＋（Ｙ−２００３）／１．５
は、それらの目的のために使用される。
【００９６】
生成目的に関して、値Ｙは、現在の年に設定すべきではなく、むしろ、コールサインが有効である期間の最終年に設定すべきである。既定では、これは、現在の年＋１０に設定される。
【００９７】
生成は、以下のように進行する。
１）検証手順において予想されるようにこの権限の正準形式を使用して、ＰＮＲＰに従って、ＰＮＲＰ名前権限の値を初期化する。
２）ユーザ名に応じてパーソナライゼーション情報Ｘの値を初期化する。
３）既定ＳＨＡ−１により、有効な二次ハッシュ関数を選択し、対応する識別子Ｉに注目する。
４）０の適切な個数Ｚを選択する。
５）数Ｎが数Ｚ以上になるまで以下を繰り返す：
ａ．Ｓａｌｔ Ｓを選ぶ。
ｂ．権限に基づくピア名および仮の区別された修飾子をＸ、Ｉ、およびＳに基づいて構成する。
ｃ．関数Ｉに従ってピア名のハッシュを計算する。
ｄ．このハッシュ内の０の個数（Ｎ）を測定する。
６）ピア名に関連付けられたＰＮＲＰ識別子を計算する。
７）ＰＮＲＰ識別子の最上位４５ビットに基づいてコールサインを構成する。
８）コールサインが不快な単語を含まないか検証し、もし含んでいれば、ステップ５を繰り返す。
【００９８】
ステップ５は、最新のコンピュータ上で約１５秒続くことが予想される。
【００９９】
生成関数の最後のステップは、コールサイン内の文字のランダムな集まりから何らかの不快な言葉が生じないかチェックすることを目的としている。これは、提案されたコールサインを使用することを受け入れるかどうかをユーザに問い合わせることにより実装できる。
【０１００】
（第３の実施形態で生成されるコールサインの検証）
コールサイン検証手順では、ピア識別子とコールサインとを比較し、二次ハッシュが十分な数Ｚの先行０を含むことを検証する。先行０の個数を検証することにより、コールサインに対する第三者によるスプーフィングが難しくなる。第１近似では、コールサインの暗号強度は、長さがＺ＋４５の対称鍵の強度に等しい。Ｚの値は、時間の経過とともに変化する場合がある。ムーアの法則から、コンピュータはますます強力になることが予測されるので、Ｚに対する長さ要件は増大する傾向にある。予見可能な将来にわたってムーアの法則が成立すると仮定した場合、先行０の個数Ｚに対する値は、現在の年Ｙの関数であると考えることができる。
Ｚ＞１７＋（Ｙ−２００３）／１．５
【０１０１】
当業者であれば、上の不等式の中で使用される値１７は、選択されたセキュリティと計算とのトレードオフの関係に対応し、また条件がきつい環境ほど、選択される値は大きくなる可能性があることを理解するであろう。
【０１０２】
コールサインを検証するために使用される二次ハッシュ関数は、時間の経過とともに変化しうる。現在の実装では、当業者に知られているハッシュ関数ＳＨＡ１が使用される。他の実施形態では、受け入れ可能なハッシュ関数のリストは、使用できるようにコンピュータメモリに保持することができる。特に、セキュリティが向上するようにハッシュ関数の開発が続けられることも予想される。本発明の実施形態は、新しいハッシュ関数が現れたときの将来の使用を規定することにより新しいハッシュ関数の開発に対応できる。
【０１０３】
検証は、以下のように進行する。
１）ピア名に関連付けられたＰＮＲＰ識別子を計算する。
２）ＰＮＲＰ識別子の最上位４５ビットとコールサイン内に符号化されている４５ビットとを比較する。
３）４５ビットが一致しない場合、検証は失敗である。
４）区別されたｓａｌｔから二次ハッシュ関数の識別子を抽出する。
５）ハッシュ関数識別子がない、または証明書が受け付けない、または有効な値として認識されない場合、検証は失敗である。
６）ピア名全体の正準化されたバージョンのハッシュを指定された二次ハッシュ関数とともに計算する。
７）その結果得られたハッシュ内の先行０の個数を測定する。０の個数がターゲット値Ｚよりも小さい場合、検証は失敗である。
８）識別文字列がコールサインにより指定された人またはエンティティの理にかなった説明となっていることを検証し、そうでなければ、検証は失敗である。
９）ステップ１から８がパスした場合、検証は成功である。
【０１０４】
ピア名の「正準化されたバージョン」を得るには、通常１６進数からなるピア名の権限部分が必ず数字と大文字Ａ、Ｂ、Ｃ、Ｄ、Ｅ、およびＦのみで符号化されているようにする。ステップ８は、通常、人間による対話操作を伴うことに注意されたい。
【０１０５】
（コールサインからのＰＮＲＰレコードの取り出し）
場合によっては、コールサインに関連付けられたＰＮＲＰレコード、したがって関連付けられたピア名を取り出すのが有益である。そうするには、ＰＮＲＰ識別子がコールサインと同じ４５ビットから始まるすべてのＰＮＲＰレコードを取り出し、対応するピア名を取り出し、検証手順のステップ１から７をパスできないピア名を取り除き、検証手順のステップ８を使用して、予想されるＩＤと一致する名前のみを残す。
【０１０６】
独占的権利または特権を主張する本発明の実施形態は、特許請求の範囲で定められる。
【図面の簡単な説明】
【０１０７】
【図１】ピアツーピアコンピュータネットワークにアクセスするために使用される標準的なセキュリティ保護されたユーザ識別を示す図である。
【図２】コールサインを発生する方法の第１の実施形態により生成される短縮されたコールサイン識別子の表現を示す図である。
【図３】コールサインの構成を示す図である。
【図４】コールサインを決定するプロセスを示す流れ図である。
【図５】Ｌビットから形成される様々なコールサインおよびＴ秒間に計算される区別されるｓａｌｔｓ値に対するコールサインの脆弱性を示す表である。
【図６】衝突頻度と４５ビットのビット長Ｌに対する集団の大きさとの対比を示す表である。
【図７】第２の実施形態によるコールサインの構成を示す図である。
【図８】コールサインの英数字符号化を示す図である。
【図９】コールサインの英数字符号化を示す図である。
【図１０】コールサインの第３の実施形態に使用されるようなコールサインを生成するプロセスを示す流れ図である。
【符号の説明】
【０１０８】
２０２ コールサイン識別子
【特許請求の範囲】
【請求項１】
区別された修飾子を決定するステップと、
区別されたｓａｌｔを見つけるステップと、
前記区別されたｓａｌｔを前記区別された修飾子とともにハッシングするステップと
を備えたことを特徴とするコールサインを生成する方法。
【請求項２】
前記ハッシュ結果が所定の出力パターンを含むようにする区別されたｓａｌｔを検出するステップをさらに備えたことを特徴とする請求項１に記載のコールサインを生成する方法。
【請求項３】
前記ハッシュから多数の先行０を検出するステップをさらに備えたことを特徴とする請求項２に記載のコールサインを生成する方法。
【請求項４】
前記複数の先行０の後に多数のビットを保持するステップをさらに備えたことを特徴とする請求項３に記載のコールサインを生成する方法。
【請求項５】
前記０の個数を英数字コールサインの０の桁に符号化するステップをさらに備えたことを特徴とする請求項４に記載のコールサインを生成する方法。
【請求項６】
前記複数の先行０に続くビットの前記個数を複数の英数字コールサイン桁に符号化するステップをさらに備えたことを特徴とする請求項５に記載のコールサインを生成する方法。
【請求項７】
前記コールサインの０の桁および前記複数の英数字コールサイン桁から１つのコールサインを形成するステップをさらに備えたことを特徴とする請求項６に記載のコールサインを生成する方法。
【請求項８】
暗号法でセキュリティ保護されているハッシング関数により生成された前記複数の先行０に続く複数の桁から２進数を作成するステップと、
前記２進数を複数の５ビットセグメントに分割するステップと、
前記５ビットセグメントのそれぞれを、対応する英数字に符号化するステップと
を備えたことを特徴とするコールサインを符号化する方法。
【請求項９】
前記２進数は、４５ビット長であることを特徴とする請求項８に記載のコールサインを符号化する方法。
【請求項１０】
前記英数字０文字は、ＭＳＢであることを特徴とする請求項８に記載のコールサインを符号化する方法。
【請求項１１】
パーソナライゼーション情報文字列を形成するステップと、
前記パーソナライゼーション文字列とともにハッシングされた場合に、前記ハッシングされた結果の中に所定の個数の先行０を生成するｓａｌｔ値を検出するステップとを備えたことを特徴とする暗号化ハッシュを生成する方法。
【請求項１２】
前記パーソナライゼーション情報文字列を区別されたハッシュを生成するための前記ｓａｌｔ値とともにハッシングするステップをさらに備えたことを特徴とする請求項１１に記載の暗号化ハッシュを生成する方法。
【請求項１３】
前記ｓａｌｔ値は区別されたｓａｌｔ値であることを特徴とする請求項１２に記載の暗号化ハッシュを生成する方法。
【請求項１４】
前記パーソナライゼーション情報文字列は、個人の名前を含むことを特徴とする請求項１１に記載の暗号化ハッシュを生成する方法。
【請求項１５】
前記パーソナライゼーション情報文字列は、個人の電子メールアドレスを含むことを特徴とする請求項１１に記載の暗号化ハッシュを生成する方法。
【請求項１６】
前記パーソナライゼーション情報文字列は、個人の会社名を含むことを特徴とする請求項１１に記載の暗号化ハッシュを生成する方法。
【請求項１７】
パーソナライゼーション情報文字列を形成するステップと、
前記パーソナライゼーション文字列および公開鍵とともにハッシングされた場合に、前記ハッシングされた結果の中に所定の出力パターンを生成するｓａｌｔ値を見つけるステップと
を備えたことを特徴とする暗号化ハッシュを生成する方法。
【請求項１８】
前記パーソナライゼーション情報文字列を区別されたハッシュを生成するための前記ｓａｌｔ値とともにハッシングするステップをさらに備えたことを特徴とする請求項１７に記載の暗号化ハッシュを生成する方法。
【請求項１９】
前記ｓａｌｔ値は区別されたｓａｌｔ値であることを特徴とする請求項１８に記載の暗号化ハッシュを生成する方法。
【請求項２０】
前記パーソナライゼーション情報文字列は、個人の名前を含むことを特徴とする請求項１７に記載の暗号化ハッシュを生成する方法。
【請求項２１】
前記パーソナライゼーション情報文字列は、個人の電子メールアドレスを含むことを特徴とする請求項１７に記載の暗号化ハッシュを生成する方法。
【請求項２２】
前記パーソナライゼーション情報文字列は、個人の会社名を含むことを特徴とする請求項１７に記載の暗号化ハッシュを生成する方法。
【請求項２３】
区別された修飾子をユーザ用に構成するステップと、
区別されたｓａｌｔを見つけるステップと、
前記区別された修飾子、区別されたｓａｌｔ、および公開鍵をＭビットハッシュにハッシングするステップと、
前記ハッシュ内の先行０の個数を決定するステップと、
前記ハッシュから所定の個数のビットを取り除くステップと、
テーブルルックアップを使用して前記０の個数を英数字コールサインの１桁に符号化するステップと
を備えたことを特徴とするコールサインを生成する方法。
【請求項１】
区別された修飾子を決定するステップと、
区別されたｓａｌｔを見つけるステップと、
前記区別されたｓａｌｔを前記区別された修飾子とともにハッシングするステップと
を備えたことを特徴とするコールサインを生成する方法。
【請求項２】
前記ハッシュ結果が所定の出力パターンを含むようにする区別されたｓａｌｔを検出するステップをさらに備えたことを特徴とする請求項１に記載のコールサインを生成する方法。
【請求項３】
前記ハッシュから多数の先行０を検出するステップをさらに備えたことを特徴とする請求項２に記載のコールサインを生成する方法。
【請求項４】
前記複数の先行０の後に多数のビットを保持するステップをさらに備えたことを特徴とする請求項３に記載のコールサインを生成する方法。
【請求項５】
前記０の個数を英数字コールサインの０の桁に符号化するステップをさらに備えたことを特徴とする請求項４に記載のコールサインを生成する方法。
【請求項６】
前記複数の先行０に続くビットの前記個数を複数の英数字コールサイン桁に符号化するステップをさらに備えたことを特徴とする請求項５に記載のコールサインを生成する方法。
【請求項７】
前記コールサインの０の桁および前記複数の英数字コールサイン桁から１つのコールサインを形成するステップをさらに備えたことを特徴とする請求項６に記載のコールサインを生成する方法。
【請求項８】
暗号法でセキュリティ保護されているハッシング関数により生成された前記複数の先行０に続く複数の桁から２進数を作成するステップと、
前記２進数を複数の５ビットセグメントに分割するステップと、
前記５ビットセグメントのそれぞれを、対応する英数字に符号化するステップと
を備えたことを特徴とするコールサインを符号化する方法。
【請求項９】
前記２進数は、４５ビット長であることを特徴とする請求項８に記載のコールサインを符号化する方法。
【請求項１０】
前記英数字０文字は、ＭＳＢであることを特徴とする請求項８に記載のコールサインを符号化する方法。
【請求項１１】
パーソナライゼーション情報文字列を形成するステップと、
前記パーソナライゼーション文字列とともにハッシングされた場合に、前記ハッシングされた結果の中に所定の個数の先行０を生成するｓａｌｔ値を検出するステップとを備えたことを特徴とする暗号化ハッシュを生成する方法。
【請求項１２】
前記パーソナライゼーション情報文字列を区別されたハッシュを生成するための前記ｓａｌｔ値とともにハッシングするステップをさらに備えたことを特徴とする請求項１１に記載の暗号化ハッシュを生成する方法。
【請求項１３】
前記ｓａｌｔ値は区別されたｓａｌｔ値であることを特徴とする請求項１２に記載の暗号化ハッシュを生成する方法。
【請求項１４】
前記パーソナライゼーション情報文字列は、個人の名前を含むことを特徴とする請求項１１に記載の暗号化ハッシュを生成する方法。
【請求項１５】
前記パーソナライゼーション情報文字列は、個人の電子メールアドレスを含むことを特徴とする請求項１１に記載の暗号化ハッシュを生成する方法。
【請求項１６】
前記パーソナライゼーション情報文字列は、個人の会社名を含むことを特徴とする請求項１１に記載の暗号化ハッシュを生成する方法。
【請求項１７】
パーソナライゼーション情報文字列を形成するステップと、
前記パーソナライゼーション文字列および公開鍵とともにハッシングされた場合に、前記ハッシングされた結果の中に所定の出力パターンを生成するｓａｌｔ値を見つけるステップと
を備えたことを特徴とする暗号化ハッシュを生成する方法。
【請求項１８】
前記パーソナライゼーション情報文字列を区別されたハッシュを生成するための前記ｓａｌｔ値とともにハッシングするステップをさらに備えたことを特徴とする請求項１７に記載の暗号化ハッシュを生成する方法。
【請求項１９】
前記ｓａｌｔ値は区別されたｓａｌｔ値であることを特徴とする請求項１８に記載の暗号化ハッシュを生成する方法。
【請求項２０】
前記パーソナライゼーション情報文字列は、個人の名前を含むことを特徴とする請求項１７に記載の暗号化ハッシュを生成する方法。
【請求項２１】
前記パーソナライゼーション情報文字列は、個人の電子メールアドレスを含むことを特徴とする請求項１７に記載の暗号化ハッシュを生成する方法。
【請求項２２】
前記パーソナライゼーション情報文字列は、個人の会社名を含むことを特徴とする請求項１７に記載の暗号化ハッシュを生成する方法。
【請求項２３】
区別された修飾子をユーザ用に構成するステップと、
区別されたｓａｌｔを見つけるステップと、
前記区別された修飾子、区別されたｓａｌｔ、および公開鍵をＭビットハッシュにハッシングするステップと、
前記ハッシュ内の先行０の個数を決定するステップと、
前記ハッシュから所定の個数のビットを取り除くステップと、
テーブルルックアップを使用して前記０の個数を英数字コールサインの１桁に符号化するステップと
を備えたことを特徴とするコールサインを生成する方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【公開番号】特開２００６−４８６５４（Ｐ２００６−４８６５４Ａ）
【公開日】平成１８年２月１６日（２００６．２．１６）
【国際特許分類】
【外国語出願】
【出願番号】特願２００５−１８４９９１（Ｐ２００５−１８４９９１）
【出願日】平成１７年６月２４日（２００５．６．２４）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
【公開日】平成１８年２月１６日（２００６．２．１６）
【国際特許分類】
【出願番号】特願２００５−１８４９９１（Ｐ２００５−１８４９９１）
【出願日】平成１７年６月２４日（２００５．６．２４）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
[ Back to top ]