野菜炒め

Permanent Link: http://www.cuspy.org/blog/archives/837
Trackback URL: http://www.cuspy.org/blog/archives/837/trackback

Permanent Link: http://www.cuspy.org/blog/archives/837
Trackback URL: http://www.cuspy.org/blog/archives/837/trackback
No comments yet.
You must be logged in to post a comment.

Permanent Link: http://www.cuspy.org/blog/archives/826
Trackback URL: http://www.cuspy.org/blog/archives/826/trackback
No comments yet.
You must be logged in to post a comment.
引越ししました。

押入れ(CLって書いてある所)と寝室が別れているので、寝る時にサーバーの音がまったく気にならなくなったのだけど、以前住んでいた所よりも押入れが狭くなってしまい、幾つかのサーバーが置けなくなってしまい困った。
縦空間は、まだ空いているので、棚を設置して小型のベアボーンに移行したり、ハンガーを掛ける所にFoneraをぶら下げるなどして収まった。

Permanent Link: http://www.cuspy.org/blog/archives/802
Trackback URL: http://www.cuspy.org/blog/archives/802/trackback
No comments yet.
You must be logged in to post a comment.
ちょっと前に購入した、手のひらベアボーン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分の乱数を生成してみた。
# 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
# 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
# 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 の方が若干失敗が多いな、こういうんもんなんだろうか。
Permanent Link: http://www.cuspy.org/blog/archives/782
Trackback URL: http://www.cuspy.org/blog/archives/782/trackback
No comments yet.
You must be logged in to post a comment.
帰省してて東京に戻ってくる時、新幹線の中で無線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 の母数は解らないけれど、サンプル数としてはそれなりの信頼性はあるんじゃないかと思う。
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 は 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 を持って運用している場合にマズかったな、と後から気が付いた。
Permanent Link: http://www.cuspy.org/blog/archives/773
Trackback URL: http://www.cuspy.org/blog/archives/773/trackback
No comments yet.
You must be logged in to post a comment.
< Previous Page | Next Page >