JPH10285154A - 完全守秘性暗号系を構成する鍵生成システム、認証付き鍵共有プロトコル、“Ｏｎｅ−Ｔｉｍｅ Ｓｔｒｅａｍ Ｃｉｐｈｅｒ”、“Ｏｎｅ−Ｔｉｍｅ ｐａｓｓｗｏｒｅｄ”及び鍵管理アルゴリズム - Google Patents

Abstract

(57)【要約】 （修正有） 【課題】 オープンネットワークに情報理論的な安全性
“Unconditional Security”を与える。 【解決手段】 クライアント／サーバー・ネットワーク
等で通信を行う端末双方に、２ｕ（ｕ＞４）進数で演算
するレジスターを備え、レジスターの整数空間Ｉｓのそ
れ自身への写像（Ｉｓ→Ｉｓ）を実行して「整数の軌
道」を生成する写像アルゴリズム部、及び「整数の軌
道」を圧縮変換して２進の「鍵ストリーム」を生成する
圧縮変換部を備えた鍵生成システムにおいて、写像アル
ゴリズムを過去に遡る逆写像を試みると、ｎ回の逆写像
に対しては“ｎビットのEntropy”が生じだけでなく、
圧縮変換に伴う“Entropy”もそれに加わる「情報理論
的に安全な写像アルゴリズム」が実装され、暗号と復号
のアルゴリズムの中に「意図的に」埋め込む。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、従来のネットワー
ク・セキュリティーが計算量的安全性“Computational
Security”に依存していたのに対して、オープンネット
ワークに情報理論的な安全性“Unconditional Securit
y”を与える実装技術に関する。

【０００２】 情報理論的な安全な鍵生成システム 情報理論的な安全な認証技術 情報理論的な安全な鍵配送技術 情報理論的な安全な鍵保管技術 情報理論的な安全なメッセージの暗号技術 情報理論的な安全なデジタル署名技術 に亘る。

【０００３】

【従来の技術】インターネットにしろイントラネットに
しろ、そこで必要とされるセキュリティは、上述６つの
分野に亘る。これらセキュリティーを実現する暗号技術
には対称暗号方式と非対称暗号方式とがあり、現在この
二方式が合い補ったハイブリッド方式がネットワーク・
セキュリティーを達成したかに見えている。対称暗号方
式は、暗号鍵と復号鍵とが同じ対称鍵である。メッセー
ジの機密保持を確保するためには、この対称鍵を秘密に
しなければならないので、これを「秘密鍵」と呼んでい
る。

【０００４】歴史上ネットワーク上で、この秘密鍵をど
のようにして共有するかを解決したのが、Diffe-Hellma
nの鍵配送方式である。又、ここからＲＳＡも工夫さ
れ、非対称暗号そのものが確立したことはよく知られて
いる。

【０００５】現在、上述６つの技術分野は、のメッセ
ージの暗号に対称暗号を適用し、その他の分野は非対称
暗号の応用技術を適用するというハイブリッド方式によ
ってカバーされている。この内、の個人認証技術に関
しては、実用上もっと手軽な技術が普及しつつある。

【０００６】例えば、“challenge & Response”という
手法を適用して、クライアントがサーバーにアクセスす
ると、毎回サーバーは“challenge number”という平文
を送り出し、これを受け取ったクライアントは“passwo
rd”という暗号文をサーバーに返す。これがResponseで
ある。クライアントとサーバー双方にはＤＥＳなどの対
称暗号ソフトがあらかじめインストールされていること
は言うまでもない。

【０００７】毎回平文と暗号文とがネットワーク上に送
出されているので、このセキュリティーを破ることは国
家機関にとっては容易である。一方、民間ではこれで十
分のセキュリティーを達成しているようである。もっと
信頼の於ける認証技術としては、One-Time password（O
TP; RFCにてOTPと称されている）がある。難点は、使用
回数が限られているので、商取引には向かない。ＲＳＡ
が現在主流の認証技術である。しかし、これは計算量的
安全性に依存していることを忘れてはならない。

【０００８】

【発明が解決しようとする課題】従来知られている暗号
は“計算量的に安全である”と主張している技術であ
る；これは、「Computational Security」と言われてい
る。この種の技術が、現在オープンネットワークのスタ
ンダードになっている。例えば、DESやRSAが有名であ
る。

【０００９】それはルーチンワークの大好きなコンピュ
ータで破ろうとする限り、安全であることが保証されて
いる暗号である。しかし、RSAに関して言えば、将来素
数分布に関する新しい数学が生まれたらどうなるであろ
うか（リーマン予想）。整数の素因数分解を容易に行え
る様になるであろうし、その時、世界中を飛び回ってい
る電子マネーは、電子マネーでなくなる日となる。“計
算量的に安全である“とは、この様な意味での相対的安
全性であって、将来に亘って安全であるという意味では
ない。

【００１０】もう一つ困ったことは、従来の暗号技術は
国家の安全保証とリンクしていることである。従って、
これら暗号技術の民間ユースの転用に対して色々と制限
が入ってくるのは当然である。

【００１１】故に、オープンネットワークで使える新し
い暗号技術の出現が望まれる。この世界でスタンダード
になるセキュリティを実現できる暗号技術は、どんな条
件に耐えねばならないであろうか；その技術が全ての人
に公開され、評価され、誰でもそのソフトウェアが入手
可能になるという事態を、まず受入なければならない。

【００１２】かってのように一部の人達だけが技術を共
有し、つまり技術そのものを非公開の扱いにすることに
依ってセキュリティーを保つという秘密主義は、オープ
ンネットワークに通用しない。従って、単に暗号システ
ムを複雑にすることによっては、問題の解決にならない
ことが判る。

【００１３】Gilbert Vernumによって１９１７年に発表
されたというOne-Time Padは、単純にして、かつ“完全
守秘性”注¹を提供する最初の実用的な技術であること
が知られている。しかし、この技術は上述のスタンダー
ドに耐えうる条件を備えているにもかかわらず、オープ
ンネットワークに適用できない深刻な問題を内包してい
る。そのアポリアとは、「鍵の配送と鍵の管理」に関す
ることである；これは、鍵を配送するのに当該通信路以
外に、別に安全な通信路を必要とするというアポリアで
ある。

【００１４】従って、非公開の扱いを可能とし、鍵の配
送を特別な人が行う軍事、外交上の通信のみに使われて
いるということである。完全守秘性の概念は、この暗号
の実用化に後れて３０年後に、C.E.Shannon（注1）によ
って与えられたという。この意義は、今日オープンネッ
トワークの時代に特に大きい。何故なら、従来のオープ
ンネットワークに於ける暗号技術が「Computational Se
curity」という相対的 安全性に依存しているのに対し
て、「確率論的な答え」しか許さない暗号系の理論的な
存在とその安全性を提示したことである。判りやすく言
えば、その暗号技術を全て公開し、裏も表もなく公開
し、あらゆる技術進歩を計算に入れても、その暗号を
“破れる”のは、唯一確率論しか無いと言う暗号の安全
性を明らかにしたことである。このような暗号系は「情
報理論的に安全である」とか、「Unconditional Securi
ty」であると言われている。俗な言い方をすれば、ハッ
カーは、サイコロの目が２²⁵⁶もあるようなサイコロを
振る予想しか出せないし、コンピ ュータのプログラム
は暗号文を解析して平文を作ったとしても、あらゆる平
文が等確率に現れるから、やはりサイコロを振る結果に
なる。

【００１５】結論を言えば、オープンネットワークでス
タンダードになれるセキュリティー技術とは、こういう
“Unconditionally Secure”な暗号系に依存すべきであ
る。

【００１６】しかし、この種の安全な暗号系、例えば
“ One-Time Pad cipher”をネットワークへ適用しよう
とすると（注3）、「鍵の配送と鍵の管理」を他の暗号
系または他 の安全な通信路に依存しなければならない
という深刻な問題に出会うので、このアポリアをどのよ
うに始末するか、ここが新しい暗号理論とその実装手段
の試金石になるところであるし、本発明がブレイクスル
ーした点でもある。

【００１７】

【課題を解決するための手段】暗号技術の基本は鍵生成
システムにある、言い換えると、暗号技術の基本は乱数
生成のアルゴリズムに依存する。従来の乱数生成アルゴ
リズムは“Computationally Secure”であっても、決し
て“Unconditionally Secure”な乱数生成法ではない、
あるいは情報理論的な安全性の側面から研究された痕跡
がない。

【００１８】この“Unconditionally Secure”な乱数生
成理論の一つが、「カオス発生の原因であるフラクタル
構造そのもの」の中に発見された。カントール集合は
「情報理論的に安全な」なアルゴリズムであるという発
見である。単に、カオス的現象作り出してそれから乱数
列を取り出すという意味ではない。言い換えれば、コン
ピュータでカオス的乱数を作り、乱数列を生成したと言
う人が居ても、それが「情報理論的に安全な」乱数生成
手段であるという主張にはならないし、また情報理論的
に安全な乱数の利用をしているという主張にもならな
い。さらにカオス理論で作った乱数なら安全であると
か、逆に簡単な非線型関数を使っているから安全ではな
いなどの議論も、この“Unconditional Security”関す
る議論と全く関係ない。この点は特に強調しておかねば
ならない。

【００１９】１）カオス写像の情報理論的に安全な一方
向変換性；どのような非線形曲線を使うにしろ、カント
ール集合を成す数学上のカオス写像によって生成された
カオス軌道は（Chaos Orbit）、未来に向かっては一意
に決定される一方、過去に向かうと（ｎ回逆写像しよう
と試みると）２ⁿの不確定度を生じる（カントール集合
を逆にたどる）。このｎ回逆写像の“Entropy”を考え
てみよう。

【００２０】カオス軌道は互いに交わらない、つまり同
じ数学上の点を通らないという性質があるので、有限の
時間内で「カオス軌道上の点は全て等確率で出現する」
と言える。このカオス写像の性質を情報理論の視点で見
ると、「ｎ回逆写像のEntropyはｎビットである」こと
が判る（等確率で出現するから）。ここで注意すべき
は、数学上のカオス軌道と実装技術上のカオス軌道とは
一致しない；何故なら実装技術上のカオス軌道は有限精
度の整数の軌道であるから、単にカオス理論をプログラ
ムしてもカオスにならないのである。そこで話を数学上
のカオスに限るなら「過去のカオス軌道値は、現在の軌
道値よりｎビット余計な不確定度を帯びる、つまり、ｎ
ビットの情報量を担う」という情報理論的な構造を発見
する。（この情報理論的な構造は必ずしもカオス写像の
みに発見されるとは限らないが、カオス理論はすでに確
立しているので安心して使える。故に、以下カオス写像
を例にして“Unconditionally Secure”な鍵生成理論を
解説する。） この情報理論的な構造に著目すると、我々は任意の瞬間
のカオス軌道値そのものが「情報理論的に安全な秘密
鍵」として使えるというアイデアを発見する。何故なら
暗号を破るという行為は、“Recipient”側にある現在
のデーターから、「過去に遡って」“Originator”側の
原因を特定する作業であるから、ｎ回逆写像の“Entrop
y”がｎビットであるとは、「情報理論的に安全な鍵」
を提供するアルゴリズムになる。一方この秘密鍵は、そ
のカオス軌道を「未来に向かっては一意に決定する」か
ら「復号鍵： unique―decipherbility 」として機能さ
せる事も出来る。これは暗号学的には、真に出来すぎた
属性である。ここに改めて、我々は「復号鍵」として機
能するカオス軌道上の任意の瞬間のカオス軌道値を「情
報理論的に安全な拡張秘密鍵：Secret Key-Enhansed」
と名付けると共に、該拡張秘密鍵から見て、ｎビット余
計な不確定度を帯びている過去のカオス軌道値を「秘密
鍵」と定義する。これらのカオス軌道値を、アイデア上
の「カオス鍵」と言う場合がある。（詳細は図―２にて
説明する）。上記のように、数学上のカオス写像をC.E.
Shannon.の情報理論注１から再検討すると、カオス軌道
は「情報理論的に安全な一方向変換性を備えている」こ
とが判る。この情報理論的発見から、我々は完全守秘性
暗号系“Perfect SecrecyCryptosystem”に関する基礎
理論を確立した。このカオス写像自体に関しては、既に
思想として、１９９0年特願平２―２２６５００「無線
式電話の秘話システム及び秘話通信用LSI」の中で“秘
話ＯＳ”として提示し説明しているところである。

【００２１】今回、視点を.Shannoの研究に移し、カン
トール集合を成すアルゴリズムを情報理論的な安全性を
実現する基礎理論として採用した。

【００２２】実装技術上のカオス写像を「カオス的写
像」注²と表現する。単にカオス写像という時は数学上
の「情報理論的に安全な一方向変換性」を意味すると同
時に、そのカオス写像を有限精度のコンピュータに実装
する場合「カオス的写像」と表現する。従って、「カオ
ス的写像」とは、それが未来に向かう時その情報量は
“零ビット”であり、過去に向かう時は“ｎビット”の
情報量を必要とすることが「期待出来る」実装技術上の
アルゴリズムである。該実装技術上のアルゴリズムは必
ずしもカオス的写像であるとは限らないが、カオス的写
像アルゴリズムから生み出される鍵を「カオス的鍵；ch
aotic key」と言う場合がある。

【００２３】実施例で示すように、該実装技術では、カ
オス的写像の未来に向かうその情報量が“零ビット”で
あることを、暗号／復号を「正確に実行する」根拠と
し、認証を「代理鍵」によって「正確に実行する」根拠
とし、従って代理鍵を「共有する」根拠とし、また秘密
鍵を「一回しか使えない」ように「正確に同期して更新
する」根拠とする一方、またカオス的写像が過去に向か
うと“ｎビット”の情報を必要とする事を、「情報理論
的に安全な秘密鍵」を生み出す根拠にしている。これら
全てカオス的鍵の性質に依存する。

【００２４】“One-Time Pad Cipher”をネットワーク
へ適用する際に生じる深刻な鍵管理の問題は、全て情報
理論的に安全な秘密鍵の性質を適用して解決した。すな
わち、未来に向かう写像アルゴリズムは一意に拡張秘密
鍵を決めるという性質を適用して、ＴＣＰ／ＩＰなどの
一般的なプロトコル上に鍵生成システムを実装して「情
報理論的に安全な同期制御」を実施しブレイクスルーし
たものである。ここで、同期制御とは、 鍵ストリーム（keystream）が平文と独立に選ばれ
ることと、 クライアント・サーバー双方で実行されるカオス的
写像をプロトコルが同期して制御する、という二つの意
味を代表する。

【００２５】この通信プロトコル上の同期制御を「安全
な同期プロトコル：Secure Synchronous Protocol：Ｓ
ＳＰ」というが、これによって「認証付きの鍵共有： A
uthenticated Key Agreement」がオープン・ネットワー
ク上で可能になる。このユニークな鍵共有メカニズムに
よれば「鍵を交換するためには、別に安全な通信路を設
けなければならない」という“One-Time Pad Cipher”
に特有な鍵配送問題を解決できるのである。

【００２６】２）鍵生成システム；有限精度のパソコン
で鍵を等確率に作れるか；カントール集合を生み出す母
胎は「連続量」である。ロジスティック曲線のように単
純な曲線であるからという理由で、その鍵生成を軽く見
る暗号専門家も居るかも知れないが、それはカオス生成
の根底にある「連続量とフラクタルな構造」を見落とし
いるからである。逆に、このカントール集合を生み出す
構造に注意を払わないで、単にカオス写像をプログラム
したとしても、カオスを作れないことは明らかであろ
う；連続量とコンピュータの有限精度との差は、宇宙の
大きさととゴミを比較する以上の差がある。従って、有
限精度のパソコンで鍵を等確率に作れない。

【００２７】しかし、我々は従来のフラクタル構造にプ
ラスして、「加算個の無限を取り扱うフラクタルな演算
構造」（注2）をコンピュータの世界に導入することを
考案した 。

【００２８】このフラクタルな演算理論に基づくアルゴ
リズムは多数考えられるが、どのようなアルゴリズムに
しろ「鍵が等確率に出現する」根拠を持った工夫・考案
が無ければならない。（特願平８―１０８０５８「周期
性を考慮したカオス的乱数列の発生装置」及び特願平８
―１６９８６９「乱数生成装置及び乱数生成システム並
びに暗号通信方式」（注2）の乱数生成法は、“Computa
tionally Secureな長期周 期軌道”に関する一方、前特
願平８―３３８５８３「乱数列の発生方法」の乱数生成
法は、非周期軌道に関する。

【００２９】該アルゴリズムは、いずれもプログラム技
術としては多重演算アルゴリズムを利用しているが、そ
れが“Chaotic Orbit”を生成する理論上の根拠に依存
している。すなわち「加算個の無限を取り扱うフラクタ
ルな演算構造」を継承してそれに準じている）。

【００３０】我々は「鍵が等確率に出現する」ことを期
待できる他の工夫も歓迎する。以上要約すると、“Unco
nditionally Secure”な鍵生成手段とは、秘密鍵とワー
ク鍵とを生成する手段を備え、かつそれぞれ等確率に生
成すること、及びそのプロセスが情報理論的に安全な一
方向変換性を備えていることである。鍵が等確率に出現
する状況証拠には、“ keystream ”に自己相関が無
い、０／１ビットの偏りが無い（真正乱数）、演算レ
ジスターに“Lorentz plot”が現れる（実施例参照）な
どがある。これらは「Perfect Secrecy」を提供する上
で考慮されねばならない重要な要因である。

【００３１】次の４項でも触れる。 ３）鍵ストリーム；動的ワーク鍵；上記鍵生成システム
では、整数の軌道値を通常１０進数で表現する一方、実
際暗号に使うワーク鍵には、整数の軌道を圧縮変換した
２進のビット列を使う。

【００３２】秘密鍵を１０進表現で、動的ワーク鍵を２
進表現で使うと、この２進ビット列（子）からカオス的
軌道（親）を特定しようとしても、言い換えればカオス
的写像の内部情報を得たいと盗聴者が意図しても、圧縮
変換に伴う２２ｎ の不確定度と、カオス的写像を過去
に遡る２ⁱ の不確定度が、共に乗算で効いてくるので、
その情報を計算しても得られない、さらに情報理論的に
安全になる；その不確定度は「２²ⁿ ＊２ⁱ」である。

【００３３】このような情報理論的に安全なワーク鍵を
「動的ワーク鍵：Dynamic Work-key」または“secure ke
ystream”と参照する。

【００３４】当該鍵生成システムの秘密鍵のEntropyは
「２ｎ＋ｉビット」である。この不確定度は、丁度２
²ⁿ⁺ⁱ個の“目”を持ったサイコロを振るに等しい。一例
として、ｎ＝６４、ｉ＝１２８と仮定すると、そのサイ
コロの目は２²⁵⁶個ある。該秘密鍵を突き止めるのは、
この巨大なサイコロを振るに等しい。

【００３５】４）“One-Time Stream Cipher”；対称暗
号であるところのストリーム暗号に、上述の情報理論的
に安全な鍵生成システムを組み込んで、あらゆる階層の
鍵を一回使ったら捨てるとしたルール、つまりプロトコ
ルを導入する。この暗号系を仮に“One-Time Stream Ci
pher”と言うことにする。

【００３６】一般に、ストリーム暗号では、ワーク鍵を
平文と同じ長さのビットストリームとして生成すると共
に、このワーク鍵と平文とを排他的論理和（XOR）し暗
号文にする。

【００３７】今“One-Time Stream Cipher”の一つつの
端末に著目して鍵の解析をして見れば、どの秘密鍵も動
的ワーク鍵も、全ての鍵が一度使ったら捨てられる、
“One-Time Use”に限られているはずである。この時、
当該通信プロトコルに組み込まれている、上記鍵生成シ
ステムは、１）でも述べたように秘密鍵を全て等確率で
算出し、当該通信プロトコルもそれを等確率で使う（使
ったら捨てる）；とするなら、該暗号系は「Perfect S
ecrecy」を実現していることが期待出来る（注3）。

【００３８】実際、本発明の“One-Time Stream Ciphe
r”では、生成した秘密鍵を“One-Time use”に限る一
方、安定した通信も実現している。この安定した通信
は、１）項で紹介したように、端末双方が情報理論的に
安全な秘密鍵を用いて「安全な同期プロトコル：Secure
Synchro―Protocol」を共有し、秘密鍵を拡張秘密鍵で
更新するというダイナミズムを実現しているからであ
る。以上１）〜４）項は、「Perfect Secrecy 」を実現
する暗号系の基礎理論の概要である。

【００３９】本特願はこの実装技術に関する：その構成
は、

【表１】

【００４０】その実現手段は以下の通りである； １．クライアント／サーバー・ネットワーク（以下Ｃ／
Ｓネットワーク）などで通信を行う端末双方に、２ｕ
（ｕ＞４）進数で演算するレジスターを備え、該レジス
ターの整数空間Ｉｓのそれ自身への写像（Ｉｓ→Ｉｓ）
を実行して「整数の軌道」を生成する写像アルゴリズム
部と、該２ｕ進数の「整数の軌道」を圧縮変換して２進
の「鍵ストリーム」を生成する圧縮変換部、とを備えた
鍵生成システムを実装し、

【００４１】該鍵生成システムには、その写像アルゴリ
ズムを過去に遡る逆写像を試みると、ｎ回の逆写像に対
しては“ｎビットのEntropy”が生じだけでなく、上記
圧縮変換に伴う“ Entropy”もそれに加わる「情報理論
的に安全な写像アルゴリズム」が実装されており、該情
報理論的に安全な写像アルゴリズムを、「鍵の情報理論
的な安全性」を追求する目的で、暗号と復号のアルゴリ
ズムの中に「意図的に」埋め込んだ事を特徴とする情報
理論的に安全な対称暗号系。

【００４２】２．記対称暗号系は、該像アルゴリズムに
よる整数の軌道の任意の軌道値“ｃｋ0”を「秘密鍵」
として共有すると同時に、実際に暗号／復号するワーク
鍵には上記「鍵ストリーム」を使う一方、秘密鍵＜ｃｋ
0＞がどちらかの該鍵生成システムにインプットされる
と、該秘密鍵を情報理論的に安全な秘密鍵にするため
に、写像アルゴリズムを規定回数（ｉ回）実行させて、
該秘密鍵＜ｃｋ0＞のカオス的軌道（ｃｋ1、ｃｋ2、ｃ
ｋ3、、、、ｃｋｉ）を作らせると共に、該カオス的軌
道値を該端末内に「保存」するという規約と、

【００４３】さらに、この保存されているｉ番目のカオ
ス的軌道値＜ｃｋｉ＞すなわち「拡張秘密鍵」を初期値
とした新たなカオス的軌道（ｃｋｉ、ｃｋｉ+1、、、ｃ
ｋｉ+ｊ）を生成させて、この後者の整数軌道を圧縮変
換した「鍵ストリーム」をワーク鍵に使うという規約
と、これら二つの規約から構成される「安全な同期プロ
トコル：Secure Synchronous Protocol：ＳＳＰ」を実
装し、

【００４４】該「安全な同期プロトコル」を端末群が共
有する事により、対称暗号系の共通鍵の安全性が計算量
の安全性“Computational Security”ではなく、情報理
論的に安全性“Unconditional Security”の問題に帰着
させたことを特徴とする対称暗号系。

【００４５】３．秘密鍵＜ｃｋ0＞を共有している前記
１、２項記載の対称暗号系は、互いに相手を確認しうる
手段（ＩＤ）として共有している秘密鍵＜ｃｋ0＞を、
認証の手段としてネットワーク上で交換せず、保持する
と共に、対称暗号系のサーバー上で他の偶然的イベント
を初期値とした別の整数の軌道値を生成し、これを前記
1項の安全な同期プロトコル（S S P）の下でサーバーが
保持しいるクライアントの秘密鍵＜ｃｋ0.serv＞によっ
て暗号化し、該秘密鍵＜ｃｋ0.serv＞の「代理の鍵＜ｓ
ｋｉ.serv＞」として、他方のクライアントに配送する
一方、

【００４６】この暗号データを受け取ったクライアント
も、該クライアントが保持していた秘密鍵＜ｃｋ0.clin
＞により同じく“SSP”の下で該暗号データを復号化し
て「代理鍵」＜ｓｋｉ.clin＞を受け取るという規約
「鍵の同期配送プロトコル」を実装し、

【００４７】さらに、サーバーは代理鍵＜ｓｋｎ.serv
＞を初期値としたカオス的軌道を生成して該拡張代理鍵
群を保持し；

【００４８】

【数５】｛ ｓｋ（ｎ＋１）.serv、ｓｋ（ｎ＋２）.ser
v、ｓｋ（ｎ＋３）.serv、、、｝、

【００４９】一方クライアントも代理鍵＜ｓｋｎ.clin
＞について、それを初期値とした整数の軌道を生成して
該拡張代理鍵群を保持し；

【００５０】

【数６】｛ｓｋ（ｎ＋１）.clin、ｓｋ（ｎ＋２）.cli
n、ｓｋ（ｎ＋３）.clin、、、｝、

【００５１】これら拡張代理鍵群をそれぞれ前記鍵生成
システムの圧縮変換部に入力し、それぞれ対応する拡張
ワーク鍵系列を生成し、かつ保持し；

【００５２】

【数７】｛、、ｗｋ１.serv、ｗｋ２.serv、ｗｋ３.ser
v、、、｝ ｛、、ｗｋ１.clin、ｗｋ２.clin、 ｗｋ３.cli
n、、、｝

【００５３】これら情報理論的に安全な拡張ワーク鍵群
をネットワークへ出して交換する規約「鍵の同期認証プ
ロトコル」を実装し；すなわち、 （１）クライアントからサーバーへ最も新しい「拡張ワ
ーク鍵」＜ ｗｋ３.clin＞を配送する。

【００５４】（２）サーバー上では下記の比較をする。

【００５５】クライアントのワーク鍵＜ｗｋ３.clin
＞：サーバー上のワーク鍵＜ｗｋ３.serv＞ （３）一方サーバからもクライアントへ比較的に新しい
「拡張ワーク鍵」を配送する。この鍵には＜ｗｋ１.ser
v＞又は＜ｗｋ２.serv＞どちらを使ってもよい。 （４）クライアント上では（３）項の鍵を使って下記の
比較をする。

【００５６】サーバーのワーク鍵＜ｗｋ１.serv＞：ク
ライアント上のワーク鍵＜ｗｋ１.clin＞ （５）一致を見なかった場合は、該端末の方のイニシャ
テイブで通信を切断する。

【００５７】（６）一致を見た場合、

【００５８】

【数８】 対応する拡張ワーク鍵の一致 ： ＜ｗｋ３.serv＞ ＝ ＜ｗｋ３.clin＞ ＝ ＜ｓｋn.serv＞ ＝ ＜ｓｋｎ.clin＞：代理鍵を共有し ＝ ＜ｃｋｉ.serv＞ ＝ ＜ｃｋi.clin＞ ：拡張秘密鍵を共有し ＝ ＜ｃｋ0.serv＞ ＝ ＜ｃｋ0.clin＞ ：秘密鍵を共有し ＝ 認証完了

【００５９】 などが成立する「鍵の同期認証プロトコル」を備え、 同時に ＝ ＜ｓｋｎ＞；を共有する、 すなわち、 ＝ 代理鍵の情報理論的に安全な配送を完了する とした「鍵の同期配送プロトコル」を実装し、該「鍵の
同期配送プロトコル」と「鍵の同期認証プロトコル」の
両者から構成される「認証付きの鍵共有プロトコル：Au
thenticated Key Agreement Protocol」を実装する事を
特徴として秘密鍵の共有を実現する前記１、２項記載の
対称暗号系。

【００６０】４．対称暗号系の端末双方が“login ”
後、前2項記載の安全な同期プロトコル（ＳＳＰ）の下
で前３項記載の「認証付き鍵共有」を成した後に於いて
は、当該対称暗号系の中の鍵群は、

【００６１】

【数９】 拡張ワーク鍵の一致 ＝ 拡張秘密鍵を共有し ＝ ＜ｃｋｉ.serv＞ ＝ ＜ｃｋi.clin＞；ｉ＝1~任意 ＝ ＜ｃｋ0.serv＞ ＝ ＜ｃｋ0.clin＞； ＝ ＜ｃｋ0＞；秘密鍵を共有する、

【００６２】を無条件に満足する鍵群となるので、“lo
gin”が発生する度に、端末双方とも一回使用した秘密
鍵を、該鍵群の中の未使用の任意の拡張秘密鍵もって
「更新する」ことを特徴とした対称暗号系又は、前記
１,２,３項記載の構成要件を満たす“One-Time Stream
Cipher”同じく前記１,２,３項記載の構成要件を満たす
ことを特徴とした“One-Time Password”。

【００６３】５．多数のクライアントの秘密鍵のファイ
ル「鍵箱」を備えたサーバーが、その鍵箱を情報理論的
に安全なセキュリテイで守るために、前2項記載の安全
な同期プロトコル（ＳＳＰ）の下で前3項の「認証付き
鍵共有」を成した後に於いて、該鍵サーバーは、「鍵
箱」の任意の秘密鍵＜ｃｋ0＞を前2項記載の当該秘密鍵
＜ｃｋ0＞の「鍵ストリーム」＜ｗｋ-ｃｋ0＞によって
該鍵＜ｃｋ0＞自身を暗号化し、

【００６４】該「鍵箱」を暗号ファイルCRYPTO（ｃｋ
ｎ：ｎ＝0,1,2,3,,）として管理する一方、前記１乃至4
項記載の対称暗号系がこれを復号化するには、該クライ
アントが保持している鍵＜ｃｋ0.clin＞から生成した上
記鍵ストリーム＜ｗｋ-ｃｋ0.clin＞しか復号化の手段
が残されていないので、前記１乃至4項記載の対称暗号
系は次の“login”時に、該クライアントの該鍵ストリ
ームをサーバーに配送し、該サーバー上で暗号ファイル
CRYPTO（ｃｋｎ：ｎ＝0 ）を復号化し、当該クライア
ントの秘密鍵＜ｃｋ0.serv＞をサーバーへ与えるとした
「鍵管理プロトコル」を実装する一方、該対称暗号系
は、該サーバーが該秘密鍵＜ｃｋ0.serv＞を入手した後
には、前3項記載の規約「認証付き鍵共有プロトコル」
の実行に入ることを特徴とした鍵管理アルゴリズム及び
鍵サーバー。

【００６５】６．前記１項記載の鍵生成システムのレジ
スターは、１０ⁿ （ｎ＞＝１）個または２ⁿ個（ｎ＞
１）の桁から成立する一様レジスターであり、その一桁
も又１０^m個または２^m個の桁から成立する（１０ⁿ ＜＝
１０^m ）一様レジスターであり、というように「入れ籠
構造」を成した「自己相似形レジスター」であることを
特徴とする一方、該鍵生成システムの写像アルゴリズム
は、該一様レジスターを１０ⁿ 進数または２ⁿ進数の整
数空間Ｉｓと見なす該整数空間のそれ自身への写像Ｆで
ある；（Ｆ：Ｉｓ→Ｉｓ）。

【００６６】注１）C.E.Shannon.“Comunication theor
y of secrecy systems”Bell Systems Technical Journ
al,28(1949), 656-715. 注２）特願平８―１０８０５８ 「周期性を考慮したカオス的乱数列の発生装置」及び 特願平８―１６９８６９ 「乱数生成装置及び乱数生成システム並びに暗号通信方
式」 ［１８］／／／［００２４］ 特願平８―３３８５８３「乱数列の発生方法」 注３）Douglas R. Stinson “CRYPTOGRAPHY：Theory an
d Practice”Theorem 2.4 注４） 山口昌哉「カオスとフラクタル」ブルーバック
ス

【００６７】

【発明の実施の形態】請求項１，２，３、４、５、６記
載の対称暗号系は、完全守秘性の実現“Perfect Secrec
y Cryptosystem”を意図した。該暗号系を「使い捨て
のストリーム暗号システム：One-Time Stream Cipher」
としてインターネットへテスト実装した。その実施の形
態を述べる。

【００６８】Ｉ、完全守秘性をオープン・ネットワーク
へ実装する立場から、まず一般的なストリーム暗号シス
テムついて再検討する。

【００６９】図−１にて、ストリーム暗号システムは、
平文Ｘをビットストリ―ムであるワーク鍵によって暗号
文Ｙに変換する：関数関係式で表すと、

【００７０】

【数１０】 平文Ｘのビットストリ―ム長＝暗号文Ｙのビットストリ―ム長、 ＝ワーク鍵ｗｋのビットストリ―ム長、 Bit-length（Ｘ）＝ Bit-length（Ｙ）＝ Bit-length（ｗｋ） Eq．1 暗号文Ｙ ＝ XOR（平文Ｘ＋ワーク鍵ｗｋ） Eq．2 これを元の平文に戻すには、同じワーク鍵ｗｋを使っ
て、

【００７１】

【数１１】 平文Ｘ ＝ XOR（ 暗号文Ｙ＋ワーク鍵ｗｋ ） Eq．3

【００７２】ここで注目しなければならない事は、関数
関係式Eq．１＆Eq．２にワーク鍵ｗｋが入っているので
Eq．３の復号が成立するという自明な関係である。情報
理論の視点から見ると、一般的に平文Ｘと暗号文Ｙとは
互いに「独立な事象ではない」という関係である。これ
は、そもそも暗号・復号を成立させる自明な、そして必
須な関係であることを記憶しておかなければならない。
これは対称暗号系の欠点を意味する一方、そもそも暗号
系の安全性を計算量の安全性に持ち込まなければならな
かった理由でもある。

【００７３】一方、情報理論的な安全性を追求するとこ
ろの完全守秘性とは「暗号文Ｙが与えられた時に平文Ｘ
を推定する確率と平文Ｘそのものが生じるアプリオリ確
率とは等しい」時の安全性を述べた理論である。この安
全性とは、暗号文Ｙが与えられた時に平文Ｘを推定する
のは丁度、サイコロの目が“星の数ほど有る”ようなサ
イコロを振って、そしてそのサイコロは誰でも手に入れ
ようとすれば入るものであるが、次にどの“目”が出る
か誰も予想する者が居ないということを述べているのと
同じである。

【００７４】この完全守秘性は、次のEq．4とEq．５が
同値であることを主張し、その確率等式は「平文Ｘと暗
号文Ｙとが独立変数である」時に成立する：

【００７５】

【数１２】 Prob．P（平文Ｘ｜暗号文Ｙ）＝ Prob．P（平文Ｘ） Eq．4 Prob．C（暗号文Ｙ｜平文Ｘ）＝ Prob．C（暗号文Ｙ） Eq．5

【００７６】従って、上記条件「平文Ｘと暗号文Ｙとが
独立変数である」とは、一般的な関数関係式Eq.１｜２
｜３そのものを否定するような主張である。

【００７７】しかし、この時、ワーク鍵が平文Ｘと独立
に選ばれ、かつワーク鍵の情報理論的な性質が「どのよ
うな平文Ｘ、どのような暗号文Ｙに対してもEq．2を成
立させる鍵が唯一存在し、同時に全ての鍵が等確率に使
われるならば、該平文Ｘと暗号文Ｙとは完全守秘性の主
張、Eq．4＆Eq．5を満たす」ということが証明されてい
る：詳細な条件に関しては、注１＆注３に譲る。

【００７８】この定理が、どのようにして一般的なスト
リーム暗号システム（Eq．1からEq．3）に実装された
か、以下順に述べるところである。

【００７９】II．まず最初に、当該ストリーム暗号シス
テムの構成要件を図―１に示す；図中に於て、クライア
ント／サーバー・ネットワーク（以下Ｃ／Ｓネットワー
ク）などで通信を行う端末双方に、２ｕ（ｕ＞４）進数
で演算するレジスターを備え、該レジスターの整数空間
Ｉｓのそれ自身への写像（Ｉｓ→Ｉｓ）を実行して整数
の軌道を生成する写像アルゴリズムと、２ｕ進数の該カ
オス的軌道を圧縮変換して２進ビット列の「鍵ストリー
ム」を生成する圧縮変換部とを備えた鍵生成システムを
実装する一方、該端末双方は、該整数の軌道系列の任意
の軌道値＜ｃｋ0＞を「秘密鍵」として共有すると同時
に、該秘密鍵を初期値として生成した整数の軌道をさら
に圧縮変換したところの上記２進ビット列を平文／暗号
文と等量作り＜ワーク鍵＞として使う。図中、秘密鍵＜
ｃｋ0＞が共有されているので、該秘密鍵から作られた
ワーク鍵wkも正確に等しい（ The Entropy ＝“0”Bit
に示される）。これ等がストリーム暗号システムを構成
する（前々特願請求項２、３、に相当する)(注2)。該ス
トリーム暗号システムを構成する枠組みの中で、秘密鍵
を情報理論的に安全な拡張秘密鍵“ Secret Key―Enhan
sed ”にするプロトコルを図―２に示す。

【００８０】該ストリーム暗号システムは、共有してい
る秘密鍵＜ｃｋ0＞を直接使わないで上記鍵生成システ
ムにインプットし、該秘密鍵＜ｃｋ0＞を初期値として
写像アルゴリズムを規定回数（ｉ回）実行させて、該秘
密鍵＜ｃｋ0＞のカオス的軌道（ｃｋ1、ｃｋ2、ｃｋ
3、、、ｃｋｉ）を作らせる。この軌道を該暗号システ
ム内に「保存」した後、このｉ番目のカオス的軌道値＜
ｃｋｉ＞を初期値とした写像アルゴリズムを、さらに
（ｊ回）実行させ、新たなカオス的軌道（ｃｋｉ、ｃｋ
ｉ+1、、、ｃｋｉ+ｊ）を生成し、当該平文又は暗号文
と等量のワーク鍵wkを生成する（ｊの値は平文／暗号文
と等量になるように決める）。図―２中、秘密鍵＜ｃｋ
ｉ＞から見て、ワーク鍵wkに至るエントロピーは正確に
“0”ビットであり、一方、秘密鍵＜ｃｋ0＞に至るエン
トロピーは正確に“ｉ”ビットである。故に、秘密鍵＜
ｃｋ0＞から見て、該秘密鍵＜ｃｋｉ＞を「拡張秘密
鍵」と呼ぶ一方、該ワーク鍵wkから見ると該秘密鍵＜ｃ
ｋ0＞に至るエントロピーはさらに増加し、正確に“ｉ
＋ｊ”ビットとなる。これで、より安全なワーク鍵とな
るので、該ワーク鍵wkを「動的ワーク鍵：Dynamic wk
（Ｃｋｉ＋ｊ）」または“secure keystream”として参
照する。これら鍵を総称して、カオス的鍵“chaotic k
eys”として参照する場合がある一方、その生成システ
ムを図―３に示す。

【００８１】該図―３／Ｓ７は、次のEq．６に対応す
る；

【００８２】

【数１３】 拡張秘密鍵 ＝ Ｆｉ（秘密鍵） ＜ｃｋｉ＞ ＝ Ｆｉ（＜ｃｋ0＞） Eq．６

【００８３】Ｆｉ ：該写像アルゴリズムは、レジスタ
ーが作る整数空間（Ｉｓ）内の全ての鍵ｃｋ1、ｃｋ2、
ｃｋ3、、、ｃｋｉ、、、 ｃｋｎを等確率で生成するだ
けでなく、該動的ワーク鍵（ビットストリーム）に偏り
が無い（0.01％以下）及び該動的ワーク鍵に自己相関が
ない（0.01％以下）という属性を提供できる非線形関数
でなければならない。“ｉ”は重要なコントロール・パ
ラメータである。

【００８４】該図―３／Ｓ２／Ｓ２／Ｓ５／Ｓ６は、次
のEq．７に対応する；

【００８５】

【数１４】 Dynamic wk（Ｃｋｉ＋ｊ）＝ One-way Compr．Ｆｉ＋ｊ（＜ｃｋ0＞） Eq ．７ One-way Compr：２ｕ進数から２進への一方向圧縮変換

【００８６】該動的ワーク鍵wk（Ｃｋｉ＋ｊ）は、ネッ
トワーク上を移動したり、公開されるような使い方をさ
れる場合も有る、従って盗聴される場合もあるが、該秘
密鍵＜ｃｋ0＞の安全性は「情報理論的に安全であ
る」。ｉ＝１２８として実装すると、該エントロピーは
“１２８＋ｊ”ビットである。この不確定度は、サイコ
ロの目が“２¹²⁸ 以上”も有るサイコロを振るのと同じ
である。

【００８７】該図―１／図―２／図―３に示される構成
要件の中で、対称暗号系の秘密鍵を拘束するEq．６ E
q．７に示された規約を「安全な同期プロトコル：Secur
e Synchro―Protocol」として参照する。該安全な同期
プロトコルを実装した対称暗号系では、その共通鍵の安
全性が従来の計算量の安全性の問題“Computational Se
curity”にならず、情報理論的に安全な又は確率論的に
安全な問題“Unconditional Security”に帰着する。そ
の理由を要約すれば、

【００８８】 該安全な同期プロトコル“ Secure Sy
nchro―Protocol：ＳＳＰ ”という実装技術が、端末群
に共有され、 端末双方のカオス的鍵“chaotic keys”を制御し、 その秘密鍵＜ｃｋ0＞を情報理論的に安全な拡張秘
密鍵＜ｃｋｉ＞に変換し、これから動的ワーク鍵 wk
（Ｃｋｉ＋ｊ）“secure keystream”を生成する、から
である。

【００８９】III.この安全な同期プロトコル（ＳＳＰ）
をパラダイムにして、秘密鍵をどのようにして“One-Ti
me”にするかという本題に入ることになるが、その前提
として、鍵をどのようにしてネットワーク上を配送する
か、そのためにはクライアント／サーバー双方の認証を
どのように実施するか、を示さねばならない。「代理鍵
の安全同期配送プロトコルおよび代理鍵による安全同期
認証プロトコル」図―４と「初期認証シーケンス／Pass
net更新シーケンス」図―６はその仕組みを示す。ＳＳ
Ｐのパラダイムでは、認証と鍵配送とが同時進行し、内
容は同じであるが違った目的に到達するという特徴があ
る。

【００９０】その構成要件は図―２に示すように、秘密
鍵＜ｃｋ0＞を共有している請求項１、２記載のストリ
ーム暗号システムは、Ｃ／Ｓとも共有している秘密鍵＜
ｃｋ0＞を、互いに相手を確認しうる手段であるＩＤ＝
秘密鍵をネットワーク上で交換する事をせず、両者とも
「保持する」。

【００９１】その代わり、図―４、図―５に示すよう
に、該ストリーム暗号システムはサーバー上で他の偶然
的イベントをトリガーとした初期値から別のカオス的軌
道値＜ｓｋｎ.serv＞を生成し、これをサーバーが保持
している秘密鍵＜ｃｋ0.serv＞の「代理鍵」として、前
記２項の安全な同期プロトコルと該秘密鍵＜ｃｋ0.serv
＞によって暗号化し、クライアントに配送する。この偶
然的イベントの発生は、いままで知られているどのよう
な手段でもよい；「代理鍵」は一度使用されるとその都
度、瞬時に捨てられるから。

【００９２】配送の様子を図―６にて、１―秘密鍵ＤＢ
から７―暗号化された“ｓｋｎ”までに示す。１―秘密
鍵ＤＢから該当するユーザーの秘密鍵＜ｃｋ0.serv＞を
どのように探し当てるか、この仕組みを「初期認証」と
いうが、これには“Passnet”と名付けられたパスワー
ドを使う。“Passnet”は、ユーザーが携帯するメデイ
ア（図―６―９に示す）に、ユーザーの秘密鍵＜ｃｋ0.
serv＞と一緒に格納されているランダム・データであ
る。

【００９３】該“Passet”とは、どのようなパスワード
か後述する（なおユーザーの携帯するメデイアにどのよ
うに「安全に格納する」かの仕組み等は派生技術なので
除外する）この暗号データを受け取ったクライアントは
（図６では初期認証応答として示される）、該端末が保
持していた秘密鍵＜ｃｋ0.clin＞と請求項１記載の「安
全な同期プロトコル（S S P）」により同じく該暗号デ
ータを復号化して代理鍵＜ｓｋｎ.clin＞を受け取る。

【００９４】但し、この段階では「サーバーが保持する
クライアントの秘密鍵」と「クライアントが保持してい
る秘密鍵」とは等しいとは限らないので、前者を＜ｃｋ
0.serv＞後者を＜ｃｋ0.clin＞と記号して区別している
（図―４では＜Ｓｋ？＞と表現している）。

【００９５】本来、秘密鍵は共有されている一対のＩＤ
兼用暗号鍵であるが、ネットワーク上でパスワードで引
き当てただけでは、それが後述する“One-Time Passwor
d”であっても、両者の秘密鍵が同じであるとは保証で
きない。

【００９６】従って、この時点では秘密鍵、代理鍵とも
クライアントに所属していたものかサーバーに所属して
いたものなのか、両者の区別を記号化した；図―６で
は、＜ｓｋｎ.serv＞を７―暗号化される代理鍵、一方
＜ｓｋｎ.clin＞を１２―復号化された代理鍵として区
別している。

【００９７】このような構成要件の中では、秘密鍵が同
じであれば代理鍵も等しいし、その逆に、代理鍵が等し
ければ秘密鍵もまた等しいことが判る。故に認証のため
には秘密鍵の代わりに代理鍵を調べる。もし該暗号化さ
れる代理鍵と復号化された代理鍵とが等しいことが、安
全に確認出来たとすると、

【００９８】

【数１５】 ＜ｓｋｎ.serv＞ ＝ ＜ｓｋｎ.clin＞ ＝ ＜ｓｋｎ＞ ： Ｅｑ．８

【００９９】結局、鍵を共有するようになるので、該ス
トリーム暗号システムは、鍵の情報理論的に安全な配送
を「認証と同時に」完了する「鍵の同期配送プロトコ
ル」を備えた事になる。

【０１００】IV.該Ｅｑ．８を確認する手段を「鍵の同
期認証プロトコル」と名付け、以下の図―７と図―４に
説明する。代理鍵を直接ネットワーク上で交換するのは
“insecureとなるから、代わりに、図―７に於いてサー
バー上の代理鍵１５＜ｓｋｎ.serv＞を初期値としたカ
オス的軌道１６―

【０１０１】

【数１６】｛ ｓｋ（ｎ＋１）.serv、ｓｋ（ｎ＋２）.s
erv、ｓｋ（ｎ＋３）.serv、、、｝

【０１０２】を生成し、一方クライアント上の代理鍵１
７＜ｓｋｎ.clin＞についても、それを初期値としたカ
オス的軌道系列１８―

【０１０３】

【数１７】｛ｓｋ（ｎ＋１）.clin、ｓｋ（ｎ＋２）.cl
in、ｓｋ（ｎ＋３）.clin、、、｝

【０１０４】を生成し、これらカオス的軌道系列を前記
乱数生成システムに戻して該圧縮変換部に入力し、それ
ぞれ対応するワーク鍵系列に変換する；

【０１０５】

【数１８】（、、ｗｋ１.clin、ｗｋ２.clin、ｗｋ３.c
lin、、、）； 図―７―２２／２３／２４

【０１０６】及び

【数１９】（、、ｗｋ１.serv、ｗｋ２.serv、ｗｋ３.s
erv、、、）； 図―７―１９／２０／２１

【０１０７】これらワーク鍵系列は「情報理論的に安全
な拡張ワーク鍵群」である。従って代理鍵を直接ネット
ワーク上で交換する代わりに、その拡張ワーク鍵をネッ
トワークへ出して交換する事が出来るようになる。該拡
張ワーク鍵を初期認証に使う場合、図―６では“Passne
t”と呼び、通常の“Password”と区別した。交換のプ
ロトコルは比較的に新しい「拡張ワーク鍵」＜ｗｋ３.c
lin＞を先に使う（この理由も既に述べた）。

【０１０８】すなわち、 （１）クライアントからサーバーへ最も新しい「拡張ワ
ーク鍵」＜ｗｋ３.clin＞を配送する―２５。

【０１０９】（２）サーバー上では２６―下記の比較を
して一致していれば「クライアントの認証」を行う：ク
ライアントのワーク鍵＜ｗｋ３.clin＞：サーバーのワ
ーク鍵＜ｗｋ３.serv＞サーバーがクライアントの認証
を実施した場合、その確認のサインをどのような手段で
クライアントへ通信するか、通常のＴＣＰ／ＩＰのプロ
トコルを使うのは“insecure”となるのは明らかであ
る。そこで、 （３）サーバからクライアントへも「拡張ワーク鍵」を
配送する。この鍵には拡張ワーク鍵であれば＜ｗｋ１.s
erv＞又は＜ｗｋ２.serv＞どちらを使ってもよい。

【０１１０】図―５／２では、＜ｗｋ１.serv＞を使っ
ている―２１。

【０１１１】（４）クライアント上では―２６の比較を
して次のことを確認する： クライアントはサーバ上でクライアントの認証が実施
された事を確認する； クライアントがサーバを認証する； （５）一致を見なかった場合は、該端末の方のイニシャ
テイブで通信を切断する―２７。

【０１１２】この鍵の同期認証プロトコルでは、

【０１１３】

【数２０】 拡張ワーク鍵の一致 ： ＜ｗｋ３.serv＞ ＝ ＜ｗｋ３.clin＞ ＝ ＜ｓｋn.serv＞ ＝ ＜ｓｋｎ.clin＞：代理鍵の共有し ＝ ＜ｃｋｉ.serv＞ ＝ ＜ｃｋi.clin＞；拡張秘密鍵の共 有し ＝ ＜ｃｋ0.serv＞ ＝ ＜ｃｋ0.clin＞；秘密鍵の共有し ＝ 認証完了（図―４に示す） Ｅｑ．９

【０１１４】そして、同時に前述のＥｑ．８を成立させ
る；

【０１１５】

【数２１】 ＝ 代理鍵の情報理論的に安全な配送 ＝ ｓｋｎ：代理鍵を共有する； Ｅｑ．８

【０１１６】故に「鍵の同期配送プロトコル」と「鍵の
同期認証プロトコル」とは同じ手続きに基ずく二つの異
なる適用であることが判る。これはカオス的写像の安全
な同期制御に基ずく、あるいは安全な同期プロトコル
（ＳＳＰ）に基ずく鍵共有の新しい方式を与える。「鍵
の同期配送プロトコル」と「鍵の同期認証プロトコル」
の両者を合わせて、このスキームを「認証付き鍵共有プ
ロトコル：Authenticated Key Agreement Protocol（ A
KAP ）」として参照する；すなわち、

【０１１７】

【数２２】AKAP ＝ SSTP ＋ SSAP SSTP：Secure Synchro-Transfer Protocol SSAP：Secure Synchro-Authentication Protocol

【０１１８】該認証付き鍵共有プロトコルは種々の目的
に応用出来る。これをサーバーの視点で考えると、従来
に無い優れた特徴を備えた「鍵サーバー：key server」
の機能を与える。

【０１１９】Ｖ．“One-Time Password”；代理鍵とそ
のワーク鍵に関する安全な同期制御（ＳＳＰ）よれば、

【０１２０】

【数２３】Ｅｑ．８／Ｅｑ．９ ＝ その他の拡張ワーク
鍵群を共有する、Ｅｑ．１０

【０１２１】も同時に実現する。該「その他の拡張ワー
ク鍵」―Ｅｑ．１１も共通鍵であることに着目すると、
次回クライアトがサーバーへ“loginする際のパスワー
ドとして使える事を発見する。しかも該拡張ワーク鍵
は、代理鍵の代わりをする、情報理論的に安全な「公開
鍵」であるだけでなく、クライアントがサーバーへ“lo
ginする度に、該サーバー上で他の偶然的イベントから
生成した整数の軌道値であったことを思い出すと、該拡
張ワーク鍵が“One-Time”であることは明らかである。
該拡張ワーク鍵を“One-Time Password”にする手順
を、ｗｋ２“Passnetの更新処理；図―７―２８／２９
に示す。

【０１２２】図―６―９のデイスクに示される“Passne
tとは、初めの“loginに使われた＜ｗｋ０＞である；こ
れを図―７―２８／２９で、新しい拡張ワーク鍵＜ｗｋ
２＞と入れ替える：

【０１２３】

【数２４】 ＜ｗｋ０＞ ← ＜ｗｋ２＞ Ｅｑ．１１

【０１２４】該ワーク鍵＜ｗｋ２＞が次回使われる“Pa
ssnetである。

【０１２５】こんな簡単なプロトコルで“One-Time Pas
sword”が成立するのは、前記の認証付き鍵共有プロト
コルのお陰である：図―８／検証―１に示されるシステ
ムはインターネット上に公開されているので、実際に鍵
サーバーへ“loginを実施して“One-Time”検証出来
る；“loginをインターネット上で連続して実施し“One
-Time”の“Passnetを検証する；（http：//ｗｗｗ.met
eora.amadagp.co.jp/）。

【０１２６】VI.“One-Time”のセッション鍵系列；こ
こで共有された代理鍵は、種々のアプリケーションを可
能にする；Ｅｑ．８より

【０１２７】

【数２５】＜ｓｋｎ.serv＞ ＝ ＜ｓｋｎ.clin＞ ＝ ｓ
ｋｎ： ｎ ＝ 0〜ｉ

【０１２８】これは拡張共通鍵群であるから、 該代理鍵はクライアントとサーバーが暗号セッショ
ンを持ったという証拠に使える。これは、商取り引きの
事実を証明する、保存に値するデータである：“Non-re
pudiality in Electric Commerce。

【０１２９】 該クライアント・サーバー双方は、安
全な同期プロトコル（ＳＳＰ）を介して“One-Time”の
セッション鍵を「等確率に」、「連続して」、「ほとん
ど無数に」共有する。該拡張共通鍵群を多数共有してい
る様子を図―５に示す。該“One-Time”のセッション鍵
の使い道には、例えば、特定のクライアントだけに特定
のコンテンツやバリューデータを提供するためのＩＤの
機能を持たせるアプリケーションが有る。（なお、図―
９／検証―２のシステムはインターネット上で検証出来
る：（http：／／ｗｗｗ.meteora.amadagp.co.jp／を参
照ください）。三番目に、 該サーバー（鍵サーバー）に参加しているクライア
ント（Ａ）と他のクライアント（Ｂ）に共通のセッショ
ン鍵を安全に与えることが出来る。一度設定されると、
該鍵サーバを介さないでも、クライアント（Ａ）―
（Ｂ）は“One-Time”のセッション鍵系列を「ほとんど
無数に」共有する。このアプリケーションは従来の“Ke
rberos”などに見られない便宜をユーザーに与える。

【０１３０】 鍵サーバー、セッション鍵、該セッシ
ョン鍵から作った“Passnetなどが“One-Time”のデジ
タル署名技術を構成する。

【０１３１】これら具体的な適用事例の紹介は、認証付
き鍵共有（AKAP）の派生技術であるので、省略し請求か
ら外した。

【０１３２】VII.“One-Time Stream Cipher”；安全な
同期プロトコル（ＳＳＰ）をベースにした「認証付き鍵
共有」を成した後に於いては、当該ストリーム暗号シス
テムの中の拡張秘密鍵は

【０１３３】

【数２６】 拡張秘密鍵の一致 ＝＜ｃｋｉ.serv＞ ＝ ＜ｃｋi.clin＞ ；ｉ＝1〜任意 ＝ ＜ｃｋ0.serv＞ ＝ ＜ｃｋ0.clin＞； ＝ ＜ｃｋ0＞；秘密鍵を共有する； Ｅｑ．９

【０１３４】を無条件に満足する。この事は、「ＴＣＰ
／ＩＰなどの一般的なプロトコルを介しても」、認証付
き鍵共有を経過することにより、「写像アルゴリズムの
安全な同期制御」をリモートで正確に実施できると同時
に、システムを“fail-safe”に設計出来ることを意味
する。

【０１３５】よって、“login”する度に、拡張秘密鍵
をもって秘密鍵を正確・確実に更新出来る手段を得るこ
とになった。該拡張秘密鍵の一つ＜ｃｋ１＞（図―２に
示される）は、そのエントロピーが“ｉ―１”ビットで
あるので、元の秘密鍵＜ｃｋ0＞の次に情報理論的に安
全な鍵である。よって秘密鍵の更新処理は極めて単純と
なる：

【０１３６】

【数２７】 ＜ｃｋ0＞ ← ＜ｃｋ１＞ Ｅｑ．１２

【０１３７】該更新のタイミングは、前述図―７―２８
／２９の“Passnetの更新処理と同じ である。この様な
単純なプロトコルの適用で対称暗号系を“One-Time”に
出来るのは、該暗号系が認証付きの鍵共有プロトコルに
よって成立しているからである。

【０１３８】VIII．鍵管理と鍵サーバー；オープンネッ
トワークでは、一般に第三者の信頼できる機関（truste
d authority:TA）または証明機関（certificate author
ity：CA）を必要としている。ユーザの身分を証明した
り、ユーザの鍵を送付したりする。鍵を管理するという
事は、これだけの適用に止まらない。鍵を生成し管理す
るというこのTA、CAこそ“データに価値を与える”要で
ある。

【０１３９】つまり署名技術の核心とその適用を見抜く
ならば、TA、CAを第三者の“信頼できる人”に期待する
のではなく、“第三者の信頼できるシステム”にしなけ
ればならないことが判る。丁度、紙幣や小切手を人手に
頼ってガリ版で刷っているような状況を想像してみれば
良い。

【０１４０】請求項５の発明は、鍵の運用管理に関して
クライアント／サーバーという当事者以外に一切人を介
在させないこと、及び鍵を情報理論的に安全なセキュリ
テイで守る仕組みに関する。サーバーは多数のクライア
ントの秘密鍵のファイル「鍵箱」を備える；図―６、秘
密鍵ＤＢがそれに該当する。秘密鍵ＤＢの管理を次のよ
うに行う；サーバーは、前１、２項記載の安全な同期プ
ロトコル（ＳＳＰ）の下で前３項の「認証付き鍵共有」
を成した後に於いて、鍵箱の任意の秘密鍵＜ｃｋ0＞を
前１、２項記載の当該秘密鍵＜ｃｋ0＞の「鍵ストリー
ム」＜ｗｋ-ｃｋ0＞によって該鍵＜ｃｋ0＞自身を暗号
化する。従って、該「鍵箱」は暗号ファイルCRYPTO（ｃ
ｋｎ：ｎ＝0,1,2,3,,）として管理される一方、該サー
バーは「復号化の手段を失う」。

【０１４１】該復号化の手段を持っているのはクライア
ントだけである。すなわち、クライアントが保持してい
る鍵＜ｃｋ0.clin＞から生成したところの前１、２項記
載の「鍵ストリーム」、＜ｗｋ-ｃｋ0.clin＞しか復号
化の手段が該システムに残されていない。そこで、前記
１乃至４項の対称暗号系は次の“login”時に、クライ
アントの該鍵ストリーム＜ｗｋ-ｃｋclin＞をサーバー
に配送し、該サーバー上で暗号ファイル CRYPTO（ｃｋ
ｎ：ｎ＝0 ）を復号化し、当該クライアントの秘密鍵＜
ｃｋ0.serv＞をサーバーへ与えるとした「鍵管理アルゴ
リズム」を実装する： （１）初期認証時（図―６―１、９→１）に於いて、
“passnetの送付と共に、上記鍵ストリーム＜ｗｋ-ｃｋ
0.clin＞を送付する。 （２）該サーバーは、該秘密鍵＜ｃｋ0.serv＞を入手す
る。

【０１４２】ここで、暗号化以前の＜ｃｋ0＞と復号化
後の秘密鍵＜ｃｋ0.serv＞とは必ずしも等しくないこと
に注意する。

【０１４３】ここからは、先のIII―代理鍵の安全同期
配送プロトコル、及びIV―代理鍵による安全同期認証プ
ロトコルを実施する。言い換えると、前３項記載の規約
［認証付き鍵共有」を成して前記１乃至４項記載の対称
暗号系を成立させるのである。

【０１４４】このように、極めて単純なアルゴリズム
で、クライアント／サーバーという当事者以外に一切人
を介在させない鍵の運用管理及び鍵サーバーを実現出来
るようになる。

【０１４５】IX.フラクタルな演算構造 請求項１及び６記載の鍵生成システムは、カントール集
合を生む従来のフラクタル構造以外に、有限精度のコン
ピュータの中に導入された新たなフラクタルな演算構造
を持つ。その結果を図―１０、図−１１に示す。この事
例では、非線型関数に、ロジステイックス曲線を使って
いる。該自己相似形レジスターの仕様は： 一様レジスターの桁数 ；１０００個：１０³、 入れ籠レジスターの桁数；１０００個：１０³、 一様レジスター上の演算は、１０³を“法”とする。

【０１４６】該自己相似形レジスターにより、連続量で
ある線分［０、１］が“discreteな１０００個の微少区
間に分けられ、その微少区間がさらに１０００個の微少
区間に分けらるという風に順次考えることが可能とな
る。その結果連続量の属性の一つである［加算個の無
限］を“discreteな自己相似形アルゴリズムで扱えるよ
うになる。この時のフラクタル次元は従来の“0.６３”
から“0.63＋1.0”に上がる（該理論は他に譲る、ここ
ではその様子を実施例、図―１０、図−１１で示し
た）。図―１０のプロットは、１５００回程度の写像演
算をした結果の、一様レジスターの先頭桁の数値を表
す；これが、ロジステイックス曲線を意味することは明
らかである。同時に、図−１１は、該先頭桁の次の桁の
数値を表すプロットである。これ以降の桁の数値も、全
て該図−１１のプロットのような様相を示す（省略す
る）。この乱雑なプロット図−１１と先の整然としたプ
ロット図―１０の意味するところは、乱雑な方のプロッ
トが“Lorentz plot”注⁴に相当する。一見乱雑に見え
る現象（図−１１）と（例えば、お湯の沸騰状況がこの
ような“Lorentz plot”として現れるが）、その現象の
背後には整然とした法則性が存在しているという関係、
この場合ロジステイックス曲線（図―１０）が存在して
いるという関係を、プロット図−１１と図―１０が示し
たのである；一見乱雑に見える現象（図−１１）とその
背後にある法則（図―１０）とのシミュレーションであ
る。

【０１４７】請求項６記載のフラクタルな演算構造とカ
オス的写像アルゴリズムが、カオス的軌道を成すという
状況証拠としては、図―１０＆図−１１以外に、鍵スト
リームの自己相関が0.01％以下、１／０ビットの偏りも
0.01％以下というデータに現れている。

【０１４８】

【発明の効果】発明の実施の形態に於いて、“One-Time
Stream Cipher”をオープン・ネットワークの完全守秘
性暗号系“Perfect Secrecy Cryptosystem”として紹介
した。

【０１４９】従来、“one-time pad cipher”は完全守
秘性暗号系であるにもかかわらず、オープン・ネットワ
ークへ適用出来なかった。“One-Time Stream Cipher”
はその困難を解決した。その発明された問題解決法と
は、一つは情報理論的に安全な鍵生成システム“Secure
Key Stream”と情報理論的に安全な同期プロトコル“S
ecure Synchro―Protocol”である。その上に築かれて
いる、もう一つの発明が、認証付き鍵共有プロトコル
“authenticated key agreement protocol”である。実
は“ One-Time Pad Cipher”に必要であった「もう一つ
別の安全な通信路」とは、この鍵共有プロトコルがその
仕組みを提供しているのである。例えば、インターネッ
ト上で“One-Time Pad cipherを実現するという事は“O
ne-Time Padcipherと同等な安全性を帯びている「認証
技術」も同時に備えねばならないことを意味している。
しかし、ここにＲＳＡは使えない；この安全性は計算量
の安全性“Computational Security”であるから。

【０１５０】従って、当該発明はインターネット上で使
える情報理論的に安全な認証技術を発明したという主張
に等しい；それをストリーム暗号系に実装し、“One-Ti
me Stream cipher”と名ずけたのである。

【０１５１】この視点から見ると、認証付き鍵共有プロ
トコルを実装したサーバーは「情報理論的に安全な鍵サ
ーバー」である。もし、従来のプロキシーサーバーに該
鍵サーバーを実装したらどうなるか；該鍵サーバーは使
用回数が無制限の“One-TimePassword”をサービスす
る。同じく、ｗｗｗサーバーに実装すれば、該ｗｗｗサ
ーバーは、認証機能“One-Time Password”を備え、
イントラネットのＤＢを暗号ＤＢに成し、その暗号と
復号の機能を提供し、インターネットとイントラネッ
トをシームレスに統合する新しいオープンネットワーク
を提供する。

【０１５２】さらに、該鍵サーバーの下に金融証券のア
プリケーションを置いたらどうなるか。当然、該金融機
関が該鍵サーバーを管理するから、該システムは、従来
の金融機関の基本システムを維持したまま、しかもオー
プン・ネットワーク上でのトレードや決済を可能にす
る。将来、金融システムにも適用可能な暗号系とは、こ
のような鍵サーバーを含んだ完全守秘性暗号系になるは
ずである。

【図面の簡単な説明】

【図１】ストリーム暗号の生成を説明する説明図であ
る。

【図２】拡張秘密鍵と情報理論的に安全なストリーム暗
号システムを説明する説明図である。

【図３】カオス的鍵と鍵ストリームの生成・更新を説明
するフローチャートである。

【図４】代理鍵の安全同期配送プロトコルと代理鍵によ
る安全同期認証プロトコルを説明する説明図である。

【図５】Ｏｎｅーｔｉｍｅのセッション鍵群を説明する
説明図である。

【図６】初期認証シーケンスを説明する説明図である。

【図７】更新シーケンスを説明する説明図である。

【図８】検証１を説明する説明図である。

【図９】検証２を説明する説明図である。

【図１０】ロジステック曲線の説明図である。

【図１１】本発明による演算結果を説明する説明図であ
る。

【符号の説明】

Ｓｋｏ セッション鍵 Ｗｋ ワーク鍵

───────────────────────────────────────────────────── フロントページの続き (54)【発明の名称】 完全守秘性暗号系を構成する鍵生成システム、認証付き鍵共有プロトコル、“Ｏｎｅ−Ｔｉｍｅ Ｓｔｒｅａｍ Ｃｉｐｈｅｒ”、“Ｏｎｅ−Ｔｉｍｅ ｐａｓｓｗｏｒｅｄ”及び鍵管理アル ゴリズム

Claims (6)

【特許請求の範囲】
1. 【請求項１】 クライアント／サーバー・ネットワーク
   （以下Ｃ／Ｓネットワーク）などで通信を行う端末双方
   に、２ｕ（ｕ＞４）進数で演算するレジスターを備え、
   該レジスターの整数空間Ｉｓのそれ自身への写像（Ｉｓ
   →Ｉｓ）を実行して「整数の軌道」を生成する写像アル
   ゴリズム部と、該２ｕ進数の「整数の軌道」を圧縮変換
   して２進の「鍵ストリーム」を生成する圧縮変換部、と
   を備えた鍵生成システムを実装し、 該鍵生成システムには、その写像アルゴリズムを過去に
   遡る逆写像を試みると、ｎ回の逆写像に対しては“ｎビ
   ットのEntropy”が生じだけでなく、上記圧縮変換に伴
   う“ Entropy”もそれに加わる「情報理論的に安全な写
   像アルゴリズム」が実装されており、 該情報理論的に安全な写像アルゴリズムを「鍵の情報理
   論的な安全性」を追求する目的で、暗号と復号のアルゴ
   リズムの中に「意図的に」埋め込んだ事を特徴とする情
   報理論的に安全な対称暗号系。
2. 【請求項２】 前記対称暗号系には、 該写像アルゴリズムによる整数軌道の任意の軌道値“ｃ
   ｋ0”を「秘密鍵」として共有すると同時に、実際に暗
   号／復号するワーク鍵には上記「鍵ストリーム」を使う
   一方、 秘密鍵＜ｃｋ0＞がどちらかの該鍵生成システムにイン
   プットされると、該秘密鍵を情報理論的に安全な秘密鍵
   にするために、該写像アルゴリズムを規定回数（ｉ回
   ）実行させて、該秘密鍵＜ｃｋ0＞の整数軌道（ｃｋ
   1、ｃｋ2、ｃｋ3、、、ｃｋｉ）を作らせると共に、該
   整数軌道値を該端末内に「保存」するという規約と、 さらに、この保存されているｉ番目の整数軌道値＜ｃｋ
   ｉ＞を初期値とした新たな整数軌道（ｃｋｉ、ｃｋｉ+
   1、、、ｃｋｉ+ｊ）を生成させて、この後者の整数軌道
   を圧縮変換した「鍵ストリーム」をワーク鍵に使うとい
   う規約と、 これら二つの規約から構成される「安全な同期プロトコ
   ル：Secure Synchronous Protocol：ＳＳＰ」を実装
   し、 該「安全な同期プロトコル」を共有する事により、対称
   暗号系の共通鍵の安全性を計算量の安全性“Computatio
   nal Security”ではなく、情報理論的に安全な、つまり
   “Unconditional Security”の問題に帰着させたたこと
   を特徴とする対称暗号系。
3. 【請求項３】 秘密鍵＜ｃｋ0＞を共有している前記
   １、２項記載の対称暗号系は、互いに相手を確認しうる
   手段（ＩＤ）として共有している秘密鍵＜ｃｋ0＞を、
   認証の手段としてネットワーク上で交換せず、保持する
   と共に、 対称暗号系のサーバー上で他の偶然的イベントを初期値
   とした別の整数の軌道値を生成し、これを前記安全な同
   期プロトコル（ＳＳＰ）の下でサーバーが保持している
   クライアントの秘密鍵＜ｃｋ0.serv＞によって暗号化
   し、該秘密鍵＜ｃｋ0.serv＞の「代理の鍵＜ｓｋｉ.ser
   v＞」として他方のクライアントに配送する一方、 この暗号データを受け取ったクライアントも、該クライ
   アントが保持していた秘密鍵＜ｃｋ0.clin＞により同じ
   く前記“ＳＳＰ”の下で該暗号データを復号化して「代
   理鍵」＜ｓｋｉ.clin＞を受け取るという規約「鍵の同
   期配送プロトコル」を実装し、 さらに、サーバーは代理鍵＜ｓｋｎ.serv＞を初期値と
   した整数軌道を生成して該拡張代理鍵群を保持し； 【数１】｛ｓｋ（ｎ＋１）.serv、ｓｋ（ｎ＋２）.ser
   v、ｓｋ（ｎ＋３）.serv、、｝、 一方クライアントも代理鍵＜ｓｋｎ.clin＞について、
   それを初期値とした 整数軌道を生成して該拡張代理鍵
   群を保持し； 【数２】｛ｓｋ（ｎ＋１）.clin、ｓｋ（ｎ＋２）.cli
   n、ｓｋ（ｎ＋３）.clin、、｝ 、 これら拡張代理鍵群をそれぞれ前記鍵生成システムの圧
   縮変換部に入力し、それぞれ対応する拡張ワーク鍵系列
   を生成し、かつ保持し； 【数３】｛、、ｗｋ１.serv、ｗｋ２.serv、ｗｋ３.ser
   v、、、｝ ｛、、ｗｋ１.clin、ｗｋ２.clin、 ｗｋ３.cli
   n、、、｝ これら情報理論的に安全な拡張ワーク鍵群をネットワー
   クへ出して交換するという規約「鍵の同期認証プロトコ
   ル」を実装し、 該「鍵の同期配送プロトコル」と「鍵の同期認証プロト
   コル」の両者から構成される「認証付きの鍵共有プロト
   コル：Authenticated Key Agreement Protocol」を実装
   する事を特徴として秘密鍵の共有を実現する前記１、２
   項記載の対称暗号系。
4. 【請求項４】 対称暗号系の端末双方が“login”後、
   前記１、２項記載の安全な同期プロトコル（ＳＳＰ）の
   下で前記３項記載の「認証付き鍵共有」を成した後に於
   いては、当該対称暗号系の中の鍵群は、 拡張ワーク鍵の一致 ＝ 拡張秘密鍵を共有する、 【数４】 ＝ ＜ｃｋｉ.serv＞ ＝ ＜ｃｋi.clin＞ ； ｉ＝1〜任意 ＝ ＜ｃｋ0.serv＞ ＝ ＜ｃｋ0.clin＞； ＝ ＜ｃｋ0＞；秘密鍵を共有する、 を無条件に満足する共通鍵群となるので、 “login”が発生する度に、端末双方とも一回使用した
   秘密鍵を該共通鍵群の中の未使用の拡張秘密鍵をもって
   「更新する」ことを特徴とした対称暗号系又は、前記
   １、２、３項記載の構成要件を満たす“One-Time Strea
   m Cipher”、同じく前記１、２、３項記載の構成要件を
   満たすことを特徴とした“One-Time Password”。
5. 【請求項５】 多数のクライアントの秘密鍵のファイ
   ル「鍵箱」を備えたサーバーが、その鍵箱を情報理論的
   に安全なセキュリテイで守るために、前記２項記載の安
   全な同期プロトコル（ＳＳＰ）の下で前記３項の「認証
   付き鍵共有」を成した後に於いて、 該サーバーは、「鍵箱」の任意の秘密鍵＜ｃｋ0＞を前
   記１項記載の当該秘密鍵＜ｃｋ0＞の「鍵ストリーム」
   ＜ｗｋ-ｃｋ0＞によって該鍵＜ｃｋ0＞自身を暗号化
   し、該「鍵箱」を暗号ファイルCRYPTO（ｃｋｎ：ｎ＝0,
   1,2,3,,）として管理する一方、 前記１乃至４項記載の対称暗号系がこれを復号化するに
   は、該クライアント自身が保持している鍵＜ｃｋ0.clin
   ＞から生成した前記１、２項記載の鍵ストリーム＜ｗｋ
   -ｃｋ0.clin＞しか復号化の手段が残されていないの
   で、 前記１乃至４項記載の対称暗号系は、次の“login”時
   に、該クライアントの該鍵ストリームをサーバーに配送
   し、 該サーバー上で暗号ファイル CRYPTO（ｃｋｎ：ｎ＝0
   ）を復号化し、当該クライアントの秘密鍵＜ｃｋ0.ser
   v＞をサーバーへ与えるとした「鍵管理アルゴリズム」
   を備え、 これにより該サーバーは該秘密鍵＜ｃｋ0.serv＞を入手
   した後には、前記３項記載の規約「認証付き鍵共有プロ
   トコル」の実行に入ることを特徴とした鍵管理アルゴリ
   ズム及び鍵サーバー。
6. 【請求項６】 前記１項記載の鍵生成システムのレジス
   ターは、１０ⁿ（ｎ＞＝１）個または２ⁿ個（ｎ＞１）の
   桁から成立する一様レジスターであり、その一桁も又１
   ０^m 個または２^m個の桁から成立する（ １０ⁿ ＜＝１０
   ^m）一様レジスターであり、というように「入れ籠構
   造」を成した「自己相似形レジスター」であることを特
   徴とする一方、 該鍵生成システムの写像アルゴリズムは、該一様レジス
   ターを１０ⁿ 進数または２ⁿ進数の整数空間Ｉｓと見な
   す該整数空間のそれ自身への写像演算Ｆである；（Ｆ：
   Ｉｓ→Ｉｓ ）。