このところどうも暗号づいてます。Java ですと簡単に暗号化が利用できるのもあって、「暗号」というものの利用法をいろいろと考えるのですが、特に Web アプリの場合には、単に「読まれない」というだけではない利用法があるように感じています。

というのは、

平文と対立する意味での「暗号文」を、勝手に第３者がそれらしく偽造することができない。

 というメリットじゃないか、ということなんですね。要するに「電子署名」で作られた「署名」は、これを作ることができるは本当にその暗号鍵を持っている人だけである、というのと同様なメリットです。

ですから、暗号化されたキーを解読して、それが意味の通った内容であるかどうか、をチェックすることで、そのリクエストの正当性を保証する、というような使い方があるようにも感じるわけです。

たとえば、Web アプリとそれ以外のサービスを組み合わせて使う場合（とか Servlet でもコンテキストが違う場合）、セッションを共有させるができませんから、何らかの手段で互いを紐づける必要があるわけです。この時に、単なる ID で相互に紐付けた場合、悪戯心（悪意まではいかなくてもね）のあるユーザが、「その前後の番号を入れたらどうなるの？？」と、手入力でそういう ID を入れて実験してみる可能性を否定できないわけです。

勿論セッションキーは「使われていない番号が圧倒的に多い巨大な数値」ですから、こういう「手入力でセッションキーを入れてみて大当たり」という可能性が極端に少ないわけですが、アプリ側で相互のデータ紐づけに使う　ID の場合、意外に脆弱な値を使っていることもあります。たとえば、

ウェブアプリへの入り口はこちらへどうぞ！ http://web.app.jp/context?user=yamada@mydomain.jp

というような文の埋め込まれたメールを、yamada@mydomain.jp 氏に送った場合、ひょっとして yamada@mydomain.jp 氏は

http://web.app.jp/context?user=myfriend@mydomain.jp

でトライするかもしれません！

この時、user の引数である「yamada@mydomain.jp」 を何らかのやり方で暗号化して、 

http://web.app.jp/context?user=31dIWa7lHSOWE

というかたちになっているだけで、こういうトライを未然に防止できるわけです。

たとえば、この暗号の中に「有効期限」を含ませて暗号化すれば、「期限切れ」というようなかたちで再利用を防止することもできます。ここまでやるとほとんどセッションＩＤみたいな使い方になりますよね。

あるいは、「これをイジられたら他人の情報が見えちゃう」というキーなりＩＤは、たとえばフォームの中にあるかもしれませんし、あるいはクッキーの中にあるかもしれません。もし、悪意あるプログラマが「弱点を衝いてやる！」とリクエストを解析した時には、こういう一般ユーザは意識しないデータでさえ、侵入の糸口になるかもしれないわけです。

一般論として内部的な管理データ（ＩＤ）を外部に晒すのは良いことではありません。そういう内部データを保護するために、暗号を使うというのが私の場合一番頻繁に使う使い方...なのは、歪んでるかなぁ？？

さて、半分はまだジョークの世界です。

「暗号」の対義語として「明らかな符号」であるところの「明号」という概念がある（と断言するほどはっきりしたものではないです）ような気がしませんか？　ネットで検索すると、今のところ次のような使い方で「明号」がひっかかります。

1. 暗号ロジックが未熟なために、簡単に解読される暗号を揶揄して「明号」と呼ぶ。皮肉ですね。

2. 公開鍵暗号のように、「鍵を明るい場所に出す」暗号を、それまでの秘匿鍵暗号と対比させて「明号」と呼ぶ。まあ、公開鍵暗号でも秘密鍵は依然としてあるわけですけどね。

3. 暗号技術が軍事とか外交のような特殊場面に使われるものではなくて、今のようにコンピュータの基礎技術になった状況変化を受けて、秘密な技術で「後ろ暗い暗号」ではなくて、みんなで公開の討議の対象となるような暗号を「明るい暗号」と捉えよう、という考え方。これはどっちか言えば気分の問題ですね（苦笑）。真面目に「明るい明号、楽しいセキュリティ」をスローガンに掲げる人もいます。

さて私としてはこれが真打なのですが..

4. 「暗号」が特に鍵を知っている人以外は全然解読できないものであるのに対して、「明号」はどのような知的存在であっても間違いなく解読できるもの。この「知的存在」は人間じゃない、ということを前提にしています。言い換えると「宇宙に向けて電波信号を発信したり、無人宇宙船に載せて宇宙人と遭遇したときに、『地球の人類はこういう存在だ』というのをどうやって宇宙人に伝えるのか？」という問題の中から、「明号」という概念が出てきたもののようです。

少し前に「非対称の起源」という本を読みました。この本は「右と左」という概念についていろいろなジャンルを横断して考察している面白い本ですが、この中で「宇宙人に対して、どうやって『右と左』という概念を伝えることができるのか？」という問題について検討しています。宇宙空間には上も下もありませんし、宇宙人が住んでいる惑星が地球と同じ向きで公転している保証もありません。また、宇宙人の左側の胸に心臓がある、なんて保証もないわけです。どうすれば右・左を伝えることができるのでしょう？（これは長くなるので本の方をお読みください）

ですから「左右」のような基本空間概念であっても、それを「明号」で表現しようとすると実に難しいわけです。とはいえこの「明号」の実装は、とりあえず「数」の概念の記述から始まるようです。数学はどんな宇宙であっても一様であり、しかも語り手自身が「知的存在」であることを言外に伝達できます。

そう考えてみると、プログラミングというものは本質的に数学に基盤を置いています。ですからソートは宇宙のどこに持っていっても、並べ替えをするわけですね。勿論アルファベットはASCIIに束縛される必要はなくて、単に「区切り文字ではない」ものというだけの意味で捉えれば、「私が書いたプログラム」を「宇宙人が読んで理解できるか？？」という視点で、見直してみるというのも面白いかもしれません。（良い）プログラムは明号かも？

私は別に専門家じゃないですけど、暗号関連の話って大好きだったりします。このところ「自然とランダム」と「秘奥義メルセンヌ・ツイスター」で、ランダム性と強く結びついた暗号関連話が続いたところで、こんな名前のアルゴリズムがあったりするんですね。

あ、これ開発者の３人の連名で付いているだけです。ブラムさん２人とシャブさんが開発したアルゴリズム....というだけの名前ですが、メルセンヌ・ツイスターがアニメの必殺技だったとすると、こっちはクトゥルフ神話（苦笑）かな。

この Blum Blum Shub アルゴリズムは、暗号論的に安全な一連の乱数を提供します。言い換えると、メルセンヌ・ツイスターが漸化式によるものなので、「前の値から次の値を推測する」ということができてしまう...のに対して、Blum Blum Shub は「前の値から次の値を推測できないことが、数学的に証明されている」（ま、現実には前の値から次の値を推測する困難性が、素因数分解の困難性と同じであるようにしているわけです）アルゴリズムです。強力なアルゴリズムですが、これ数論としてはそんなに難しい知識を使っているわけじゃないようです。ですからメルセンヌ・ツイスターを種にして Blum Blum Shub で希釈すれば安全だ、という感覚のようです。メルセンヌ・ツイスターは「充分にランダムに散らばった種」を提供しますからね。

そういう具合に結構ここらへんの数学寄りの応用アルゴリズムって、目立たないけども重要な進歩が1990年代後半にかなりあるようですね。この理由は勿論インターネット環境の普及があって、セキュリティに関する議論が盛んになったことから、こういう暗号技法が着目された（RSAとかもそうですね...）わけです。

勿論こういう暗号技法の「意外な利用」の最大なものは「電子署名」ですけども、一時私も面白がって調べたことのあるいわゆる「マジック・プロトコル」がいろいろあります。たとえば通信環境で「コイン投げ」を公平に行うためのプロトコルとか、電子投票で「投票者の投票内容が秘密」なのに、投票全体が公正であるか（たとえば二重投票した人がいないとか）を検査できるプロトコルとか、面白い応用例がいろいろとあるわけです。ここらへん数学的には「ゼロ知識証明」と呼ばれる新しいジャンルです。興味のある方はこういうキーワードで調べてみると刺激的ですよ！

 

さて、前回のランダムの話の続きです。で、乱数生成器の話をいろいろと調べていたのですが、面白いものを見つけちゃいました。その名も「メルセンヌ・ツイスター」という乱数生成アルゴリズムです。

これ、日本人が発明したアルゴリズム（まつもとまこと氏。ちなみにご夫人は少女漫画家の明智抄！）で、擬似乱数生成器としては、現在最強のアルゴリズムとして知られているようです（ただし、漸化式から次の値を推測できるので、そのまま暗号用には使えません）。「最強」というのは、乱数の品質が極めて高く、極めて長い周期（2¹⁹⁹³⁷-1）と高次元（623次元）に均等分布にする、という極め付きの品質を持つ、のにも関わらず、乗算・除算のような遅い計算がほとんどないので、極めて高速に乱数を生成します。

そういうわけで、メルセンヌ・ツイスターの擬似乱数アルゴリズムライブラリや、シミュレーションソフトでの採用がかなり進んでいるようです。

.....けど、このメルセンヌ・ツイスター、やはり萌えはネーミングですね。カッコイイです。ほとんどアニメの必殺技...と思っていたら、ジョークページがありました（苦笑）。

きのこに媚薬

あと、このまつもとまこと氏が市民向けの講演会向けに書いた「りんごが落ちたって万有引力は発見できないさ -- 今の学問、社会のニーズに惑わされてない？」という小論は、面白いです。一読をすすめます。

 

今回は「ランダム」についての話でもしましょうか。

デジタル技術というものは決定論的です。デジタル技術がその根底に置くアナログ変量自体は、細かく見ていけば本質的にランダムな揺らぎを持つものなのでしょうが、そういうランダムな揺らぎを封じ込めて、たとえば「+3V以上は 1」という具合に、「決めて」しまうことでデジタル技術というものが成立しているわけです。

ですからそういう「決めて」しまうような、「抽象化」の上に成立するデジタル技術というものは、本質的に決定論的でないことはありえません。一般によく使われる線形合同法による乱数アルゴリズム（rand() で実装されるタイプのもの）は、「一見乱数みたいに」見えることだけを目的にしています。ですから、たとえばモンテカルロ法のような「乱数の品質によって値が異なる」アルゴリズムですと、足を掬われる結果が出る可能性もありますし、セキュリティが重要なケースでは「今出た乱数の値から次に出る乱数の値を推測する」ことが、アルゴリズムがバレている場合に不可能である、とは言えません。要するに rand() は本当の乱数を生成するのではなくて、「一見乱数に見える」数、「擬似乱数」を生成するのです。

私はそういえば心理学科の出ですから、学校時代「乱数表の使い方」とか手ほどきを受けてたりします（昔話ですね）。探すと今でもネット上に一様乱数表があったりします。勿論こういう乱数表の元はJISで決まっている乱数表の一部を載せているだけなのですから、より大きい乱数表をネタにして乱数を生成する...というのも「擬似乱数ではない」本当の乱数を得る手の一つです。

とはいえ、こういう乱数表に頼るのは現状ではあまり一般的な手段ではないでしょう。たとえば Tomcat でセッションキーを得るのに使う、Java の java.secure.SecurityRandom クラスでは、別なやり方をしていたりします。

これは Linux などの UNIX 系での JVM のやり方ですが、もし、 /dev/random（など） があれば、そこからランダムシードを得て乱数を生成します。このデバイスファイルとして実装された /dev/random と /dev/urandom です。

この２つは、ランダムジェネレータの仮想デバイスです。両者の違いは読み込み時にブロックするかどうかで、Java1.4まではブロックする /dev/random がデフォルトで $JAVA_HOME/jre/lib/security/java.security で securerandom.source プロパティに書かれていましたが、Java5からはブロックしない /dev/urandom に変更されています。

このランダムジェネレータは結構面白いものなのです。セキュリティツールをインストールする際など、「キーボードを叩き続けなさい」という指示が出て、適当にキーボードを叩く、ということをしますが、これは /dev/random を使うやり方なのですね。

というのは、「コンピュータの内部ではなくて、コンピュータの外側」にランダムの源を得る、というのがこの「キーボードを叩く」という儀式なのです。言い換えると、「人間がすること」であるキーボード入力の間隔から、こういうランダムの種を仕入れてくるわけです。

人間の行為は観念ではなくてアナログな自然現象です。だからこそ「ランダムの種」になりうるわけなのです。とはいえ、コンピュータの内部にだって、本当は自然現象があるのです。今の /dev/random は条件が合えばそういうコンピュータ内部の「自然」をランダムネスの供給源できる場合があったりします。

それはＣＰＵの熱雑音だったりするわけです。CPU によってはそういう熱雑音を利用するハードウェア乱数生成器を持っていたりします。で、こういうハードウェア乱数生成器に対するドライバがもうすでに Linux などは備えているわけです（まあ、そういうＣＰＵを使っていれば...ですが）。

何か「コンピュータと自然」というような深いテーマですね。面白くなって調べてしまいました！

最近目にするようになったのが、コレですね。

で、どういうものか少し調べましたが、要するに、

URLを ID として、ユーザ認証をするプロトコル

 というあたりが正確なようです。勿論 OpenID サービスを実装した認証サーバも立ち上がってますから、それを使って試すこともできますが、自前で認証サーバを立ち上げることだって問題はないようです。

メリットは言うまでもなく、「アカウント：パスワードのペアをただ一箇所で管理できる」ということです。まあ、LDAP とか、それこそ Kerberos とか、イントラネット向きのそういう技術っていろいろあるのですが、Web 系の「誰でも利用できるサービスで、それでも個人を特定したい場合」というのはいろいろあるわけです。そういうニッチにうまくハマるのかなぁ？などとも思います。

まあ、そういうニッチにハマって強烈に普及した技術では Captcha がありますが、これだって一種の認証サービスだと言えばそうかもしれません（「人間」であることを認証する....苦笑）。

この OpenID も何か面白い使い方とかそのうち考えてみよう...

参考：＠ＩＴ「OpenIDが熱狂的に受け入れられる理由」
　　　OpenID.ne.jp

さて、Meyer ネタです。このところ遊びで書いているプログラムに、わりと真面目に XP 風の Test First を実践してみよう....ということをしてみましたが、これ結構イケますね。で、考えたことですが、「こういうTest Firstって、そういえば Meyer の契約主導設計に結構近いものが？？」という問題なのですね。

で調べてみると、ちょうどいいメーリングリストの投稿がありました。

 > 　私もこの点が気になってJPLoPの友野さんにお聞きしたのですが、XPでいう
> テストはMeyerの契約主導設計の実現の一種であるというお話でした。「表
> 明」というのでしょうか。「表明」は「こうなっているべきだ」というのを事
> 前条件、事後条件、不変条件で通常そのプログラムの内部で記述するものです
> (というのは平鍋さんのほうが詳しいと思います)が、それを外側にもってきた
> のが、XPのテストということでしょうか。

私の最近の頭の中では，

   Meyer の表明
       "Built-in Test", "Test Inside Code", "Testing-in Strategy"

   XP の Unit Test
       "Built-out Test", "Test Outside Code", "Testing-out Strategy"

など分類されています．このような分類で，テストを考えている他
の文献等ありませんかね?

やっぱり同じような感想を持つ方がいるようです。確かに「Meyer 的表明＝内部に埋めこまれたXP的テスト」、「XP的テストファースト＝契約主導設計の変形」というような等式が成り立つのかも？ということなのですね。

そう考えてみると、やはり Meyer の「オブジェクト指向入門」はやはりかなり強烈に時代を先取りしていた本だったのかもしれません。たとえば、Annotation で書いた表明記述から、XP のテストクラスを自動で変換しちゃうとか、そういうものもありそうな...

これは遊びで書いているプログラムで出た問題です。

要するにブログのコメントなんかに対するサニタイザです。この時に、「存在していいタグ」を指定して、許可されたタグだけはそのままで、それ以外のタグはエスケープする、という処理がありますよね。まあ、一般に「許されるタグ」は単純に属性なしでそれなりの動作をするタグがほとんどです。

とはいえ、このサニタイザ仕様に対して、「属性を許可したり、特定の属性を排除したり...」という指定を与えるのはどうすればいいのでしょうか？ タグ名だけならば、当然タグ名の列挙で充分なのですが、たとえば、

a タグに対して、href 属性と name 属性、target 属性はあっていい。しかし、onclick 属性など内部に JavaScript の書ける属性は禁止だし、href 属性でも

<a href="javascript:window.localtion.href=.....">リンクだよん</a>

のように、javascript URI を指定している場合は禁止にしたい...

というような、結構ゼータクなことをしたい、ということを考えて見ましょう。この指定をデータとしてどう記述するのでしょう？？？

これ、やはり「似た公的規格」を準用するのがいいのでは...と思いませんか。というわけで、私は XPath 風にこれを書くのがいいんじゃないか..と思って、その方向での実装をしていきました。たとえば、上記の例だと、とりあえずこんな感じでしょうか。

禁止指定： a[@href="javascript:*"]
許可指定： a[@href] a[@target] a[@name]

擬似コードで書いた動作はこんなところです（単純化のために、複数の属性がある場合などは略です）。

function needSanitize( tag ) {
  if( tag.match( 禁止指定 ) { return 禁止; }
  if( tag.match( 許可指定 ) { return 許可; }
  return 禁止;
}

で、「禁止・許可の指定のために XPath モドキで指定する」ということですから、たとえば本当は JavaScript URI のチェックは、XPath 関数を使って、

starts-with(a[@href], 'javascript:')

とでも書くべきではあるのでしょうが、簡潔さで以上のような XPath 外のワイルドカード指定みたいなことにしました。「すべての属性は不可だが、属性のない b タグは許可」という指定ならば、

禁止指定： b[@*]
許可指定： b

みたいに実現できればいいように思います。これは XPath にちゃんとある書き方ですね。とはいえ、

禁止指定： b[@on*]
許可指定： b b[@*]

で onclick などの JavaScript が書ける属性のみ不可、とする場合には、属性名に対する先頭一致の感覚で書いている on* は、XPath の規格外になります（というか、正確には「on*」という名前の属性と一致するようですから、規格「内」なんですけどね）。

まあ、こんな風に「別に XPath じゃないけども、見た目を XPath に合わせてやる」というのも、実装仕様としては、もう大丈夫ではないか...とも思います。ちょっと調べてみると、ネット上で配布しているものでは「Webサイトの更新時刻取得エージェント」である「五月雨」が、更新判定から除外すべき部分を XPath 風に指定する、というのがあったりします。今回のものなんか、Well-formed な XMLであること自体がまったく期待できないコメントなので、ちゃんとした XPath ライブラリにお願いすることがそもそも無理だったのですが、そういう風な「見かけだけ」なXPath モドキというものも、「コミュニケーションという問題」で有用なのかもしれません。たとえば、もうすでに、

//web-app/servlet/servlet-name

くらいまでは一般に多分許容範囲ではないでしょうか。