2011年6月28日(火曜日)
ゆるゆり5 天然ボケ vs 計算されたボケ
公開: 2011年7月9日22時55分頃
購入。
- ゆるゆり5 (www.amazon.co.jp)
なんと、ついに表紙からあかりが消滅してしまいました。……と思ったら、帯の裏にいた!! しかも、他の誰よりも大きく描かれているではありませんか。誰よりも大きな扱いなのに、誰よりも目立たないあかり。
京子があかりに飲み物をおごる話には笑わされてしまいました。喉が渇いてスポーツドリンクが飲みたいというあかりに、京子は自動販売機のボタンを同時押し、出たのはおしるこ。自動販売機の同時押しは左側優先というのは知りませんでしたが、普通に実装するとそうなりそうではありますね。
あと、結衣がお茶を一気飲みするエピソードも面白かったです。京子がちなつを恐れるというシチュエーション自体が普段とは逆ですが、さらに、クールなツッコミキャラのはずの結衣が身体を張るという。
それから、私がいちばん興味深いと思ったのは、京子と櫻子を比較して分析するエピソード。作中では知性の差ということで落ち着きましたが、ごはんを食べさせろという台詞を比較しても、全く違う個性があることが分かります。
| 櫻子 | 京子 |
|---|---|
| なんでもいいからくわせろー | 炭水化物とたんぱく質をバランス良く私にくわせて!! 繊維質も忘れずに♥ |
| すし!! ステーキ!! フランス料理フルコース!! | 阿蘇牛とか池田牛とか赤身のうまいのを!! |
櫻子は欲望のままに言っている天然ボケ風味です。しかし京子はどう見ても狙ってボケています。結衣からツッコミを引き出そうという意図を感じますし、そのツッコミのバリエーションもたくさん考えられそうです。このたった2つの台詞で、天然ボケと計算されたボケの違いを非常にうまく表現していると思います。
二人が組んだらどちらがボケなのかという話もありましたが、おそらく京子はツッコミもできるのに対し、櫻子にツッコミは厳しいのではないかという感じがしますね。
- 「ゆるゆり5 天然ボケ vs 計算されたボケ」にコメントを書く
続・徳丸本のあれこれ ストレッチング処理の変更
更新: 2011年7月10日9時20分頃
徳丸本のあれこれを実践してみて気付いたことの続きです。
前回、ストレッチングの回数をどうするのかが難しいと書きました。負荷を心配しつつ1000回で実装してみたのですが、実際に動かしてみると処理が一瞬で終わってしまい、速すぎて心細く感じるほどでした。
アプリケーションの機能は一通り実装し終わり、テスト運用を始めたのですが、しばらく運用してみてもログインが遅いとか、それに伴って負荷が高くなるといったことは起きませんでした。
というわけで、もう少し遅くしてストレッチパワーをためた方が良いのではないかと考え、調整することにしました。
ハッシュアルゴリズムの変更
まず、ハッシュアルゴリズムをSHA512に変更しました。徳丸本 (www.amazon.co.jp)
※2011-07-10追記: 手元で実測した結果ではSHA512の方が少し遅かったので「遅い」と判断していましたが、春山さんからコメントをいただきました (twitter.com) (ありがとうございます)。64ビットCPUではSHA512の方が速いと言われているそうです。実装に依存する面もあるので、一概にどちらが遅いとは言えないようです。
ハッシュ値の長さは、16進表記で128文字。少し長い感じもしますが、varchar(255)のカラムにすんなり格納できますから問題ありません。
※データベースのサイズを節約したい場合は、Base64にしたり、バイナリで保存することにしても良いと思います。徳丸本のPHPのコードではhexdigestの形になっていて、それで特に問題なかったのでそのまま採用しました。
Rubyには標準でDigest::SHA512 (www.ruby-lang.org)がありますので、Digest::SHA512#hexdigestを呼ぶだけでOKです。ついでに、設定ファイルでDigestの種類を変更できるようにしておきました。
ストレッチ回数の調整
ハッシュアルゴリズムをSHA512に変更しても、速度はそれほど大きくは変わりませんでしたので、処理の回数も調整することにしました。
解析されにくくするためには、できるだけ遅くしたいところです。しかし、遅すぎるとログインのたびに利用者が待たされることになります。どのくらいを遅すぎると判断するのかは難しいところですが、今回は、0.1秒以内に処理できれば良いことにしました。
手元の環境でベンチマークを実行してみました。RubyにはBenchmark (www.ruby-lang.org)というクラスがありますので、rails consoleから以下のようなコードを実行しました。
Benchmark.measure { 1000.times{ User.password_digest('user_id', 'dummy_passphrase') } }
1回だけの測定では一瞬で終わってしまって誤差が大きいので、1000.timesで1000回実行するようにしています。ストレッチ回数の設定を変更しながら試していったところ、ストレッチ5000回が約0.07秒でした。処理速度は環境に依存すると思われますが、まあこのくらいで良いでしょう。
というわけで、ハッシュアルゴリズムをSHA512、ストレッチ回数を5000回に設定しました。本番反映してしばらく様子を見ましたが、特に問題も出ていないようです。もちろん、アルゴリズムや回数を変更すると既存のユーザーはログインできなくなりますので、パスワードの再設定は必要になりましたが。
なお、これはあくまで私が今回実装したシステムでの話です。今回開発しているアプリケーションはCMSで、ログインするのはサイト管理者、編集者、承認者だけ、その頻度も高くありません。そのため、ログイン処理の負荷が問題になることはあまり考えられないでしょう。一般の利用者がユーザー登録するようなシステムの場合、一度に多数のユーザーが頻繁にログインする可能性がありますので、もう少し慎重に検討する必要があるかもしれません。
- 前(古い): 2011年6月27日(Monday)のえび日記
- 次(新しい): 2011年6月29日(Wednesday)のえび日記
