DIARY - 2004.06

06/29 - boost::program_optionsが夏を知らせる

七月に予定されているboost 1.32の目玉はboost::program_optionsではないでしょうか。このライブラリは、コマンドラインオプションの解析を行うためのものです。今時、コマンドラインから実行するプログラムなんて作らない、なんて方もいるでしょう。しかし、INIファイルの構文解析器もいっしょについてくるとしたらどうでしょう? そして、それらが統一されたインタフェースで扱えるとしたら? そう、きっと素晴らしい夏が始まるに違いありません。

あなたがしーぷるぷるだとしたら、どのようにしてプログラムに設定情報を与えてきましたか? GNU Gengetoptを使った、XMLで書いてDOMまたはSAXで読み込んだ、自分でファイル形式を定めて解析器を作った(boost::spiritを使って!)、あるいは別のなにか(たとえば、FLTKは、レジストリっぽい設定の読み書きインタフェースを提供しています)。それらが悪いと言っているわけではありません。実際、上に挙げた例はすべて私が試した事柄です。状況によって、使い分けるのが賢いでしょう。しかし、忘れないでください。GNU GengetoptはCのためのものだし、しーぷるぷるではXMLライブラリはあまり気軽に使えないし(MiXというライブラリはそれを改善しますが)、boost::spiritはあまりに変態だし、コマンドラインのプログラムを作るのにFLTKをリンクしたらやりすぎです。

さて、問題がひとつ。六月の現時点ではboost 1.32はリリースされていません。どうしてもboost::program_optionsが使いたくなったら、どうすれば良いのでしょう? そうです。tarボールがなければ、CVSを使えばいいじゃない、というわけです。ただし、他のライブラリがうまくビルドできない場合があるので(たとえば、MacOS Xではboost::thread関連等がビルドできません)、boost::program_optionsだけビルドしてインストールする必要があるかもしれません。

以上の文章を書くにあたって、参考にした[Boost-users]のスレッドは、06888, 06889, 06890, 06896, 06900です。

06/29 - MSN Messengerの暗号化 (5)

前回、適切な通信方式はふたつ存在すると書きました。煎じつめるとこの問題は、誰を信用するのかという問題、暗号化された通信を運用するためにどれくらいのコストがかかるのかという問題が関わってきます。しかし、それはさておいて、ふたつの方式について考察します。

まず、ひとつめの方式は、ユーザとIM Serverの間の通信を暗号化するというものです。この方式を採用した場合の、ボブとアリスの会話の例を見てみましょう。

  1. ボブはパソコンに、「明日、デートしない?」というアリス宛のメッセージを入力します。
  2. ボブのパソコンは、アリス宛のメッセージをIM Serverにしか読めないように暗号化して、IM Serverに暗号化されたメッセージを送信します。
  3. IM Serverは、暗号化されたメッセージを復号して、「明日、デートしない?」という元のアリス宛のメッセージに戻します。
  4. IM Serverは、 アリス宛のメッセージをアリスにしか読めないように暗号化して、アリスのパソコンに暗号化されたメッセージを送信します。
  5. アリスのパソコンは、暗号化されたメッセージを復号して、「明日、デートをしない?」というメッセージを表示します。

この場合、ボブのパソコンからIM Serverに送られるデータは暗号文になっているので、盗聴しているイヴには読めません。さて、この方式の利害得失はなんでしょう?

良い点は、IM Serverが信用できると仮定するならば、暗号化にまつわる面倒くさいいろいろを、すべてIM Serverに押し付けることができる点です(言うまでもなく、世の中にこの手の技術が普及していない最大の理由は面倒くさいからです!)。 そしてまた、IM ServerとIMソフトウェアの開発者は同一であることが多く、ユーザに統一されたインタフェースを提供することができる、つまり、暗号うんぬんのややこしい操作をうまく隠すことができるかもしれません。

悪い点は、良い点の裏返しです。IM Serverは信用できるとは限りません。いやいや、その前に信用できる、信用できないというのはいったいどういうことなのでしょう?

ここで驚愕の事実が発覚します。なんと、IM Serverを運営している会社の社長トレントはイヴの父親だったのです(もちろん、裏社会での仇名はマロリーです)。そして、トレントは娘に激甘だったので、実はIM Serverの管理者権限を娘に与えていたのです!

この場合(イヴはわざわざ盗聴する必要はありませんが、そこはフクザツな乙女心だと思ってください)、ユーザとIM Serverの間の通信が暗号化されていてもなんの意味もありません。だって、IM Serverでは暗号化されたメッセージが復号化されていて、イヴはそれを覗き見することができるのですから。

このような事態では、ボブにはいったいどんな手段が残されているでしょう? 次回はふたつめの通信方式について述べます。

06/18 - MacOS XでVTKをビルドするために

VTK (The Visualization Toolkit)は、BSDライクなライセンスのコンピュータグラフィックス、画像処理、可視化のためのオープンソースソフトウェアシステムです。どのような機能があるかについては、What Is VTK?にまとめられています。カリカリに最適化されたコードを書きたい場合にはお勧めしませんが、簡単なツールを作りたいときにはお勧めです。MacOS XでVTKをビルドする場合、いくつか注意するべきことがあります。

  1. cmakeをダウンロードしてインストールしておきましょう。
  2. システムのzlibを使ってビルドするように設定しましょう。
  3. gcc 3.3ではRendering/vtkCarbonRenderWindowInteractor.cxxのコンパイルが通らないので、すこし編集する必要があります。

一番最初のcmakeのインストールは簡単です。cmakeの配布ページから、OSX用のバイナリをダウンロードするだけです。cmakeはビルド用のツールで、VTKはこれを用いてビルドすることになります。具体的には、コマンドラインで以下を実行します。

> cmake -i

沢山の設定項目について質問されます。ほとんどはデフォルトのままで良いでしょう。しかし、USE_SYSTEM_ZLIBの質問については「ON」と答える必要があります。これらについては、VTKのメーリングリストで解説されています。(071736, 071741, 071746)

最後に、Carbonを使ってコンパイルするように設定した場合、ソースコードをすこし編集してやる必要があります。VTK 4.2(最新版)では、Rendering/vtkCarbonRenderWindowInteractor.cxxの188行め、196行め、204行めが、

(int)charCode,1,&((char)charCode));

のようになっていると思います。このままでは左辺値がどうこうとコンパイラに叱られるので、

(int)charCode,1,(char*)(&charCode));

のように書き換えてあげればよいでしょう。

06/15 - MSN Messengerの暗号化 (4)

前回出てきた定理を裏返してみましょう。「暗号化されていないデータは盗聴される(かもしれない)」の裏は、「暗号化されたデータは盗聴されない(といいなあ)」です。これは真でしょうか?

適切な通信方式と、適切な暗号化方式を用いた場合、データが盗聴される可能性は、実用上、充分安全な程度まで下げることができるとされています。(よく誤解されることですが、数学の達人でない限り、公知の暗号化方式を用いたほうが安全です。現代の良い暗号とは、暗号化の方式が判っていても解くことが難しい暗号のことを言います)

さて、ボブの物語に戻りましょう。ボブがやるべきことは、アリスにしか解読できないように暗号化したメッセージを送ることです。そうすれば、イヴが盗聴していても、イヴが手に入れられるのは暗号化されてぐちゃぐちゃになったデータだけです。暗号化のやりかたとして、共有鍵暗号とか公開鍵暗号と呼ばれるものがありますが、それらは数学的にややこしいので(どれくらいややこしいかというと、ルートとか虚数とかよりややこしいのです!)ここでは触れないことにしましょう。とにかくそういう適切な暗号化方式があってそれを使うわけです。

それでは、ボブの物語でデータのやりとりを説明してみましょう。と、いきたいところですが、ことはそう簡単には進みません。ふたつめの段落の冒頭に「適切な通信方式と、適切な暗号化方式を用いた場合」と但し書きがついていたことを思いだしてください。ボブは暗号化したメッセージを送る前に、適切な通信方式についても考察しなければならないのです。

適切な通信方式は、この物語では大雑把にふたつ存在します。次回はそれについて考察します。