アカウント名:
パスワード:
> ＞ハードコードすることで秘密鍵が共有できているなら，> ＞鍵交換する必要がないですよね？>> 意味がわかりません。
公開鍵暗号化を使う必要もなくて、AESでもDESでもいいじゃんってことでは?
Wikiを読む限り交換される際に始めて暗号化されているようなので、 ファイル受信側：公開鍵Pと秘密鍵S(RSA)を生成し、Pを送信 ファイル送信側：共通鍵C(AES)を生成し、Pで暗号化して送信 これでCを使ってファイルを暗号化する、という教科書的な方法だと思います。
そんなことをやっても何の意味もない。クローラーが生成した公開鍵を「ファイル送信側」に送れば、「ファイル送信側」がその鍵を元に暗号化してクローラーに送信してしまう。（意味わかる？）
ちなみにこういうのはman-in-the-middle attackとは言わない。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ？ -- Debian初級
暗号が破られたわけじゃない (スコア:5, 参考になる)
プロトコルが解析された
暗号鍵が（プログラム中から）見つけ出された
あたりが正しい。
これ豆知識な。
Re:暗号が破られたわけじゃない (スコア:0)
ただ，RSAを使っているらしいので，鍵をプログラムに
埋め込む必要はないはずです．
Perfect Dark wiki より
> 通信は、公開鍵交換（RSA-1024）、秘密鍵でAES暗号鍵を暗号化・交換、
> AES暗号鍵で暗号化通信を開始、となっています。
> 自動アップデートは当方が秘密鍵を持っており、ソフトに公開鍵が組み込まれています。
> 電子署名を確認してからアップデートを行うので、安全性は高いと考えています。
ノード間の認証はできないはずなので，Man-in-the-middle のような，
プロトコル的な攻撃かもしれません．
Re: (スコア:0)
Re: (スコア:0)
そんなわけはない。peer to peer でRSAを使うなら、一方に公開鍵、もう一方には秘密鍵が当然に入っているわけで。
（公開鍵暗号ってだけで凄い万能とか思っちゃう人、まだいるんだね。）
Re: (スコア:0)
通信時に鍵交換ができるならば，
鍵データをプログラムにハードコードする
必要はないので，リバースエンジニアリングで
鍵を抜き取ることはできないはず，
ということを意図していました．
Re: (スコア:0)
だいたい、
> Man-in-the-middle のような，プロトコル的な攻撃かもしれません．
どうしてここで man-in-the-middle なんて出てくるんですか。
守りたい目的は何ですか？通信内容の盗聴を防止することですか？違うでしょ。
目的は、当該ソフトのpeerに成り済まして当該P2Pネットワークに参加されるのを防ぐこと
でしょ？
man-in-the-middleは正当な通信当事者2者の間に入る攻撃手法の名称ですから、当該ソフトのpeerに成り済まして当該P2Pネットワークに参加するのに、middleも糞もない、自分自身が通信当事者なのですから。（わかりませんか？）
Re: (スコア:0)
ハードコードすることで秘密鍵が共有できているなら，
鍵交換する必要がないですよね？
>目的は、当該ソフトのpeerに成り済まして当該P2Pネットワーク
>に参加されるのを防ぐことでしょ？
てっきり，ノード間の通信内容を秘匿にしたいのかと思っていました．
たぶん，これが，話がかみ合わない理由ですね．
Re: (スコア:0)
> ＞ハードコードすることで秘密鍵が共有できているなら，
> ＞鍵交換する必要がないですよね？
>
> 意味がわかりません。
公開鍵暗号化を使う必要もなくて、AESでもDESでもいいじゃんってことでは?
Re: (スコア:0)
Re: (スコア:0)
ハードコーディングされてないと言えると思います。
perfect darkについて詳細を知らないのでなんともいえないですが、
Wikiを読む限り交換される際に始めて暗号化されているようなので、
ファイル受信側：公開鍵Pと秘密鍵S(RSA)を生成し、Pを送信
ファイル送信側：共通鍵C(AES)を生成し、Pで暗号化して送信
これでCを使ってファイルを暗号化する、という教科書的な方法だと思います。
今回の件ですが、たぶんファイルの情報をやりとりする部分だけは
暗号化されてないか、簡単な暗号化だったので解読できた、ってことではないでしょうか？
で、それを収集して解析した、ってことだと思います。
Re: (スコア:0)
そんなことをやっても何の意味もない。クローラーが生成した公開鍵を「ファイル送信側」に送れば、「ファイル送信側」がその鍵を元に暗号化してクローラーに送信してしまう。（意味わかる？）
ちなみにこういうのはman-in-the-middle attackとは言わない。
Re: (スコア:0)
いや、だから別ACだと・・・。
私が言いたいのは、単にあなたがハードコーディングが絶対されている、みたいな論調だったので、
それを否定しただけです。
man-in-the-middle attackでないというのもわかってますよ。
それとこれが成りすましの防衛にはならないことも。
なので今回の件は、ファイル送受信の暗号解読が主な方法ではなくて、
プロトコルを解析した上でクローラーがなりすまして情報を収集する、
という方法を取ったのだと思ってるのですが、それについてはどうでしょうか？
それとも、perfect darkが成りすましを防衛する完全な手段を取っていたという情報をお持ちでしょうか？