DIARY - 2004.07

07/27 - Koening Lookupの昏闇で

Koening Lookupのなんたるかを知っていて、boostとvecmath-c++を使っているすべての同志にこの文書を捧げましょう。おそらく、そんな人間は世界全部合わせても両手の指で足りるくらいしかいませんが。

さて、vecmath-c++は、JAVA 3DのvecmathライブラリをC++に移植したもので、以下のように標準ストリームに出力することができます。

#include <iostream>
#include <vecmath.h>

int main(int, char*[]) {
    kh_vecmath::Vector3f vector(1, 0, 0);
    std::cout << vector << std::endl;
    return 0;
}

いつでも罠は口を開いて私たちを待っています。

#include <boost/test/test_tools.hpp>
#include <vecmath.h>

int test_main(int, char*[]) {
    kh_vecmath::Vector3f vector0(1, 0, 0);
    kh_vecmath::Vector3f vector1(0, 1, 0);
    BOOST_CHECK_EQUAL(vector0, vector1);
    return 0;
}

標準に準拠したコンパイラでは、このふたつめのコードはコンパイルできません。なぜなら、BOOST_CHECK_EQUALマクロは、内部的にvector0とvector1をストリームに書き出すからです。

なぜなら、が、理由の説明になっていないと思われるかもしれません。しかし、次のコードを見れば、理由をご理解いただけるでしょう。以下は、グローバル名前空間に定義されています。

template <class T>
std::ostream& operator<<(
        std::ostream& o, const kh_vecmath::Vector3<T>& t1)
{
    return o << "(" << t1.x
             << "," << t1.y
             << "," << t1.z
             << ")" << std::endl;
}

その通りです。Koening Lookupで関数を発見するためには、引数のクラス（この場合はVector3<T>）の属する名前空間（この場合はkh_vecmath）で、関数が定義されていなければいけません。

この問題を解決するためのパッチを用意しました。川地氏による機能拡張パッチを適用した後に適用してください。

07/05 - MSN Messengerの暗号化 (7)

私が余暇を利用して作成しようとしているプログラムのひとつは、MSN Messengerの暗号化を行うためのツールです。このプログラムは、いくつかの要件を満たしているべきだと考えます。

安全であること。ボブがアリスにふられたことを、イヴに盗聴されないくらいに安全であること。
簡単であること。最低でも、インストーラをクリックするだけでインストールできること。

この問題のひとつの回答として、SpyShieldというプログラムがあるようです。GnuPGと連携して暗号化を行うようですが、見る限り、安全ではあっても、簡単であるとはとても思えません。それに、Microsoft Windows用のバイナリしか配布されていないので、MacOSユーザはとても疎外されていると言えるでしょう（あるいは、GNU/Linux SystemsやSolarisや、そのほかもろもろのOSで、MSN Messenger互換なソフトウェアを使っているひとびともまた）。

私は、別の回答を考えています。SpyShieldはMSN Messengerのプラグインとして働きますが、私が考えているプログラムは、ローカルなプロクシ（あるいはパケットリピータ）として働くことで、問題のいくつかを解決します。また、MSN Messengerにおける認証それ自体はMD5を利用した（まあまあ安全な）ものであることを利用して、PGPの面倒くささから、逃れられるのではないかと考えています。

最後になりましたが、アリス、ボブ、イヴ（それにトレントとマロリー）という登場人物は『暗号技術大全』からの引用であることを言明しておきます。

07/04 - MSN Messengerの暗号化 (6)

ふたつめの通信方式は、ユーザ同士の間の通信を暗号化するというものです。とても素直な方式だと言えるでしょう。前回説明した方式とは違って、IM Serverは暗号化されたメッセージを復号化しません。つまり、イヴがIM Serverの管理者権限を持っていたとしても、ボブがアリスに送ったメッセージを覗き見することはできなくなります。この方式の良い点と悪い点について考えてみましょう。

良い点は、ふたりのユーザ以外の誰も、メッセージを読むことができないというところです。ほかの誰かを信用することなしに、安全にメッセージをやりとりすることができるのです（IM Serverが信用できない場合があることを思い出してください）。そもそも、馬車馬の眼を抜く現代社会で、誰かを信用することはとても難しいことだと思いませんか？　そして、IM Serverをまったく変更せずに、新しい暗号化方式を追加することができます。これは、独立系の開発者にとって大きな魅力かもしれません。なにしろ、この業界ではMSN Messengerが支配的なプラットフォームとなっているのですから。

悪い点は、さて、なんでしょう？　おそらく最大のものは、面倒くささでしょう。通信を暗号化するために、ユーザはいろいろと設定したりしなければなりません（第一の通信方式はHTTPSを用いて容易に実現できると想像されます。第二の通信方式を素直に実装するとPGPを使う羽目になります。そして、PGPのユーザインタフェースはお世辞にも面倒くさくないとは言えませんよね？）。思いだしてください。一般のユーザはソフトウェアのインストールさえ面倒くさがるものなのです！

こうして、ようやく（あしかけ三ヶ月もかけて）、私はなにを作るべきか、という戦略にたどりつきました。次回はその設計方針を述べて、だらだらと続いた文章の結びとする予定です。