少し前に武田さんが、
（略）では逆に128bit SSL相当あるいはそれ以上の強度で暗号化したファイルを紛失した場合において、その事実を公表・謝罪する必要があるのかという疑問が生まれる。
紛失したファイルを第三者が拾得した場合と、暗号化した通信を第三者が傍受する場合のどちらのリスクが大きいかということになるかとは思うが、実際のところインターネット上での個人情報の暗号化通信と、暗号化された個人情報ファイルの紛失の差異について、どのような認識が一般的なのだろうか。
という疑問を呈されていた。
企業が個人情報ファイルを紛失した際に、単に「暗号化していますので問題ありません」で済まされないのは、まず、少なくともどんな暗号アルゴリズムを用いていたかを明らかにしなければ、客観的に「問題ない」とはできないからだ。そして、お墨付きの暗号アルゴリズムを使用していたとしても、鍵の作り方がどうなっていたかと、鍵の管理をどうしているのかを明らかにしなければならない。
SSLとの対比で言うと、SSLでは通信データ（ハンドシェイク完了後の）の暗号化に用いる鍵に、
という性質がある。
これに対して、一般的に行われているファイルの暗号化では、まず鍵の生成方法は自由であり、鍵ファイルの保存を必要としないものでは、パスワード（人間が思い浮かべた文字列）をそのまま鍵にしているものがあるし、パスワードと暗号化用ソフトウェア内蔵の鍵（リバースエンジニアリングによって判明し得る）から生成しているものもあり、それらでは、どんな暗号アルゴリズムと鍵長を用いようとも、強度はパスワードのレベルまで落ちていると見なされるだろう。
次に、鍵ファイルを保存する方法の場合、鍵の生成方法まで規格化されたものを使用すればよいが、鍵ファイルを秘密にしておかなければならず、それが同時に流出している可能性があるならば、鍵ファイルの使用にパスワードを要求するようになっていても、安全性はパスワードのレベルだと見なされる。
SSLが信頼されているのは鍵がセッション終了時に消去されるところにポイントがある。一般に、通信の暗号化では鍵は短期間で捨てられる（ようにプロトコルを設計できる）のに対し、ファイルの暗号化では、その目的上、いつかそのファイルを復号しなくてはならず、それまで鍵を捨てずに温存しておかざるを得ず、どうやってもそこが通信の暗号化にはないリスクとなる。*1
「SSLは許されるのに、暗号化ファイルは許されないの？」という疑問に対する答えは、安全であることの信頼性について、暗号化ファイルがSSL通信並みになることは、それがいつか復号されることを予定しているものである限り、あり得ないからということではないか。
そうすると、暗号化された個人情報ファイルを流出させたときに謝罪しなくてよいためのひとつの条件として考えられるのは、「そのファイルはもう復号することを予定しておらず、鍵を消去している」と示すことではないか*2。そのような場合があるかというと、鍵は安全に消去したが、なぜか暗号化ファイルは消さなかった（もしくは、安全に消去できていなかった）という場合があるかどうかだ。
という記事が出た。すばらしい。私も「Winny稼動コンピュータ数調査の追試をしてみた」では、SP1を使わざるを得なかったのだが、早速「BIOT」を使わせていただいたところ、SP2でも、SP1のときと同じ性能を得ることができた。
*1 ただし、ここでは流出が起きるような事態を想定しているので、通信の暗号化においても、通信の端点（サーバ）から流出が起きる場合を考慮しないと公平でない。まず、セッション鍵がサーバから流出するケースでは、そのタイミングで生きているセッションの通信が傍受されたときに復号され得ることになるが、元々その場合は、サーバ内で復号されたばかりのデータも流出し得るのだから、それは暗号化の問題ではない。次に、（訂正）セッション鍵の交換に使われる秘密情報（たとえば、RSAを用いる場合の秘密鍵）が流出した場合を検討すると、流出以降の暗号化通信は安全でないものとなるが、流出以前に行った暗号化通信については、安全である（傍受された通信データは復号されない）と見なすことができる。
訂正（8月30日） 脚注1にミスがあったので訂正。Diffie-Hellman + RSAを想定していたはずだった（DHE-RSA-*）。この場合RSA鍵は認証に用いられ、それが流出するとman-in-the-middle攻撃によりそれ以降の秘密が損なわれる件を言いたかったつもり。しかし……（つづく）
*2 暗号化アルゴリズムと鍵生成の方法にお墨付きのある規格化されたものを用いていたことを示し、かつ、消去するまでの間の鍵の管理体制が適切であったことを示すのに加えて。