アカウント名:
パスワード:
> そうだとすると、Aさんがビジネス文書をアップロードしたら、たまたまBさんの自作ポエムとハッシュが一致、Aさんが別の端末から自分のビジネス文書を開こうとしたら謎のポエムが出てきてBさん涙目、みたいなセキュリティホールがあり得るので結構言語道断な気もします。たまたまハッシュが一致する可能性ならユーザー別に暗号化したってあると思いますが
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
無料ユーザーは文句言えないんじゃ (スコア:3, 興味深い)
Re: (スコア:0)
Re:無料ユーザーは文句言えないんじゃ (スコア:1)
Aさんが大きなファイルをアップロードしようとすると、DropBoxクライアントはそのファイルのハッシュを計算してDropBoxサーバに送る。サーバでは、同一ハッシュのファイルを他の人がDropBox上に持ってないかをチェックする。Aさんがアップロードしようとしたファイルがたまたまよく知られた動画ファイルなんかであれば、Bさんが既にアップロードしていたりする。その場合は、AさんのDropBoxクライアントはファイルをアップロードしない。その代わりサーバ側でAさんのアカウントからBさんのファイルへの紐付けが行われる(ハードリンクな感じ)。
と言う実装になってるんじゃ? という疑念が、「みんなが持ってそうなファイルをアップロードしようとした時に限って凄いスピードで同期される」という体験から推測される、と。
そうだとすると、Aさんがビジネス文書をアップロードしたら、たまたまBさんの自作ポエムとハッシュが一致、Aさんが別の端末から自分のビジネス文書を開こうとしたら謎のポエムが出てきてBさん涙目、みたいなセキュリティホールがあり得るので結構言語道断な気もします。
でもまあ、そんな器用なハッシュ衝突が起こる確率は、「適当に入力したパスワードが一致した」「ランダムにでっち上げたセッションキーが偶然当たった」レベルなので、それをセキュリティホールと言っちゃうとどんなシステムにもセキュリティホールがあることになっちゃうか。
Re: (スコア:0)
> そうだとすると、Aさんがビジネス文書をアップロードしたら、たまたまBさんの自作ポエムとハッシュが一致、Aさんが別の端末から自分のビジネス文書を開こうとしたら謎のポエムが出てきてBさん涙目、みたいなセキュリティホールがあり得るので結構言語道断な気もします。
たまたまハッシュが一致する可能性ならユーザー別に暗号化したってあると思いますが
Re:無料ユーザーは文句言えないんじゃ (スコア:2)
・AさんがファイルXをAさんのパスワードで暗号化したビット列x
・BさんがファイルYをBさんのパスワードで暗号化したビット列y
があって、xのハッシュとyのハッシュが偶然一致したので、サーバが勘違いしてビット列yはアップロードされずじまい。Bさんのファイル取得リクエストに対しては、間違ってビット列xが返される。xをBさんのパスワードで復号しても元のファイルYにはならないので、結果、Bさんからするとファイルの内容がランダム文字列に変化してしまったように見える。最初のコメントは、そのような不幸な例に遭遇しただけかもしれないじゃないか、という考察ですね。
ストレージを節約すべく、xとyが偶然一致する事に期待する、というのはちょっと考えにくい戦略じゃないかと。 ランダムなビット列同士が偶然一致する幸運に掛けることになるので、ユーザ毎のパスワードで暗号化したファイルをアップロードする仕様の場合は、そのストレージ節約戦略は採用されないように思います。
それを言い出すと、そもそもの「複数のユーザが同じ内容のファイルをアップロードするかも」と期待するという発想もかなり奇異に思えますが。
# ユーザがアップロードしたファイルを精査しているうちに同じ内容が多数有ることに気付いて
# そんな機能が実装されたんじゃ、みたいなもっとひどい邪推も出来ますが、ここまでくると言いがかり未満
そういうわけで、「他の人も置いていそうなファイルに限って高速に同期が出来る」という現象が本当に見られたなら、 それは、個々人のパスワードで暗号化されて送信されているわけではない、という事の強い傍証になるかと。
Re:無料ユーザーは文句言えないんじゃ (スコア:1, 参考になる)
また複数のユーザが同じものをおく可能性は低いという予想のほうがむしろ理解できないです． 自分の原稿，ホームビデオをおくというシチュエーションでは確かにあり得ないです． しかし，「面白いのみつけたよ」ってメール等で送られてきた画像・動画・文書をとっておいたりとか， もっと業務用のイメージで言えば，大きい「お知らせ文書」を添付で送られたりとか，重複が発生する場合もあるでしょう． で，多くのファイルは重複していないとしても，極一部の大きいファイルが数千人・数万人で重複していたら それを削ることの効果は無視できないものになるわけです．
Re:無料ユーザーは文句言えないんじゃ (スコア:1)
ZFSの場合は、Solarisで複数コンテナを使うとほぼ同じ構成のOS一式のディレクトリ構造が複数作られることになる、とかいう仕組みだった気がするので、コストを掛けて実装する理由が想像できるんですが。
DropBoxの場合は、いろいろ考えても1%も削減できないんじゃないか?とか、でも貸しストレージ企業がストレージを1%削減できたとしたらそれは結構なコストダウンになるのか?とか、ついでに、元々更新チェックのためにハッシュを計算してサーバに投げてという仕組みは必須だから、そこに多少の機能を上乗せするだけで実装出来る重複排除機能はそんなに高コストではないのか?とか、でも中身はお客様ご自身以外には絶対見えませんと言う外部仕様にある意味反する機能だし・・・とか。
Re: (スコア:0)
Re:無料ユーザーは文句言えないんじゃ (スコア:1)