いやぁ， 年末年始に実家に帰らないといろいろできていいなぁ。 来年も帰るまぁか。
GnuPG 用に Win32 クロス環境を構築してみる。 まずは ftp://ftp.gnupg.org/people/werner/cpd/ から以下のファイルを GET！
root に su して /usr/local/src 上で上記ファイルを展開し， mingw32-cpd-0.3.1/ へ移動する。 あとは ./Configure および make install で勝手にビルドしてくれる。 簡単でよかった。 なお Vine Linux の場合デフォルトでは /usr/local/bin にはパスが通っていないようなので追加してやる必要があるようだ。 確か最新の gcc は 3.2 の筈だが， 他にクロス環境が見当たらなかったので 2.95.2 でもいいか。 そもそも Vine Linux ネイティブの gcc からして 2.95.3 だし。
個人的には SH 用のクロスコンパイラなんかも使ってみたいところだけど (昔，純正の SH コンパイラを調査してレポートを書いたことがある。 もちろん社外秘) いずれまた。 Intel のチップってアセンブリックなレベルでの面白みに欠ける (苦労ばかり多かりき) のがイマイチ。 そういや 『Interface』 2002年7月号の特集は面白かったな。 「gcc はマニアック」 という先入観が強化されてしまったが。(^^;)
(脱線ゴメン) で， このクロス環境で早速 GnuPG 1.2.1 と GPGME をビルドしてみる。 GnuPG 1.2.1 は問題なし。 GPGME は ./configure で 「クロス環境なんかじゃテストプログラムが動かんわ，ボケぇ！」(※ 英語不得手なのでかなり意訳) と怒られてしまった。 怒られた箇所をバイパスしようと中を覗いてみたが簡単には行きそうもないので取り敢えず諦めた。 OpenCDK は取り敢えず保留。
ところで GPGME が GnuPG に依存するのは当然だが， 最近のバージョンは GPGSM にも依存しているようだ。 GPGSM は GPGME と同じく例のドイツ政府が採用した Agypten プロジェクトの成果物で， なんと S/MIME を実装しているらしい。 う〜ん， 気になる。
結城浩さんが GnuPG 1.2.x に同梱されている README を日本語に訳して公開されている。 素晴らしい！ で， その中にあったプチテクニック。 README はちゃんと読んでおくものだなぁ。
--fingerprint コマンドを2つ並べるとサブ鍵 (主鍵に対する副鍵) の鍵指紋が取得できる。 たとえばこんな感じ。
C:\>gpg --fingerprint --fingerprint spiegel@alles.or.jp
pub 1024D/B46A4F0E 2000-05-25 Yasuhiro ARAKAWA <spiegel@alles.or.jp>
指紋 = B148 233B C512 9165 77FF FD54 D390 BF4C B46A 4F0E
sub 2048g/51927695 2000-05-25
指紋 = 0B9E 089C 5A8F 444E 93FE 6537 D95F 0193 5192 7695
サブ鍵はふつう暗号化に用いるので， 厳密にやるならこっちもちゃんとチェックしないといけないんだよな。
結城浩さんのサイトには他にも色々なコンテンツがある。 Pretty Good Privacy クイズとか。 あっ 「クリエイティブ・コモンズのライセンス解説」 がある。 日記も面白そうなので下のリストに載せておこう。
WideStudio の最新版も導入する。 随分前に一度導入したきり放ったらかしていたのだ。 知らん間に Perl や Ruby や Python までサポートするようになっていて， しかも Windows 版のパッケージにはそれら全ての言語が同梱されている。 パッケージサイズは約65MB。 目眩いのするような量だが何とかダウンロードしましたよ。(来月の請求が恐い)
実は既に ActivePerl を導入していたのだが， 削除して WideStudio の方を有効にした。 Ruby は随分前から気になって一応 『プログラミング Ruby』 とか買ってるんだけど， これまた放ったらかし状態。 これで導入できたわけだからちょっとは触ってみようかな。 昨年はこんなんばっかりだったなぁ。 今年はもう少し余裕のある私生活を送りたい。
Windows 版 WideStudio に同梱されている MinGW はちょっと古くて， gcc のバージョンが 2.95.3 である。 MinGW のサイトから 最新版 (とついでに MSYS) をダウンロードしてサンプルプロジェクトをビルドしてみたが見事に失敗した。 さきは長い。
ところで
WideStudio
では Shift-JIS の扱いについて sjisfix を噛ませることによって問題を回避しているようである。
例えばソースコードに sjisfix を通すと "表示" という文字列を "\x95\\示" に変換してくれる。
余談だが，
sjisfix を引数なしで起動すると例外を吐いてぶっコケるんだけど，
ええんかいな。
「Franco's GNU gettext for WIN32」
試しに Shift-JIS で記述した po ファイルに上記の sjisfix を通すと msgfmt が通るようになるかと思ってやってみたが， 世の中そんなに甘くはなかった。 さきは長い。
もうお仕事を始めておられる方もいらっしゃるようで， 寒い中皆さんご苦労様です。 私も仕事始めまでにできるところは進めておこう。
一年前から考えていたのだが棚上げになっていた企画を実行する。 すなわち 「公開鍵を新調する」 である。 これには思惑が2つあって， ひとつは今の公開鍵の鍵長 (2048bit) が少々心もとない気がしてきたこと。 もうひとつはソフトウェアやドキュメントを公開する際に使う 「署名専用鍵」 を作ることである。 実は2000年に仕事用の鍵と私用の鍵を分けたのだが， 仕事はともかく私生活でデータを暗号化することはほとんどないことに気がついた。 むしろ使うのは電子署名の方である。 ならば 「実印」 的な意味合いを持たせた署名専用鍵を作っておけばいいではないのか。 暗号化に使う鍵はその 「実印」 鍵で署名をしておけば Revoke も気軽にできるし， 有効期限を短く設定することもできる。 (有効期限を短く設定して頻繁に交換すればある鍵でクラックを受けても比較的被害が少なくて済むはずである)
ただ今使ってる公開鍵を廃棄するのはまずい。 何せつい先日拙作をリリースしたばかりである。 これには現在の鍵による署名が添付されている。 そこで原稿の公開鍵の有効期限を今から12ヶ月後に更新し， 一方で新たに署名専用キーを作成することにした。(余談だが， GnuPG のプロジェクトリーダの Werner Koch さんは GnuPG リリース用に使っている署名専用鍵の有効期限を延長している。 アップデートはお早めに) もちろん両鍵はお互いに署名しておく必要がある。
署名専用鍵の方は RSA を用いることにした。 現在 (1.2.1) の GnuPG で署名専用鍵を作ろうとすると DSA と RSA が選択できるが， DSA の鍵長は 1024bit までしか選択できない。 私は RSA 2048bit 鍵を選択することにした。(2048bit 以上も作成可能だが 「長すぎるわ，ボケぇ！」(かなり意訳) と怒られる) 更に有効期限は 2006年1月3日までとした。 作成した鍵は以下のとおり。
pub 2048R/76F72BE7 2003-01-04 Yasuhiro ARAKAWA (sig only) <spiegel@alles.or.jp>
指紋 = 3DBE 60E2 5C36 805F 1C26 A6A1 1B1B 373B 76F7 2BE7
メール等で使う鍵は従来のものを使うので， 今までコミュニケートできている人はそのままで結構です。
なお， 従来の鍵には新たな有効期限と上記鍵による署名を追加して鍵サーバにアップロードしているので 更新していただいてもよい。 本当は OpenPKSD で登録したかったがまだその機能は公開されていないので， MIT PGP Key Server と OpenKeyServer に登録した。(JPNIC の鍵サーバはコケてるみたいなんだけど正月休み？) 同期が完了するまではこれらのサーバから最新鍵を取得できる。
ところで新しい署名専用鍵を MIT PGP Key Server で探すと以下のような表示になる。
pub 2048R/D5E4DC1F 2003/01/04 Yasuhiro ARAKAWA (sig only) <spiegel@alles.or.jp>
Key fingerprint = 55 4B C3 EA 4B BA 6C A3 9C 06 C4 E9 28 C1 49 80
sig 76F72BE7 (Unknown signator, can't be checked)
sig B46A4F0E Yasuhiro ARAKAWA <spiegel@alles.or.jp>
なんと全く違う鍵になってしまった。 いや待て， このフォーマットどっかで見たことあるぞ。 そう， 私が以前散々コケにした NAI の鍵の表示と同じなのだ。 そういやあのとき私は 「何だって今更RSA単独鍵なんか使ってんだろ」 などと書いてしまったが， してみると NAI のあの鍵も署名専用鍵だったのかな。 いや， 申し訳ない。
新たに作った署名専用鍵を pgpdump すると署名専用の RSA (pub 3) ではなく通常の RSA (pub 1) が使われている。 まぁ両者で性能の違いが出るとは思えないが何となく釈然としない。 PGP 2.6.x との互換性を考えているのだろうか。 でもそれならバケットバージョンが V4 である時点で互換性はない筈である。 例えば今回作った鍵を PGP にインポートすると暗号化ができてしまうのだろうか。 それはそれで嫌なんですけど。
同じく pgpdump の内容を見て気がついたが， 確か 1.0.6 くらいまではハッシュ関数のデフォルトは RIPE-MD/160 だったと思ったのだが， 今見ると SHA-1 に戻っている。 あと圧縮アルゴリズムもデフォルトが ZLIB に戻っている。 具体的には以下の順である。
Symmetric algorithms : AES 128-bit, CAST, Triple-DES Hash algorithms : SHA1, RIPEMD160 Compression algorithms : ZLIB, ZIP
ただし実際の処理では ZIP がデフォルトになっているようだ。(リストを無視してる？)
調べてみたらあちこちのドキュメントが移動したり無くなったりしている。 ので， ここで一応整理しておく。 以下のリストは 「わかる! PGP暗号」 の末尾にある参考文献からの差分である。
そのうちサイト内全域を更新する必要があるな。
「数学と計算」 にある各種コンテンツはことごとく私の趣味範囲にクロスオーバする。 ありがたや。
現時点で 「公開鍵方式で最適な鍵長」 ってどのくらいなんだろう。 例えば， NTT が1999年に公開している文書 「次世代暗号として期待される楕円暗号分野で新技術を開発 ―安全性証明付き新方式と世界最速の楕円曲線暗号演算法―」 では RSA 鍵の安全性強度の高い鍵長を 2048-3072bit としているので， 2048bit では既に心もとない感じである。 かといって 4096bit はちょっと長すぎる気がしないでもない。 GnuPG ユーザで鍵長を 4096bit にしている人は多いようだが， 実際に GnuPG で 2048bit 以上の鍵を作ろうとすると警告表示が出る。 「The GNU Privacy Handbook」 では対象鍵暗号が 128bit なので公開鍵暗号の方も 1024bit くらいがいいのではと書いてあるようだ。(英語不得手なので自信なし)
CRYPTREC の報告では， DSA に関しては鍵長が 1024bit なら事実上安全であるとしている。 どちらかというとヤバそうなのはハッシュ関数の方か。
ちなみにGnuPG のプロジェクトリーダの Werner Koch さんの公開鍵の鍵長は 1536bit で， WinPT で鍵を生成する時のデフォルト値は 1792bit である。 どっかの ML に投げて訊いてみようかな。
東風フォントの最新版がリリースされている。 Adobe Japan1-2 の追加漢字 (IBM外字) が追加されているそうだ。 これでほぼ文字落ちはなくなったかな。 ブラボー！
例によっていつも参考にさせてもらっている PGPB2 プラグインで使われているフリーの C++ ライブラリらしい。 ザッと見た感じかなり便利そうである。 真面目に検討してみようかな。
「情報コミュニケーション III E ,アルゴリズムとプログラミング」
京都女子大学の小波秀雄教授が教材として公開しておられるテキスト。 初心に返って読んでみるか。
1/5 の記事より (バーチャルネット法律娘 真紀奈17歳)
こんなやり方では 「国内ソフト産業の競争力強化に役立」 ちません。 なんで米国の悪いところばっかり見習うかなぁ。 著作権保護期間もそのうち120年とか言い出すに違いない。
実際， 特許や著作権関連の係争にかかるコスト (お金だけじゃなく時間も) はバカにならない。 しかし大企業であればそういう問題について調査・調停するセクションがちゃんとある。 つまりそういうトラブルを見越してあらかじめ経費として計上しているのだ。(最近は景気悪いからどうか知らないが) 今回の案は原告-被告間のコスト配分が変わっただけで (コスト面からだけ見れば) 損にも得にもならない。 じゃあ何故このような提案が出てくるのか。 それはもちろん競争相手のビジネスチャンスを (競争以外の方法で) 潰すためなのである。 だからこれは 「国内ソフト産業の競争力強化に役立」 たないのだ。
しかし企業同士， それも大企業同士の係争ならこの程度で済むかもしれないが， ギリギリのコストで制作・開発を行う (SOHO を含めた) 中小企業や個人にとっては死活問題となる。 考えても見よ。 ある日突然 「貴方の発表したコンテンツ (もしくは製品) は私どもの保有する著作権を侵害しています」 と言われたとき， 果たしてそうじゃないと立証することが出来るのか。 もし出来るとしても立証できるまでの間に仮差し止めでも食らった日にゃ， その損害は量で (つまりお金で) 評価できないほど甚大である。
今の時代， 殆どの著作物は他の著作物を流用・援用することで成り立っている。 今回の案はこの事実を完全に無視している。 そのうち鼻歌をうたうだけでカードから料金が引き落とされたり， コースターに書いた洒落た落書きに対して告訴されたりする日が来るのかもしれない。
上記の真紀奈さんの記事では 「登録制にすれば」 という話もあるが， 大企業は既にその手のデータベースを自前で構築しているのに比べ， 私達個人は完全に丸腰である。 登録制にしたところで検索するためのコストは原理的に減らないし， 減らすための画期的なロジックが開発されたとしてもそれを採用してくれるかどうかは別問題だ。 (意図的にコストのかかるやり方を強要することだって出来るのだから) そもそもこれから唄う 「鼻歌」 やこれから書く 「落書き」 が著作権に反するかどうかあらかじめ調べる奴などいない。 係争のかかるコストを原告側が払うのには (つまり商業上の規制が存在することには) ちゃんと理由があるのだ。
日本語による情報：
結城浩さんのサイトのコンテンツはクリエイティブ・コモンズ表記のサンプルとしても参考になる。 仕事の合間につらつら読んで見たが現実的な構成で個人でも使いやすいように見えた。 また当面ソフトウェアライセンスについては関与しないそうだ。(GPL/GPL2を使いなさいってことかな)
さすがに社外秘の内容をコモンズに置くわけにはいかない (つか，そもそも公開できない) が， 雑文置き場にあるような内容なら Attribution (帰属) ライセンスで公開してもかまわないんだろうな。 私の文章って半分くらい PDF (もっと言えば SmartDoc) なんだけど， どうしようかな。
(「バーチャルネット法律娘 真紀奈17歳」 より)
「勝手につける『コモンズ』への解説」 なんてのがあるらしい。 明日の昼飯時にでも読むか。
「ヤマトタケル」の話。 まぁ確かに荒唐無稽なストーリーだが， それを言うなら 「ヤマタノオロチ退治」 自体記紀によって 「作られた」 話であることを忘れちゃいけない。 一般に 「ヤマタノオロチ退治」 は出雲神話だといわれているけど， 実は出雲風土記には 「ヤマタノオロチ退治」 なんて話は *全く* 出てこない。(故に 「ヤマタノオロチが斐伊川の擬人化である」 という説明は全く説得力を持たない) それどころかスサノオ神 (出雲風土記ではこう呼ばれる) そのものが出雲風土記ではマイナーな存在なのだ。 もちろんこれは (スサノオ神の負っている性格から考えても) 政治的な意図によるものだ。 (出雲風土記は他の風土記とは大きく性格を異にする。 ぶっちゃけて言ってしまえば風土記編纂者 (＝出雲国造) が自らの権力と権威を内外に知らしめる目的で作られている) 神話は (特に日本の神話は) その時々の為政者によって常に 「作られる」 ものなのだ。 そういう意味では勝手にストーリーをねじ曲げた 「ヤマトタケル」 は実はかなり意味深であるともいえる。(制作側がそこまで意識して作ってるとは思えんが)
「Xbox暗号解読プロジェクト、「Project X」として再開へ」
最近の相次ぐ無罪判決に気を良くしたのかな。 結構なことである。 堅牢な城に対しては地道に外堀から埋めていくのが兵法の常套。
先日の話の続き。 私の素朴な疑問を某MLに投げたところ， ありがたいことにアドバイスを頂いた。
あれ？ これ紹介したことなかったっけ。 随分前に買ったんだが， ちょっとだけ斜め読みしてそのまま本棚の飾りと化してたからなぁ。 実はこの本の中に鍵長について検討している節があったのだ。 (指摘してくださった方， ありがとうございます)
問題の部分は第4章の p.115-118 あたり。 予算1,000万ドルで暗号の解読をする場合に解読マシンの構成と解読時間がどの程度になるかというものだ。 詳しい内容は本を見ていただくとして， RSA 760ビットの鍵の場合4,300台のマシンを調達して約50年かかるという結果が出ている。 なお，鍵長が長くなるほど調達できるマシンの数が減ってしまう。 これは解読により多くのメモリ容量が必要になるためコストが割高になるかららしい。 つまり1620ビットでは (1,000万ドルの予算内で) マシンを調達できない計算だ。
これは2000年4月に公開されたデータだそうで， 今ではマシンの性能や価格はかなり変わっているので上記の値は少し控え目に見ておいた方がいいかもしれない。 あと1,000万ドルの予算を安いと見るか高いと見るかだよな。 まぁ個人の通常用途なら上記の条件で50年間秘密にできるのなら充分実用に耐えるだろう。 ちなみに上記のデータが CryptoBytes にないかと探してみたが， 何故か2000-2001年の間がすっぽり抜け落ちている。 何かあったのか？ 不安になったので今公開されている PDF 文書を全部ダウンロードしておくことにした。
ちなみにこの本はとても良くできていてお薦めなのだが， RSAセキュリティ社のオフィシャルガイドであることをお忘れなく。 その辺バイアスをかけて読まないとね。
そういえば似たような話は SETI@home にもある。 SETI@home プロジェクトでは非常に計算集約的な処理が要求されるのだが， 正式に開始された4年前に比べると CPU パワーは飛躍的に伸びていてマルチプロセッサ構成のマシンもその気になれば個人で買えなくもないところに来ている。 しかし， 体感的には CPU パワーの向上に比べて演算自体のパフォーマンスはあまり上がっていない感じである。 (実際にはより計算負荷をかけるように途中でクライアントソフトが変更されたのだが， それは今回無視する)
あちこちの BBS の話を聞きかじるに， どうもボトルネックになっているのはメモリアクセスのようである。 メモリアクセス， 特にメモリキャッシュの性能が全体の演算のパフォーマンスに影響することはプロジェクト開始当初から指摘されていたが， CPU パワーが上がれば上がるほどそれが目立ってきている印象である。 もちろんチップメーカだってただ手をこまねいているわけではない。 Hyper-Threading 技術などはひとつの解答である。 まぁ現時点ではまだ劇的に効いてるわけではないようだが。 ロジックにも特別な最適化が必要になるしね。 (→ 「Hyper-Threading Technology 短評 (たるさん的三位一体説)」)
更に最近の CPU では電源容量 (特に突入電流) や熱の問題も深刻化しているようだ。 熱はともかくパソコンごときで突入電流を気にしなければならなくなるとは凄い時代になってきたものである。 ムーアの法則はこの辺でそろそろ頭打ちにしていただいて， システム全体の安定化や効率化について真剣に考えていただきたいものである。
「初夢コラム(鬼笑い予想編)」 (たるさんのパソコンフィールド)
上記を踏まえて考えるとこの 「鬼笑い予想」 も案外的を射ている気がする。 演算能力は単に CPU パワーで決まるものではない。 システム全体のバランスに激しく依存する。 今より高いスペックを求めるなら個人でそれを構築していくのは難しくなっていくのかもしれない。 更に...
実はマスコミがよく取り上げる 「ユビキタス」 構想 (というかむしろキャンペーンというべきかもしれないが) には落とし穴がある。 一般に 「ユビキタス」 とは身の回りに遍くコンピュータが存在している状態を指すらしいが (そう説明されているが)， 企業等が実際に目指しているのはそんなものではなく 「コンピュータによってより完璧にコントロールされている状態」 である。 その結果として 「ユビキタス」 状態になるに過ぎない。 人間が側にいるコンピュータを使って仮想空間にアクセスするのではなく， コンピュータが側にいる人間を使って現実空間にアクセスするのである。(SFっぽい，コンピュータが自我を持つとかそういう話ではない。 念のため) その場合， 結果的に情報が一局に集中する上記の 「ユビキタス・ネットワーキング」 は実に都合のいい構成といえるだろう。
暗号鍵の話からかなり外れてしまったな (^^;)
MinGW の最新版を入れてみた。
これでもう一度 WideStudio からコンパイルを試みるが， やはりダメ。 g++ は 3.0 から OSI C++ に準拠するためにかなり変更されているらしいので， その影響かもしれない。 取りあえず現象のみサポートMLに報告して， すっぱり諦める (設定を元に戻す) ことにした。
その代わりに gcc Developer Station を導入してみる。 この開発環境は今は The Garage of Choro からダウンロードできるらしい。 で， この環境から gcc 3.2.1 を呼び出せるようにセットアップした。 ざっと眺めてみた感じ適当にコンパクトで扱いやすい印象である。 この構成で本当にうまくいくかどうか分からないが， 当面これで調査を進める予定。
以前 gettext で失敗した件だが， -c (または --check) オプションつきで起動すればいいことが分かった。 すなわち sjisfix でコードを置き換えた後
C:\>msgfmt -c -o gnupg.mo ja_sjis.po
とすればいい。 試したところ GnuPG の ja.po も問題なくシフトJIS化できた。 ブラボー！
ところで gettext だが， MinGW packages repository で 0.10.40 を見つける。 このサイトには他にも色々 Win32 向けにポーティングしたものが公開されているのでお薦めかも。
例の Project X の話 だが， 日本の法律下での参加は無理のような気がする。 1999年に改正された著作権法の言う 「技術的保護手段の回避」 に相当するかもしれないからだ。 こいつは DMCA よりさらに質が悪く， 一切の例外を認めていない。 研究目的でもアウトである。 参考：
実際のところはどうなのだろう。 この辺を某BBSに投げてみた。
(1/16 追記： 今回の場合， 対象となる鍵はシステムそのものをロックするものであり， システムへのクラックが著作権侵害に結びつくとは考えられない， との回答をいただきました)
「共通鍵ブロック暗号の選択／設計／評価に関するドキュメント」 (PDF)
通信・放送機構／横浜リサーチセンター ホームページで公開されているドキュメント。 こいつぁ凄いぜ。 日本語のドキュメントで暗号についてここまで網羅的に書かれているものはなかなかないだろう。 この中の2.6章に公開鍵の鍵長について言及があり， RSA鍵と対称鍵ブロック暗号の鍵長とを対比させることによって強度を示している。 これによると1024ビットのRSA鍵は72ビットの対称鍵ブロック暗号に， 2048ビットのRSA鍵は88ビットの対称鍵ブロック暗号に相当するらしい。 実は72ビット対称鍵については現在 RC5-72 が進行中である。 この辺の動向をチェックしていくことでコンピュータのスペックに対する鍵の強度を推定できるかもしれない。
「フリーソフトに対抗、各国政府にWindowsソースコード開示」
これは効果としていかがなモノか。 ソースコードがオープンであることのメリットは， そのコードを元に自分用にカスタマイズし fork できることだ。 「見られる」 だけでは意味がない。 もしもコード中に致命的な問題を発見しても自分で修正して適用することはできないのである。 そもそも公開されたソースコードが実際に稼働しているソフトウェアと同一である保証はないしね。 政府向けで考えるなら開示されたソースコードをもとに fork する許可 (fork 自体は組織内部のみの使用に留め非公開にしてもいいと思うが) も含めないと実質的に使い物にならないだろう。
PGP 8.0 も同様な戦略をとっている。(MS よりは少し寛容) 感情的には分からなくもないが， ユーザにとって本当に意味ある 「公開」 かどうかは甚だ疑問である。
WinXPで動かすときのライセンス問題： [Apache-Users 2303]， [Apache-Users 2304]
Microsoft のここが嫌い。 この高価でかつ面倒臭いライセンスの仕組み自体をどうにかしない限り MS に明日はない。 少なくともサーバ用途では MS 製品はコストに見あわないと思う。 サーバはとっとと Linux なりに移行して Windows はひたすらネットワーク端末に徹するのが吉かと。 (逆に私は今だに Linux をデスクトップとして使う気にならない)
計算機暗号屋日記 (1/17) で指摘されてしまった。 リンクの間違いは単純に Copy & Past 操作のミスです。 ゴメンなさい。
これです， これ。 探してたのは。 そっか， Bulletins を探せばよかったのか。 ありがとうございます。 うっ， 英語だ。 何とか読めそうだけど。
このネタで4回も続けてしまった。 忘れないうちにどっかに纏めておこう。
ここってどのくらいの人が見てるんだろ。 ここにはアクセスログとか見せてもらえるサービスはないのでさっぱり分からん。 いくつかのアンテナでチェックされてるらしいことは知ってるんだが。 どっかの Web バグサービスを仕掛ける方法もあるんだけど， あまりにもえげつないし， 気にするだけムダかな。 辺境だし， ここ。
これってサイト側を直せば済む問題じゃないような気が。 アクセス制限をかけてるサイトへ誘導するようにすれば誰でも簡単にクラッシャーメールが送れるわけだ。 もうHTMLメールは止めようよ。 昔は私も寛大だったが， 現時点ではベネフィットよりリスクの方がずっと大きい。
「悪質な電話関係の「利用した覚えのない請求」が横行しています − 有料情報料、ツーショットダイヤル情報料など−」
ぶはははは！ いやぁ， 国民生活センターにも督促が行きましたか。 面白すぎ。 いや， 実際のところシャレになってないので皆さんお気をつけを。
もしここに書かれていることを開発の現場がやっていないのだとしたら大問題。 普通ちゃんと試してから判断するだろう？ それがプログラマの 「性」 だと思うのだが。
実は問題はユーザ側にある。 営業マンの提案を鵜呑みにプロジェクトを立ち上げてしまうユーザ。 あるいはマッチポンプな企業広告を本気にしてしまうユーザだ。 当然プログラミングの知識などあるわけないので判断のしようがない。
ユーザサイドで検証しろというわけにはいかないが， 開発会社やメーカに物証を提出させることはできる。 大規模プロジェクトなら検証にもそれなりのコスト (お金と時間の両方) が必要だ。 そして物証を基にリスクとコストについてとことん議論すべき。 それが本当の意味の 「打ち合わせ／ミーティング」 だろう。 いや， 最近ブリーフィングやレビュー以上の 「打ち合わせ」 をした覚えがないので欲求不満が...
ところで実験以上のレベルで .NET 技術を使ってるところってあるの？
「Tex使えない奴は研究者失格なわけですが＠研究する人生 」
お気の毒なこって。 研究者じゃなくてよかったな，私。 つか， TeX を 「Tex」 と表記する奴に言われたくない，かな。 十年くらい TeX (厳密には LaTeX だけど) 使ってるけどいまだに極めた気がしない。 一年前に 『LaTeX2e 数式環境』 読んだときは目から鱗が落ちた。 TeX には単なる道具以上の 「思想」 がある。 それが TeX が支持される真の理由だと思うけどね。 ある意味では， 機能と手順をおぼえれば誰でも一定の品質を得られるワープロやスプレッドシートの方が *道具としては* 洗練されてると思う。
うちらの業界でも似たようなことを言う人が多いけど， 特定の道具が使えることがそんなに重要か？ 「弘法は筆を選ばず」 だぜ。(これは何かを成すのに道具は関係ないとかいう精神論じゃないよ。 どんな道具でも使いこなせばそれなりの成果が期待できるということ。 むしろ目的や要求にあわせて道具を使い分けること (そしてその技術) が重要なのだ) MS-Office を使いこなせないなら TeX だって使いこなせないだろう。
まだ日本語環境のセットアップの面倒臭さや MS-Office との互換性の問題はあるが， そろそろ乗り換えてもいい時期じゃないのだろうか。 例えば公官庁や学校・研究機関などが公開するドキュメントを MS-Office の形式から OpenOffice の形式に移行する (またそのような移行を交渉先にも要求する) だけで劇的な変化がおこる筈。 最近の奴は PDF 出力にも対応しているので条件はそろってきているだろう。 OS をオープン指向にするならドキュメントプラットフォームもそれに合わせなきゃ。
あれ？ これ紹介してなかったかな。 かなり良くできてる。 まだ秀丸を凌駕するほどではないので乗り換えるまではしないけど。 今後要チェックだな。 Linux でこういうのないかなぁ。 emacs とか使いたくないんですけど。(結局今でも vi 使ってる私。 Ctrl キーなどとのコンビネーションって使いにくい)
「JIS 改正に関する公開レビューの御案内 - JIS X 0213 改正原案の公開レビュー - 」
何やらまた変えるらしい。 締め切りは 2/15 まで。 あまり頻繁に変えないんで欲しいんですが。 どうやったって不満は出るんだし。 さもなきゃ超漢字みたいに片っ端から詰め込むとかしないと。
それよりも現行システムへの定着にこそ注力して欲しい。 例えば JIS X 0213 を実装しないプラットフォームは政府筋の機関で購入する際に選択の候補から外すとか。
「［なんだか変！］東京ウオッチング「７けた」の郵便番号／東京」
あはははは。 面白いですな，これ。 7桁の郵便番号で得をしたのは郵便関係よりも一般の企業じゃないのかな。 金融・勘定系の顧客管理システムでは郵便番号情報をデータベース化することで情報のチェックや検索がかなり楽になる筈である。 地域を区分けするメッシュがより細かくなるんだから。 鼻先の利権構造にばかり目を奪われていると， もっと大きな構造の変化に気がつかない。
そういえばまた消費税を (それも段階的に) 上げるとかいう話が出てますな。 前の 3% から 5% の変更ですらシステムの変更で大変だったらしいのに， 毎年変更とかなったら昨年のみずほどころの騒ぎじゃなくなるかもな。
DES に続いて MD5 もこれで止どめを刺されるか？ しかし個人的には電子署名等で広く使われている SHA-1 や RIPE/MD-160 の検証をやって欲しい。 ところでこのページ， Opera で見るとレイアウトが崩れてさっぱり読めないんですけど。 普通に text/plain で書いて表示した方がよかったんじゃないのか。
「ネット上の違法オーディオ・ファイルを自動検出 ――JASRACとRIAJが実証実験に成功」
「ASRACとRIAJ、電子透かしを入れた音楽ファイルの 有効性を確認 〜インターネット上の違法MP3ファイル発見と特定に寄与」
烙印 (電子透かし) を押されたコンテンツを求めて 「わるいごはいねがぁ」 とネットをさまよい歩くわけですな。 まぁこいつに噛まれても無病息災にはならないけど。
ところで形体が変わっても検出できるということは 「誤差がありうる」 ということで， 透かしのないデータまで透かしがあると判断する誤検出の可能性があるんじゃないのか？ テキストデータまで対象にするとか言ってるが， どうやるんだ？ 検出したデータがフェアユースの範囲外であるかどうかの判断は？
「著作権侵害ユーザー名を開示せよ、Verizon に命令 」
相変わらず RIAA はジャイアンですな。 んでもってそれを見てうちの RIAJ や JASRAC も 「RIAA 君もやってるんだからボクもいいでしょ」 と駄々をこねるわけだ。 誰かこいつらを止めてくれ！
日本にはプロバイダ責任制限法があるが， 対処を間違うと色々面倒なことになる。 BBS 管理者なども気をつけないと。 法的な話は 「バーチャルネット法律娘 真紀奈17歳」 の 1/22 の記事が参考になる。
「Java搭載Windows出荷の“デッドライン”決まる」
「MS、Java出荷命令に控訴」
私， この件に関してだけは MS を応援させていただきます。 ソフトウェアを巡る数多の訴訟問題がいかにユーザ不在で行われているかという好例。 大事なことは MS でも Sun でもない私達ユーザが不利益を被らない判断を行うことだ。 それは MS JavaVM を保護することでもなく (むしろアンインストールできるようにして欲しい) Sun の Java を強制することでもなく， 両者 (またはそのどちらでもない第3のベンダ) のいずれかを選択する権利を私達ユーザのために保留しておくことだ。 大体 Sun の Java にしたって特に優秀というわけではない。 しょっちゅう穴があいたり砂場の枠が外れたりしてるのに。 すぐにインシデントへの対応をしない MS はもっと悪いけど。
「［WSJ］ Linuxに知的財産権訴訟の懸念」
「Windows/Mac/BSDにも知的財産侵害の懸念？」
Linux などは歴史的にそういった攻撃を何度も受けていて， その辺うまくやってる筈なのであまり心配することもないと思うが， Windows なんかはどうだろうね。 しかし SCO のこの行動でまた日本あたりのバカ企業がよく調べもしないでライセンス料払ったりする可能性もあるので， そっちの方が心配だね。
WinSCP 2.10 登場。 なんと SSH2 で公開鍵認証が使えるようになった。 しかも対称暗号方式で AES が使えるようにもなっている。(今までなかったのだ) 素晴らしい！ Windows を UNIX 系プラットフォームの端末として使うユーザには PuTTY/WinSCP は必携ツールですな。
Becky! 2.05.07 登場。 なんかヤバげな障害が FIX されているので是非アップグレードを！
Nullify のサイトが大きく模様替えしている。 このサイトにある OpenPGP のページはとてもよくまとまっていて分かり易いのでお薦めである。 鍵長についても分かりやすく一覧になっている。 RSA セキュリティ社の Bulletins #13 をそのままコピってるように見えるが大丈夫かいな。
この一覧を見る限り RSA や ElGamal を 3072 以上にするのは無意味なようだ。 もちろん対称暗号について128ビットより大きい鍵長を常用するようになれば状況は変わると思うが。
あっ， 山根信二さんの近況ページ復活。
IPA Winter で OpenPKSD の成果展示があるらしい。 確かに画期的かも。 以後の政策に多少なりとも生かされるならば， だけど。
「電子自治体のシステム調達におけるリスク評価の課題」の草稿。 報告書の方も是非公開してください。 しかし今の時点で実証実験がどうとか言ってるレベルでは全然ダメなんじゃ... 一国民としては， やり直しまたは1,2年程度のスケジュール延長を希望！
山根信二さんの暗号輸出規制の話 (1/25 の近況) ってのは計算機暗号屋日記 の 1/18 の記事と絡む話なのかな。 業務ソフトの場合は面倒そうだなぁ。 そうでもない (PDF 注意) ？ 一筆書いときゃいいのかな。
翻訳に関る顛末話も面白い。
そういや 「文化庁がWeb上の著作物に対する「自由利用マーク」を制定」 するそうで。 ホント日本の役人ってマークが好きだよなぁ。 文字情報より図柄の方が分かり易いってのは幻想だと思うんだが。(いや， そういう場合もあるけどさ) クリエイティブ・コモンズより後に出てきて前者より微妙にヘボいってのもなんとも。 これで登録制とか言い出したら笑うよな。
WinXP って見た目だけじゃなくて設計コンセプトも大きく変わってるのですっごいやりにくい。 見た目は元に戻すこともできるけどねぇ。 マニュアルとか WinXP 用に全部作り直さないといけないし。 はうっ！
dviout の 3.15 以降には dvispc というツールがついているらしい。 これは dvi ファイルの内容を可読可能なテキストに相互変換するもの。 DVI のアセンブラ／逆アセンブラみたいなものですな。 面白そう。
「指紋認証がネットワークで使われていない理由」 (閲覧には会員登録が必要)
だからぁ， 誤差を許容するデータや変更不可能なデータは認証には使えないんだって！ でもローカルシステムではユーザ識別に使えるんだから， 生体情報による識別システムと既存の認証システムを組み合わせればいくらでもやりようがあると思うんだが。 まっでも， そんなのより USB キーとか使った方が合理的かつ合利的だと思うけどね。
Windows Privacy Tray の 0.7.95 がリリースされている。 最近ペース速いな。 これとは別に Windows Privacy Tool というプロジェクトがあって， こちらは 1.0rc1 を公開している。 内容は GnuPG や WinPT などのツール群をひとまとめにしたもの。 GnuPP の各国版のようなものかな。 日本語版はないけど。
同梱されているハンドブックがなかなかよい。 後でゆっくり調べてみよう。
おおっ， こいつぁ凄いぜ！ というわけで早速試してみたのだが... う〜ん， ビミョー。 これなら vi の方が使いやすいような気がするんだけど。 大昔に DOS の FD というツールを UNIX 上に移植するのが流行ったのだが， 何となくそれを彷彿とさせる作りである。
そういやビレッジセンターも WZ Editor の移植をやってるらしい。
こいつも後で試してみよう。
例の奴， うちにも来た。 凄い文面だね， こりゃ。 思い当たるフシがあろうとなかろうと， この文面だけで充分 「恐喝」 として成立するんじゃなかろうか。
「作品」 を 「商品」 として 「流通」 させるということがどういうことか分かっていれば (いかに今商業主義が過剰になっているからといって) 現状のような極端なことにはならない筈。 海賊版が横行するポルノ業界ですら分かってるのに...
いや， もう凄いことになってたみたいですな。 でもネットワーク管理者は今回のワームが比較的マヌケだったことで逆にホッとしてるんじゃないのかな。 あと SQL Server (あるいは MSDE) がいたるところに 「仕込まれ」 投げ売り状態だったことが分かったのは収穫か。 パッケージを買う (あるいはネットからダウンロードする) 時はもっと気をつけないとね。 MSDE は一見便利なのだが保守性を考えると非常に使いにくい DBMS だ。 これなら MySQL の方がマシである。(MySQL なら安心というわけではない。念のため)
しかし 「サイバーテロ」 なんてなことを言う報道姿勢はいい加減何とかして欲しい。 なんでもウケ狙いで面白おかしく報道すればいいってもんじゃないと思うのだが。 でもわたしゃむしろ 「Pluto Kiss」 を連想しちゃったけどね。 テレ東系列だとこっち方面で報道していたとか？ (広島市周辺には系列局がないのでよく分からんが)
XZ for Linux 試してみた。 素晴らしい。 私の環境は Vine Linux で Window Maker なのだが (GNOME は使ってない)， 問題なし。 readme.txt には 「環境変数LANGをja_JP.ujisにセット」 しろと書いてあったが， こちらも EUC-JP で問題なし。 ちうわけで， X Window 上のテキストエディタに関する不満はほぼ解消された。 (「ほぼ」ってのは， やはり秀丸に比べてショボいから)
Tripod の場所を借りて 「ドキュメント倉庫」 オープンしました。 んでもって手始めに 「クリエイティブ・コモンズ」についてまとめてみた。
「ドキュメント倉庫」 では SmartDoc によるドキュメント管理とクリエイティブ・コモンズによるライセンスの体系付けをやってみる予定。 ここで書いてる駄文や SET@home 関連の駄文を整理して移すつもりだ。 特に SET@home は新しいプロジェクトが始まったら古いドキュメントの置き場に困ってしまいそうなので。 まっ， でも， ボチボチと， ちうことで。
「「クリエイティブ・コモンズ」について」 はいつにも増して内容無保証。 特に後半は全面的に書き直すかも。 まだ 『コモンズ』 を完全に読み切ってないのよ。 でもクリエイティブ・コモンズについてあちこちから漁った情報の整理はこれで一応できたので， しばらくは (熟成するまで) 寝かせておくつもり。
「コピープロテクトを外して著作物を利用することを合法的に解釈してみる」
CCCD (CDS) を例に使うのは上手くない気もするけど (CDS が保護手段として機能しているかという問題もあるし)， 全体としてみれば面白いテーマ。
「IPA Winter 講演資料」
「オープンソースソフトウェアのセキュリティ確保に関する調査（ドラフト版）」
だぁ！ こんなに一度にたくさん読み切れるかぁ！ 今度の休日にでもゆっくり読も。
う〜ん， 最近色々目についてしまう。
Chaky は対称暗号 CAST を使った簡単なファイル暗号化/復号ツール。 鍵の生成方法は (パスワードをそのまま使ってるということはないだろうが， 単純なハッシュ値なのか塩をふってるのかなど) 不明だが， こういうのを厳密な運用の場で使うことはないだろうからそこそこ使えそう。