せっかく作った 2048bit の秘密鍵も 16bit 相当に縮まってしまうことがある、こんな世の中だから、大事な鍵を生成する時には良質な乱数を使うように心がけたい。 debian の openssl の問題でソースコードを確認してみた所、元々の乱数生成器の実装もどうかと思った。初期化していないメモリの MD5 を反映させているんだけど、初期化してないメモリってかなりの確率で疎なんじゃなかろうか、全部 0 って確率も高いんじゃないかな。
というわけで去年買った eToken Pro にハードウェア乱数生成器がついているので今後大事な鍵はこれを使って作るようにしたい。でもこのハードウェア乱数生成器がその他の疑似乱数生成器と比べて良いという根拠も無いので簡単な検定を行ってみる。
乱数の検定はいろいろ有るみたいだけれど、アメリカ国立標準技術研究所が発行する FIPS 140-2 の中で定義されているものの、何故か打ち消し線で削除されている「monobit test」をやってみる。monobit test とは 20,000 bit の乱数を生成して、1 の数が 9,725 〜 10,275 の間だったら OK、という単純な度数検定。今回は複数の乱数生成器の比較が行いたいのでそれぞれの乱数生成器で生成した乱数からカイ２乗値を求め、比較する。

まずいろいろな乱数生成器で 1M 程度の乱数の生成する。(/dev/random はエントロピーを貯めるのが面倒なのでやめた。)

• /dev/urandom

% dd if=/dev/urandom of=data.urandom bs=1M count=1

• openssl rand

% openssl rand 1048576 -out data.openssl

• eToken Pro HWRNG

% openssl
OpenSSL> engine -t dynamic -pre SO_PATH:/usr/local/openssl/lib/engines/engine_pkcs11.so -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre MODULE_PATH:/usr/local/opensc/lib/opensc-pkcs11.so
(dynamic) Dynamic engine loading support
[Success]: SO_PATH:/usr/local/openssl/lib/engines/engine_pkcs11.so
[Success]: ID:pkcs11
[Success]: LIST_ADD:1
[Success]: LOAD
[Success]: MODULE_PATH:/usr/local/opensc/lib/opensc-pkcs11.so
Loaded: (pkcs11) pkcs11 engine
[ available ]
OpenSSL> rand -engine pkcs11 1048576 -out data.etoken

って生成した乱数のχ２乗値を求めてみたんだけどやっぱりダメだこれ、何回やっても値がバラバラで。サンプル数を増やしても値が収束しない。
一気にやる気が失せてしまったけれど、また今度別の検定方法で挑戦するかもしれない。

これは、クロスケーブルを作りたいけど圧着ペンチを持ってないという方やストレートケーブルはそこら辺にごろごろ転がっているのにわざわざクロスケーブルを買うのは勿体ない。という方に向けたチュートリアルです。

1. ストレートケーブルの外皮を剥きます。



2. 緑とオレンジ、あと緑白のスプライトとオレンジ白のスプライトの線を切ります



3. 緑とオレンジを結線し、緑白のスプライトとオレンジ白のスプライトを結線します。



4. 完成。

この様に、ネジネジしただけだとショートする可能性があるので不安な人は半田付けして、ガムテープでも巻いておくと安心です。

昨日の続きで runit をさわってみる。
run script と同じ所に finish という名前の script を置くことで異常終了時にメールを送ったり出来るって書いたけど、sv down でサービスを計画終了させた時にも finish script は実行されるみたい。
正常終了と異常終了を区別するにはどうしたら良いか調べてみると finish script に 2つの引数が渡って実行されていることが解った。

finish script の内容を

#!/bin/sh

echo $@

こんな感じにして、sv down すると

-1 15

という内容がログに書き出された。
たぶん、1つ目はプロセスの終了コード(main の返値)で 2つめはシグナルの様だ。
なので異常終了時にメールを送りたい時は

#!/bin/sh

if [ $2 -ne 15 ];then
# メールを送る
fi

というような finish script にした。

runit は daemontools と同様のプロセスのスーパーバイザシステム。
daemontools が public domain になって久しいけど、今後の機能拡張やインターフェイスの改善が期待出来ないので手近なところから runit に乗り換えてみた。
インストールドキュメントを読んでて強烈な既視感を感じたけど、無事動作することが出来た。

ちょっと使ってみて気がついた良いところ

* finish script
プロセスが異常終了した時にメールを送ったり

* svlogd(multilogの代替) で syslog に飛ばせる
multilog では logger に渡して変なことやってたなぁ

* log に tai64n じゃなくて人間に読みやすい普通の日付を入れられる
でも、ローカルのタイムゾーンに出来ないのが不満。

かっこいいシステムモニタの conky を普通に実行すると、描画の度にチラついて鬱陶しい。設定ファイル .conkyrc に

double_buffer yes

と書いたとしても

Conky: drawing to single buffer

という標準エラー出力が出ていることからダブルバッファリングが有効になっていない事が解る。これを有効にするには X.Org の double-buffering extension を使う必要があることが解った。
/etc/X11/xorg.conf の Section “Module” に

Load “dbe”

って書いた。これで conky がチラつなかなくなった。
でも逆に今まで使っていた torsmo が見えなくなったんだけど、それはもういいや。