Fork me on GitHub

cuspy memo


野菜炒め

2010/01/18 Monday 03:14:16

yasai

No comments yet.

Leave a comment

You must be logged in to post a comment.

#include <beer.h>

2009/11/09 Monday 23:29:05

include_beer_h

No comments yet.

Leave a comment

You must be logged in to post a comment.

ぶら下がりLinux

2009/08/25 Tuesday 20:51:50

引越ししました。

間取り

押入れ(CLって書いてある所)と寝室が別れているので、寝る時にサーバーの音がまったく気にならなくなったのだけど、以前住んでいた所よりも押入れが狭くなってしまい、幾つかのサーバーが置けなくなってしまい困った。

縦空間は、まだ空いているので、棚を設置して小型のベアボーンに移行したり、ハンガーを掛ける所にFoneraをぶら下げるなどして収まった。

押入れ

No comments yet.

Leave a comment

You must be logged in to post a comment.

ARTiGO A1000 のハードウェア乱数生成器を調査

2009/03/15 Sunday 02:50:04

ちょっと前に購入した、手のひらベアボーンARTiGO A1000がTRNG(ハード
ウェア乱数生成器)を持っていることに気がついた。

# modprobe via-rng
# ls -l /dev/hwrng
crw-rw—- 1 root root 10, 183 2009-03-15 00:15 /dev/hwrng
# head -c 16 /dev/hwrng | hexdump
0000000 e06d 5079 c2ae e9b5 8cc2 8781 fa6d 9497
0000010

さっそく乱数の生成速度と、品質を確かめてみる。
比較対象は、フェアじゃないけど疑似乱数の /dev/urandom と、eToken Pro が持っている乱数生成機(これは TRNGらしい)と比べてみる。
それぞれの乱数生成機で1M分の乱数を生成してみた。

  • /dev/urandom(PRNG)
  • # dd if=/dev/urandom of=/dev/null bs=1024 count=1024
    1024+0 records in
    1024+0 records out
    1048576 bytes (1.0 MB) copied, 1.60021 s, 655 kB/s

  • /dev/hwrng(TRNG)
  • # dd if=/dev/hwrng of=/dev/null bs=1024 count=1024
    1024+0 records in
    1024+0 records out
    1048576 bytes (1.0 MB) copied, 3.02498 s, 347 kB/s

  • eToken(TRNG)
  • # time echo -ne “engine -t dynamic -pre SO_PATH:/usr/local/engine_pkcs11-0.1.5/lib/engines/engine_pkcs11.so -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre MODULE_PATH:/usr/lib/opensc/opensc-pkcs11.so\nrand -engine pkcs11 1048576 -out /dev/null” | openssl
    OpenSSL> (dynamic) Dynamic engine loading support
    [Success]: SO_PATH:/usr/local/engine_pkcs11-0.1.5/lib/engines/engine_pkcs11.so
    [Success]: ID:pkcs11
    [Success]: LIST_ADD:1
    [Success]: LOAD
    [Success]: MODULE_PATH:/usr/lib/opensc/opensc-pkcs11.so
    Loaded: (pkcs11) pkcs11 engine
    [ available ]
    OpenSSL> engine “pkcs11″ set.
    OpenSSL>
    real 0m6.439s
    user 0m0.332s
    sys 0m0.008s

まとめ。VIA の /dev/hwrng は /dev/urandom より半分くらい遅い。
まあ、PRNG と比べるのがナンセンスな話で TRNGとしては十分なスピードが出ていると思う。eToken Pro は 1M 生成するのに6秒もかかってしまう、これは eToken Pro の乱数生成器の目的が秘密鍵の生成を目的としているので遅いのは仕方の無いところ。

次は品質。乱数の品質といえば、NSA が FIPS 140-2 で規定している 4つの乱数検定。
簡単な乱数検定だったので以前ちょこっと実装したのがあるんだけど、なんと、debian の rng-tools というパッケージにこの FIPS 140-2 の乱数検定を行うプログラムが付属していた。

こんな感じで /dev/urandom のテストができる。

% dd if=/dev/urandom bs=1024 count=1024 | ./rngtest
rngtest 2-unofficial-mt.12
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

rngtest: starting FIPS tests…
rngtest: entropy source exhausted!
rngtest: bits received from input: 8388608
rngtest: FIPS 140-2 successes: 419
rngtest: FIPS 140-2 failures: 0
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 0
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=1.881; avg=5.000; max=4768.372)Mibits/s
rngtest: FIPS tests speed: (min=23.606; avg=24.818; max=25.064)Mibits/s
rngtest: Program run time: 1923705 microseconds

なんかテストが5つに増えてるけど気にしない。この結果が意味するところは、20000 bit の乱数を入力として5種のテストを各 419 回ずつ行った所すべてのテストで1度も失敗し無かった、という結果。

失敗しないとつまらないので、もっとたくさんやってみる。

% dd if=/dev/urandom bs=1M count=100 | ./rngtest
rngtest 2-unofficial-mt.12
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

rngtest: starting FIPS tests…
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 191.716 s, 547 kB/s
rngtest: entropy source exhausted!
rngtest: bits received from input: 838860800
rngtest: FIPS 140-2 successes: 41911
rngtest: FIPS 140-2 failures: 32
rngtest: FIPS 140-2(2001-10-10) Monobit: 5
rngtest: FIPS 140-2(2001-10-10) Poker: 4
rngtest: FIPS 140-2(2001-10-10) Runs: 9
rngtest: FIPS 140-2(2001-10-10) Long run: 14
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=12.590; avg=5254.638; max=6510416.667)Kibits/s
rngtest: FIPS tests speed: (min=1.142; avg=23.456; max=25.163)Mibits/s
rngtest: Program run time: 191722267 microseconds

% dd if=/dev/hwrng bs=1M count=100 | ./rngtest
rngtest 2-unofficial-mt.12
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

rngtest: starting FIPS tests…
rngtest: entropy source exhausted!
rngtest: bits received from input: 838860800
rngtest: FIPS 140-2 successes: 41891
rngtest: FIPS 140-2 failures: 52
rngtest: FIPS 140-2(2001-10-10) Monobit: 9
rngtest: FIPS 140-2(2001-10-10) Poker: 3
rngtest: FIPS 140-2(2001-10-10) Runs: 15
rngtest: FIPS 140-2(2001-10-10) Long run: 25
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=6.484; avg=2748.736; max=6510416.667)Kibits/s
rngtest: FIPS tests speed: (min=937.425; avg=23785.710; max=25766.821)Kibits/s
rngtest: Program run time: 335642185 microseconds

/dev/hwrng の方が若干失敗が多いな、こういうんもんなんだろうか。

No comments yet.

Leave a comment

You must be logged in to post a comment.

大阪<->東京間の無線LAN アクセスポイントに関する調査レポート

2009/01/05 Monday 00:10:51

帰省してて東京に戻ってくる時、新幹線の中で無線LAN アクセスポイントを探索してみると、結構近隣の建物からの電波が届いていることに気がついた。
暇だったし、今後なにかの役に立つかもしれないので無線LANアクセスポイントが発するビーコンを収集してみた。

* 実装

iwlist scan の結果を parse して MAC アドレスをキーにして、BerkeleyDB 突っ込む 簡単な perl スクリプトを新神戸あたりから書き始めて、新大阪あたりで一応完成したんだけど BerkeleyDB だと後から集計するのが面倒くさそうなので名古屋あたりで SQLite を使用するように改変した。(コードは最後に載せる)
連続して iwlist scan を実行する間に1秒間の sleep を入れた。新幹線の平均速度が秒速 60m/s ぐらいだとすると結構取りこぼしている可能性が有るんだけど、ノートPCのバッテリーが持たないので仕方なく sleep を入れた。
その他、省電力にするために CPU のクロックを引き下げたり、ディスプレイを暗くしたり、ディスクアクセスを無くすために tmpfs 上に DB を置くなどの工夫を行った。

* 結果

新大阪から東京駅までの間で無線 LAN アクセスポイントは 合計 10979台見つかった。
日本全国に普及している無線LAN AP の母数は解らないけれど、サンプル数としてはそれなりの信頼性はあるんじゃないかと思う。

* SSID

10979台中 SSID を隠している(ビーコンに載せない)AP は 1283台(11%)だった。
SSID を隠していないAP 9696台(89%)の中で人気の SSID TOP 10 は以下の通り。

SSID 台数
corega 284
CG-Guest 150
BBUser 131
planexuser 96
YBBUser 89
Airport 80
docomo 75
MyPlace 60
mobilepoint 60
default 47

* チャンネル

チャンネル 台数
1 3088
2 626
3 394
4 215
5 544
6 1469
7 1285
8 132
9 364
10 296
11 2566

多くのユーザーがデフォルトのChannel 設定のまま使用していると思うんだけど、うまく端っこと真ん中で分散しているみたい。出荷時の時点でデフォルトの設定がこんな風に分布しているのかな。

* セキュリティ方式

10979台の無線LAN AP の内、通信内容が暗号化されていないアクセスポイントは 1880台(17%)見つかった。
通信内容が暗号化されていた 9099台の AP がサポートしているセキュリティ方式は WEPが 5845台, WPAが 3107台, WPA2が 1181台でした。
# 暗号化方式は1台の AP で2種以上サポートしている場合が有る

* 脆弱なアクセスポイント

脆弱な無線 LAN アクセスポイントの定義を

  • 認証していないAP
  • WEP を使用しているAP
  • WPA を使用しているけれど鍵交換方式に TKIP しか使えないAP
  • WPA2 を使用しているけれど鍵交換方式に TKIP しか使えないAP

とすると、これらの何れかに該当する AP は 8417台見つかった。
つまり 大阪< ->東京間の無線LAN アクセスポイントのうち、76% は脆弱なアクセスポイントであることが分かった。

* その他いろいろ

* 対向線路の新幹線が通り過ぎる瞬間 N700G1, N700G2 … という SSID が大量に拾える。
* 新横浜付近の住宅街を通り過ぎるとき 60, 70 ほどの AP が同時に見つかる
* 新幹線でバッテリーが切れそうになったら、手洗い所にコンセントが有る。
* 最初世界がもしも100台の無線LANアクセスポイントだったら、って文を書こうかと思ったけど淡々と統計をまとめてみることにした。
* なんだろうこれは

IE: IEEE 802.11i/WPA2 Version 0
Group Cipher : Proprietary
Pairwise Ciphers (1) : Proprietary

* MAC アドレスをユニークキーにしてDB に入れると一つの AP が複数の SSID を持って運用している場合にマズかったな、と後から気が付いた。

No comments yet.

Leave a comment

You must be logged in to post a comment.

< Previous Page | Next Page >