アカウント名:
パスワード:
タレコミはITmediaの記事を引用してますが、この記事は変な文章ですね。
もう一つのリンク元TechCrunchの記事は分かりやすいです。こちらによれば、HTTPSの公開鍵暗号をユーザーセッション毎に生成するので、仮にどこかの誰かがTwitterのインターネットトラフィックを丸々保存していて、あるユーザーから現セッションの秘密鍵が漏れたとしても、他のユーザーのセッションは解読できないし、そのユーザーの過去・将来のセッションも解読できないよ。という技術のようです。
ITmediaはおそらく、どこかの「過去分のデータの中身(contents)に触れる(access)ことができない」というような感じの英文を見て、「コンテンツに接続できない」と誤訳しちゃったんじゃないでしょうか。
「長期の公開鍵とプライベート鍵のセットが必要」というのは、長期間のトラフィックから中身を解読したかったら、その期間の各セッションの鍵セットがそれぞれ必要だよ。という意味ですね。
そうすると、その前の「長期にわたって解読されない」とは、暗号解読に長期間を要する、という意味ではなくて、「あるユーザーの暗号通信が長期間にわたって解読されっぱなしになることを防ぐ」という意味のようです。紛らわしい書き方をしたものです。
# というか全体的に「コンテンツ」とか「デコード」とか「接続」とか、訳語の選び方がおかしい。
techCrunchの記事も謎が多いですね。HTTPSで配る公開鍵が毎回違うなら、オレオレ証明書みたいなのをセッションの度に受け入れないといけないような気がします。
HTTPSの仕組みは崩さずに、ということになると、通常の公開鍵暗号にもう一枚 公開鍵暗号フェーズを組み込むことになりますが、この場合、プロトコルレベルでやろうとすると、クライアント側の対応が必要なように思えます。
となると、この一枚組み込んだ公開鍵暗号フェーズを、クライアントのjavascriptでこなすことになりますが、まぁ無くはないんでしょうけど、強引ですよね。というか こういう技術なのかな。
そんなに頻繁に行わない Webサービス間通信の場合は、毎回 公開鍵-秘密鍵を作って、ワンタイムパスワードのやりとりを行うってことは普通にやりますのでその部分に驚きはありませんが、HTTPSに一枚膜を張って 150msの遅延ぐらいはいいでしょ、という強引さは なかなかマネができない気がします。
とりあえずPerfect Forward Secrecyのことを調べてからコメントしようぜ
他のコメントにもあるが日進月歩のＩＴ業界では古い技術（Ｇｏｏｇｌｅは２年前導入らしい）
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
ITmediaの記事はなんか変だ (スコア:2)
タレコミはITmediaの記事を引用してますが、この記事は変な文章ですね。
もう一つのリンク元TechCrunchの記事は分かりやすいです。こちらによれば、
HTTPSの公開鍵暗号をユーザーセッション毎に生成するので、
仮にどこかの誰かがTwitterのインターネットトラフィックを丸々保存していて、あるユーザーから現セッションの秘密鍵が漏れたとしても、
他のユーザーのセッションは解読できないし、そのユーザーの過去・将来のセッションも解読できないよ。
という技術のようです。
ITmediaはおそらく、どこかの「過去分のデータの中身(contents)に触れる(access)ことができない」というような感じの英文を見て、「コンテンツに接続できない」と誤訳しちゃったんじゃないでしょうか。
「長期の公開鍵とプライベート鍵のセットが必要」というのは、
長期間のトラフィックから中身を解読したかったら、その期間の各セッションの鍵セットがそれぞれ必要だよ。という意味ですね。
そうすると、その前の「長期にわたって解読されない」とは、暗号解読に長期間を要する、という意味ではなくて、「あるユーザーの暗号通信が長期間にわたって解読されっぱなしになることを防ぐ」という意味のようです。
紛らわしい書き方をしたものです。
# というか全体的に「コンテンツ」とか「デコード」とか「接続」とか、訳語の選び方がおかしい。
Re: (スコア:0)
techCrunchの記事も謎が多いですね。
HTTPSで配る公開鍵が毎回違うなら、オレオレ証明書みたいなのを
セッションの度に受け入れないといけないような気がします。
HTTPSの仕組みは崩さずに、ということになると、通常の公開鍵暗号に
もう一枚 公開鍵暗号フェーズを組み込むことになりますが、この場合、
プロトコルレベルでやろうとすると、クライアント側の対応が必要なように思えます。
となると、この一枚組み込んだ公開鍵暗号フェーズを、クライアントのjavascriptで
こなすことになりますが、まぁ無くはないんでしょうけど、強引ですよね。
というか こういう技術なのかな。
そんなに頻繁に行わない Webサービス間通信の場合は、毎回 公開鍵-秘密鍵を作って、
ワンタイムパスワードのやりとりを行うってことは普通にやりますのでその部分に
驚きはありませんが、
HTTPSに一枚膜を張って 150msの遅延ぐらいはいいでしょ、という強引さは なかなか
マネができない気がします。
Re: (スコア:0)
とりあえずPerfect Forward Secrecyのことを調べてからコメントしようぜ
他のコメントにもあるが日進月歩のＩＴ業界では古い技術（Ｇｏｏｇｌｅは２年前導入らしい）