アカウント名:
パスワード:
RC4暗号は解読が簡単なので、Winnyでいくら暗号化といっても、すぐに経路がばれてしまいます。 まさに「頭隠して尻隠さず」と同じような原理ですね。
Winny開発者（金子勇氏）の設計の稚拙さを批判・非難する声がネット上ではまったく聞かれないのは何故なのでしょう？
うぅ～ん、もうちょっと勉強された方が良いような。 OpenPGPもTLSも規格は標準化されていて公開されているし、 それに基づいたopen sourceな実装は多々ありますよ。 でも、それらの実装で暗号を破られるようなものはあまりないですよね。 ＃たまに仕様もしくは実装上の脆弱性でやぶられる可能性が ＃指摘されることはありますが。 ＃＃その場合でも、すぐ修正されるけど。
> これは、どこにも管理されたノードがない純粋P2Pの宿命です。
違いますよ。TLSなどで通信先を保証するのに認証局は必要ですが、 通信自体の暗号化には必須ではありません。
Winnyでダメダメなのは、セッションの最初に、いきなり 共通鍵を暗号化せずに送付するからです。この仕様のため、 セッションの最初の通信から傍受できれば、セッションの すべてを解読可能なのです。
まじめに実装するなら、GnuPGなどで公開/秘密鍵ペアをつくり、 セッションの最初に公開鍵を送付し、セッション用の共通鍵を 暗号化して返してもらえば、通信の安全性はかなり高かった でしょうね。
公開鍵については、長時間の保持は結局足がつきますから、 定期的(数時間に1度)更新すれば良いでしょう。 ＃CPUパワーに糸目をつけないのであれば、セッションごとに ＃更新しても良いわけで。
ACCSなどの外部の人間がPeer to Peerでやり取りされる情報を解読するのは可能なんでしょうか？
どうしてそんな簡単なことがわからないんだろう・・・・
> 必須なんだよ。まだこんな馬鹿がいるのか。
TLS自体でも認証局を要求しない完全匿名(total anoymity)モードがサポートされていますよ。
これはman-in-the-middle攻撃への耐性がないため、TLSでも推奨されてはいませんが、それを理解したうえでなら、共通鍵をいきなり送りつけるよりはちょっと(盗聴による解析を避けられるという点において)だけましです。
そして、あとはman-in-the-middle攻撃のハードルが盗聴によるそれよりどれだけ高いかという見積もり次第でしょうね。 ＃man-in-the-middle攻撃のハードルが盗聴による解析よりも低いとされるなら、仰るとおり、公開鍵を利用するメリットは存在しないでしょう。
それ自体は了解ですが、であるならば、RC4のみを用いた通信はそれ自体意味を成さないのでは？ ＃「通信は（なんちゃって）暗号化されています」と言いたかっただけ？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
元々暗号化が弱いWinny (スコア:2, 参考になる)
RC4暗号は解読が簡単なので、Winnyでいくら暗号化といっても、すぐに経路がばれてしまいます。
まさに「頭隠して尻隠さず」と同じような原理ですね。
Super Souya
Re:元々暗号化が弱いWinny (スコア:0)
声がネット上ではまったく聞かれないのは何故なのでしょう？
逮捕されればあらゆる批判から逃れられる神になれるのか？
原理的に暗号で対処はできませんよ（Re:元々暗号化が弱いWinny） (スコア:4, すばらしい洞察)
どうやったって、Winny本体を解析されたら破られますよ。
べつに、Winnyの設計が弱いわけじゃありません。
これは、どこにも管理されたノードがない純粋P2Pの宿命です。
金子氏はそのことをちゃんとわかっているから、
イタチゴッコになるような臭い設計をせず、割り切ったのでしょう。
47氏語録にもそういう発言がありませんでした？
稚拙だと思うような人は技術的に半可通だからです。
Re:原理的に暗号で対処はできませんよ（Re:元々暗号化が弱いWinny） (スコア:0)
> どうやったって、Winny本体を解析されたら破られますよ。
うぅ～ん、もうちょっと勉強された方が良いような。
OpenPGPもTLSも規格は標準化されていて公開されているし、
それに基づいたopen sourceな実装は多々ありますよ。
でも、それらの実装で暗号を破られるようなものはあまりない
ですよね。
＃たまに仕様もしくは実装上の脆弱性でやぶられる可能性が
＃指摘されることはありますが。
＃＃その場合でも、すぐ修正されるけど。
> これは、どこにも管理されたノードがない純粋P2Pの宿命です。
違いますよ。TLSなどで通信先を保証するのに認証局は必要ですが、
通信自体の暗号化には必須ではありません。
Winnyでダメダメなのは、セッションの最初に、いきなり
共通鍵を暗号化せずに送付するからです。この仕様のため、
セッションの最初の通信から傍受できれば、セッションの
すべてを解読可能なのです。
まじめに実装するなら、GnuPGなどで公開/秘密鍵ペアをつくり、
セッションの最初に公開鍵を送付し、セッション用の共通鍵を
暗号化して返してもらえば、通信の安全性はかなり高かった
でしょうね。
公開鍵については、長時間の保持は結局足がつきますから、
定期的(数時間に1度)更新すれば良いでしょう。
＃CPUパワーに糸目をつけないのであれば、セッションごとに
＃更新しても良いわけで。
Re:原理的に暗号で対処はできませんよ（Re:元々暗号化が弱いWinny） (スコア:1)
> セッションの最初に公開鍵を送付し、セッション用の共通鍵を
> 暗号化して返してもらえば、通信の安全性はかなり高かった
> でしょうね。
そんな、面倒臭いことをしなくても、匿名化を増すためだけのP2PならDiffie-Hellmanで十分でしょう。
その程度も思いつかなかった、作者を「神」扱いする連中が信じられない。
Re:原理的に暗号で対処はできませんよ（Re:元々暗号化が弱いWinny） (スコア:0)
思いつかなかった訳じゃないと思うよ。
作者自身、暗号化なんてモビルスーツの足程度にしか思ってなかったかも知れないし。
Re:原理的に暗号で対処はできませんよ（Re:元々暗号化が弱いWinny） (スコア:0)
結局このシステムでは鍵を実行ファイルに埋め込むか、セッションのはじめに渡すかを行うかを行わなければならないため、通信内容は解読されることになります。
素人の質問 (スコア:0)
Re:素人の質問 (スコア:0)
どうしてそんな簡単なことがわからないんだろう・・・・
Re:原理的に暗号で対処はできませんよ（Re:元々暗号化が弱いWinny） (スコア:2, おもしろおかしい)
そんなこと言ったら誰もいなくなっちゃう……
Re:原理的に暗号で対処はできませんよ（Re:元々暗号化が弱いWinny） (スコア:0)
> ＞通信自体の暗号化には必須ではありません。
> 必須なんだよ。まだこんな馬鹿がいるのか。
TLS自体でも認証局を要求しない完全匿名(total anoymity)モードがサポートされていますよ。
これはman-in-the-middle攻撃への耐性がないため、TLSでも推奨されてはいませんが、それを理解したうえでなら、共通鍵をいきなり送りつけるよりはちょっと(盗聴による解析を避けられるという点において)だけましです。
そして、あとはman-in-the-middle攻撃のハードルが盗聴によるそれよりどれだけ高いかという見積もり次第でしょうね。
＃man-in-the-middle攻撃のハードルが盗聴による解析よりも低いとされるなら、仰るとおり、公開鍵を利用するメリットは存在しないでしょう。
Re:原理的に暗号で対処はできませんよ（Re:元々暗号化が弱いWinny） (スコア:0)
＞モードがサポートされていますよ。
だからさあ、それで今回の目的が達成できるのかね？
「Winny自身以外にWinnyプロトコルで接続させない」が今の目的なんだよ？
そんなことすぐわかるだろ？
Re:原理的に暗号で対処はできませんよ（Re:元々暗号化が弱いWinny） (スコア:0)
それ自体は了解ですが、であるならば、RC4のみを用いた通信はそれ自体意味を成さないのでは？
＃「通信は（なんちゃって）暗号化されています」と言いたかっただけ？
Re:原理的に暗号で対処はできませんよ（Re:元々暗号化が弱いWinny） (スコア:0)
そうだよ。47氏語録にもあるし、「Winnyの技術」にも書かれている。