日付：1999/3/25
電子署名電子署名とは（少なくとも私にとっては）ちょっと誤解を招きやすい言葉である。
実生活の署名というのがどのようになされるかを思い出してみよう。文章を確かにある人がみましたよ、ということを示すために文章に自分の名前なり、サインをするわけである。人間には筆跡というものがあるから、他人の文字は簡単にまねできないことになっている。従って自筆で名前を書くことは「確かに私が見ました」ということの証明になるわけだ。
さて話は変わって電子データの上での電子署名である。電子データで署名をするにはどのような方法があるだろうか？私がタイプした「大坪五郎」という文字も、隣の人間がタイプした「大坪五郎」という文字も何をどうしたって区別はつかないのだ。
この問題について調べるとかなりおもしろいことがわかるのではないかと思う。例えば最近ではみられなくなった、メーカー特注のクローズドシステムであれば結構容易に電子署名なるものが実現できるかもしれない。例えば電子的に回ってきたメールに対して、あるIDとパスワードでログインした人がその書類を見た、ということをシステムのほうで管理するのである。勝手な推量であるがたぶん１９７０-８０年代に「統合文書化システム」なる名前で販売されていた怪しげなシステムの「電子署名」なる機能はおそらくこうした方法で行われていたのではないか。
しかしこうした方法はインターネットを飛び交うオープンなメールや書類に使用するわけには行かない。だいたいインターネット全体でIDだのパスワードだのを管理している組織は存在しないのだ。では今ちまたで言われている電子署名とはいかなものであろうか。本書に載っている内容を要約すると以下の通りである。
さて現在言われている電子署名は、公開鍵アルゴリズムを利用している。以下の説明で、署名を行おうとする人間は、秘密鍵を保有していて、それに対応する公開鍵を世間一般に広く配布しているものとする。
さてその前提に基づいて行われる電子署名の方法は以下のようだ。
(1)平文テキストを作る
(2)テキストをＭＤ５関数で処理し、要約数を作る。（ここで生成される要約数とは１２８ビット、１６バイトのデータである）
(3)要約数を自分の秘密鍵で暗号化する。
(4)テキストと暗号化された要約数を送付する。
(5)メッセージを受け取った側は、公開鍵で要約数を複合化する。
(6)送付され、複合化された要約数と、テキストをＭＤ５で処理して生成した要約数を比較する。一致すれば二つのことが証明される。
（その１）送られた文章が、送信者が署名した時から改竄されていないということ。もし改竄されていればＭＤ５関数は異なる要約数を生成するはずだ。（その２）またＭＤ５は本人しか持っていない秘密鍵で暗号化されたので、公開鍵で復号化できたということは、間違いなくその公開鍵に対応する秘密鍵の所有者（すなわち送った本人）が署名（暗号化）したものだ、ということになる。
ざらざらと書いたが、だいたい内容については直感的に分かると思う。さて、「公開鍵暗号」の章の最後に、「公開鍵暗号の主要なアプリケーションの一つ、電子署名」と書いた。なぜかと言えば「秘密鍵を持っているのは本人だけだ」という前提は公開鍵暗号の場合にしか成立しないからである。共有鍵暗号の場合にはその定義によって、鍵は複数の人間の間で共有される。従って仮にその鍵でＭＤ５要約数を復号化できた、といっても送信元が署名した（すなわち鍵を使って暗号化した）とするわけにはいかない。
ここで私のような素人はふと考えてしまうのである。なるほど確かにこれは通常の署名と同じ効果を持っている。しかしその署名として暗号化する対象がＭＤ５なる聞き慣れない関数で生成されたこれまた聞き慣れない要約数なるものであるのはいかなるわけか。電子であっても「署名」なのだから例えば私が署名したいメールであれば"Goro otsubo"なる文字でも書いておけばいいではないか。いずれにしたって私の秘密鍵を持っている人間は私だけなのだから、公開鍵で復号できた、ということはそれは私が署名した、ということなのだ。
この論議はたぶん（狭い意味では）正しいのだと思う。しかしながら、（私は１５分ほど頭をひねった結果）こんなことを考えるのは私が「署名」という意味をよく理解していないせいだ、という結論に達した。
署名というのは、「与えられたテキストの内容を私が読んで、それに私が読みましたよ、という事を示すためにする」ものである。従って要求される性質には
（その１）私が確かにみました、という「私」を特定できる性質。
（その２）私が見て、署名した内容と、その後別の人間の目に触れる内容が同一であることが保証できること。
という二つの性質が要求されるのである。私が先ほど書いた「Goro otsuboと書いて暗号化しておけばいいじゃないか」という案はそのうち（１）の性質しか満足していない。私がGoro otsuboとかこうが、別の人間の名前を書こうが、内容が改竄されていない、ということの保証にはならないのである。
人によっては「何をわかりきったことをぐだぐだと」と言われることを私がこんなに感慨深げに書いているにはちゃんとわけがある。
私が最初につとめた会社では、資料や図面に必ず上位者の点検と、点検をしました、という事を示すためのサインが必要であった。そして仮にサインをとった後に少しでも訂正があれば、サインをすべて取り直さなくてはならない、という決まりになっていた。
さて私はとても怠け者であるし、おまけにせこい性質であるし、さらに人によってはすんなりサインをくれないばかりか、「何だこの図面は」といって私を立たせたまま何十分（ひどい場合には何時間も）罵声を浴びせる人もいたのである。こうした罵声には今から考えれば確かにそれなりの意味があったのだと思う。しかし当時の私にはそんなことはわからなかったし、そうして罵声を浴びせるのに疲れた相手がようやく名前を書いてくれるとそれはとてもありがたいものに思えたのである。ちょっと訂正があるからといってまたその恐ろしい人のサインをもらう、なんてのはあまり魅力的なオプションではあなかったのだ。
従って「サインをもらった後の内容改竄」は私の得意技となったのである。それがためにひどいトラブルに遭遇しておまけにサインした人間に「おれはこんな内容にサインした覚えはない。」とよけい怒鳴られ、、、などと書いてもしょうがないことだ。とにかく私は前述の署名のもつ二つの性質のうち後者を（問題があるほど）非常に軽んじていたので、前にあげた妙な疑問を思いついたのである。
さてこの「改竄されていない」という同一性（本書では完全性と言っているが）を保証するためのキーは要約数とそれを生成するＭＤ５関数である。これらにてちょっと書いておこう。
要約数とはもっと広く使われている言葉で言えばチェックサムのようなものである。チェックサムとは何か？例を挙げよう。
例えば以下に示す１０個のデータがあったとする。
１，３，５，２，２４５，５５，３４、２，５，１０
このデータをなんらかの方法で送るとして、データの一つが欠けたりあるいは変化してしまう可能性があるかもしれない。どうすれば受け取った側で「ちゃんとデータが送られた」というチェックが行えるだろうか。
一番単純な方法は、この１０個のデータに加えて、１０個のデータの合計数を送ることである。つまり送信データはこうなる。
１，３，５，２，２４５，５５，３４、２，５，１０、３６２
最後の３６２がチェック用の合計値-チェックサムである。この一つの数字を加えることで、伝送の際のいくつかのエラーを検出することができるようになる。例えば一番最初の１が欠落してしまったとしよう。すると受け取った側では「なんだ。チェックサムをとってみたら、３６１になって、３６２と違うじゃないか。データエラー。もう一度送れ」と言えるわけである。このようにデータが一つ丸ごと落ちた場合でなくても例えば２番目の３が５になってしまった場合でも検出は可能である。
かくのごとくチェックサムというのは大変便利なのであるが、これだけの説明でもこの方法が検出できるエラーには限界があることがわかるだろう。二つ以上のエラーがお互いをうち消すように発生した場合、たとえば最初の１が欠落して、かつ２番目の３が４に化けたらもう検出は不可能である。
さてこうした事をつらつらと考えると、よい要約数にはいくつかの性質が求められることがわかる。
(1)与えられた文章から要約数を計算することが（或程度）容易でなくてはならない。
(2)与えられた文章と同じ要約数を生成する文章を計算することが困難でなくてはならない。
条件(1)は実際に世の中で使用されるために必要な事。（計算に１００年もかかる要約数を誰が使おうと思うだろうか）(2)はデータが改竄されていないことを保証するために必要なことである。
さてこの条件(2)についてであるが、データが改竄されていないことを「完全に」保証するためであれば、この条件中の「困難でなくてはならない」を「不可能である」にしたいところだ。しかしながらそれは「不可能である」
理由は簡単で、要約数はその定義によってたいていの場合元の文章よりも短いものだからだ。（それでなくては「要約」数とは呼ばれない）例えばＭＤ５関数が生成するのは１２８ビットの数である。すなわち１６バイトしかないので、一文字一バイトだとしても１７文字の文章を作れば、ありうるすべての組み合わせ（それが文章として意味をもつかどうかは別として）のなかで同じＭＤ５の要約数を生成する文章は２５６も存在することになる。
さてこの性質が何を意味しているかを理解するために具体例にあてはめてみよう。
たとえばさっきの単純なチェックサムである。計算はとても楽だから、（１）の条件はOKだ。ところが（２）に関しては全くだめである。同じチェックサムを生成する数列なんてのは山のように考えられる。検出を行う対象が意図的に改竄されることを想定せず、データの欠落などをみはっていればいいのならばこれでも或程度の効果はあるだろうが、悪意を持った攻撃者に対しては全く無力である。
さてＭＤ５についてはどうだろう。(1)の条件はだいたい満足していると思われる。（実際に使われているのだから）もっともここで言っている「或程度」というのがくせもので、そのアルゴリズムはここに簡単な要約を書けるようなしろものではない。実際この関数の内部を説明した図を見ると、暗号化の説明図と大変よく似ている気がしてくる。
さて(2)の条件はどうだろうか。本書によれば、未だかって同じＭＤ５要約数を生成する２つのファイルが発見されたことはないという。（この本が執筆された時点で公開されている範囲での話だろうが）従って実際的には「異なる文章からは異なるＭＤ５要約数が生成される」、すなわち条件(2）も満たしている、としてもよさそうだ。
このＭＤ５のように要約数を生成する関数は他にもたくさんあり、（ＭＤシリーズだけでも２，４，そして５があるのだ）ハッシュ関数と呼ばれている。また本書で要約数と呼ばれているものは、メッセージダイジェストとも呼ばれるようだ。これらは厳密に言うとここらへんの用語は意味が違うのかもしれないが、私にはその違いがわからない。ただこの文章を読む人が、やたらとでてくる新規な言葉にぶつかったときに理解してもらえるようにとりあえずここに書いておく。
これでめでたく電子署名の説明をお開きにする。次には実際にどのようにこれらの暗号関連技術が使われるか、ＰＧＰ(Pretty Good Privacy)を例にとって説明する。
ＰＧＰ；Pretty Good Privacyというのは、数種類のコンピューターで動く、誰もが使用できるフリーの暗号化プログラムだ。本書にはなぜこのプログラムが開発されるに至ったか。その過程でどのような問題と戦ってきたかが、とても詳細に書かれている。実際にこのプログラムを使った人は「輸出バージョン」とか「RSAFFは使用していません」とかいうメッセージを目にしたと思うが、それらにはちゃんと理由があるのである。ここで書いても本書の繰りかえしになるだけだから、ここらへんの経緯については是非本書を見てほしい。
さて、ＰＧＰに関する簡単な解説書を見ると、「ＰＧＰは公開鍵暗号を使ったシステムです」と書いてあることがある。ふーん、と思って別のＰＧＰの解説書を読んでいくと「ＰＧＰは共有鍵暗号であるIDEAを使用しています。」と書いてある。私は最初ＰＧＰについてしらべたとき「何だこれは？」と思ってしばらく悩んだ。
ＰＧＰはファイルを暗号化し、必要であれば署名を行う為のプログラムである。なぜファイルを暗号化したいか、と言えば、一つには他人に見られたくない自分だけの情報を隠すためかもしれない。この目的であれば確かにIDEA共有鍵暗号を使えば十分だ。鍵は自分だけが知っておけばよい。暗号化複合化を行うのはあなただけなのだ。
ところがそのファイルを電子メールとして相手に送る、そして第３者によまれないために、暗号化したい、、、こうした目的を考えたときには共有鍵暗号に「鍵の配布、共有」という問題があることを前述した。そして公開鍵暗号がそれを解決することについても書いた。
従って普通に考えれば「ああ。なるほど。PGPは公開鍵暗号を使ってファイルを暗号化しているわけね」でおしまいになる。ではどこに共有鍵暗号の出番があるのだろうか？
今までふれていなかったが、公開鍵暗号には欠点（というか特徴）がいくつかある。そのうちの一つに、「共有鍵暗号に比べて処理が遅い」というものがある。RSA社のFAQ(http://www.rsa.com/rsalabs/faq/)によると、RSAの処理スピードはソフトウェアで処理した場合、DESの１／１００．ハードウェアで処理した場合DESの１／１０００〜１／１０，０００だという。（そうはいってもRSAの処理速度自体、１９９９年中には1MBits/secに達すると書いてはあるのだが）これだけ遅くてはちょっとしたメールの暗号化ならとにかく、大きなデータの暗号化（特にリアルタイムに流れる音声、ビデオなど）には向かないかもしれない。
さてここで共有鍵暗号の問題点がほとんどすべて「送り手と受け手で鍵を他人に知られずに共有化する」必要性から生じていたことを思い出そう。公開鍵暗号には処理に時間がかかるから、全文を公開鍵暗号を使って暗号化するのは適当でない。一方共有鍵暗号の問題点は鍵の共有だけだ。となれば共有鍵暗号の鍵だけを公開鍵暗号を使って暗号化し、相手に送付するという方法が考えられる。
実際ＰＧＰではそうした暗号化の方法がとられている。ＰＧＰに貼付されている"How it works"という文章にＰＧＰの動作方法概略が書いてある。その概略（＋私の勝手な付け足し）は以下の通り。
(1)ユーザーに見えないような形で、そのセッション（この場合は暗号化のプロセス）だけに使用されるランダムな鍵（以降セッション鍵と呼ぶ。もっともこの言葉はＰＧＰの該当ドキュメントにはでてこない。）が生成される。
(2)共有鍵暗号方式であるところのIDEAと、(1)で生成されたセッション鍵を使ってファイルの暗号化が行われる。
(3)想定される受取手の公開鍵を使ってセッション鍵を暗号化する。
(4)メッセージ要約関数ＭＤ５を使ってファイルの要約数を作成する。生成された要約数は送り手の秘密鍵で暗号化される。
(5)IDEAで暗号化されたファイルと、受取手の公開鍵で暗号化されたセッション鍵、それに送り手の秘密鍵で暗号化された要約数を相手に送付する。
(6)ファイルを受け取った人は、
（その１）まず自分の秘密鍵でセッション鍵を復号化する。（その２）次に復号化されたセッション鍵を使ってファイルを復号化する。
（その３）複合化されたファイルから、ＭＤ５を使って要約数を計算する。
（その４）相手の公開鍵を使って送付されてきた要約数を復元する。
（その５） （その３）で計算された要約数と、（その４）で複合化された要約数が一致すれば相手が署名したこと、また途中で改竄されなかったことが確認できる。めでたしめでたし。
ＰＧＰでは、今まで説明（というかだらだらと書いてきた）してきた内容が以上のような形で使われている。実際にはほかにもいろいろな秘密保持上のしかけが用意してある。たとえばあなたのパソコンを他人が黙って使ったときのためにＰＧＰの使用者にパスフレーズを入力させる、とか相手毎の公開鍵を管理する方法、その公開鍵が本当に相手から来たものであることを証明する方法等々。しかしこれ以上の説明は省略する。直接本書か関連のホームページなどを参照してもらいたい。（実際ＰＧＰというキーワードで検索をすれば山のようなページがヒットするはずだ）
さて今までは直接「目に見える暗号」について書いてきた。（ＰＧＰで生成された結果を-Textだが-見ればこれはおそらく何かのバイナリファイルをテキストに変換したものか、あるいは暗号化された文章だということはすぐ分かる）しかし暗号技術の応用というのは、「見える暗号」だけにとどまらない。某所で暗号についてのお話を伺ったとき（１９９２年のことだが）「究極の暗号は暗号であることを悟られない暗号だ」というお話を伺った。そうした「目に見えない暗号」の一分野である電子すかし（透かし）について次に述べる。
証明になる：私は最初につとめた会社で、ヒラの時代に部長のサインを偽造したことがあるが。だってその日の朝のうちに提出しなければならなかったのに部長がいないんだもん。幸いにもサインをする用紙は半透明のタイプだったので、部長の他のサインの上に紙を載せてそのまま手でなぞったのである。ちゃんと後日その部長にサインをもらって事なきをえたが。本文に戻る
わけにはいかない：よくよく考えると一つの鍵は特定の２人の間でしか使用されない、という前提が貫かれるとすれば、共有鍵暗号でも電子署名ができるとは思うのだが。署名が復号化できた。鍵をもっているのはあいつか俺だけだから、これを署名したのは私でなければ（私が健忘症にかかっているのでなければ）あいつだ、ということになる気もする。本文に戻る