「Dropbox、データの暗号化に関する説明が正しくなかったとして告発される 」記事へのコメント

暗号化されてないならすれば良いじゃない

[s02222 (20350)]

TrueCryptのボリュームファイルをDropBoxに置けばOK、と。

DropBoxのシステムにどれぐらい余分な負荷をかけちゃうのか知らないけど。

Re:

[Anonymous Coward]

>TrueCryptのボリュームファイルをDropBoxに置けばOK、と。

ボリュームの一部（たとえば数KB）が書き換わっても、ボリューム全体送信しちゃうんじゃ
dropboxの負担よりユーザーの方がやきもきしそう。

Re:

[s02222 (20350)]

ついうっかり、2カ所で編集してコンクリフト処理されると倍の容量を消費してしまいますね。ファイル単位で暗号化できるような何かを探さないとダメか。

Re:

[ikotom (20155)]

DropBox & TrueCrypt を実際にやっておりますが、
どうもアップロード速度から判断する限りは差分のみ送っているようなので
数GBもあるTrueCryptファイルをストレス無く共有できてます。

ただ、同期のタイミングによって、昨晩自宅で編集したものを
翌朝会社で編集しているとかで、コンフリクトが発生することは時折起こります。
ですので最低限、２倍の空きの確保が必要なのは何ともしがたいですね。

Re:暗号化されてないならすれば良いじゃない

[haratake (365)]

> DropBox & TrueCrypt を実際にやっておりますが、
> どうもアップロード速度から判断する限りは差分のみ送っているようなので

差分を作るには、比較対象の元ファイルと現在のファイルの二つが必要です。

そして、誰が差分を作るかですが、クライアントとサーバーのどちらかになりますが、
サーバーだとしたら、現在のファイルはクライアントにアップロードしなければ、
差分を作ることが出来ません。
もし、クライアントだとしたら、元ファイルが必要です。元ファイルがクライアントにあるのでしょうか？

Re:暗号化されてないならすれば良いじゃない

[ikotom (20155)]

差分を作るには、比較対象の元ファイルと現在のファイルの二つが必要です。

確かに。
一応クライアント側にキャッシュフォルダはあるようですが、.svn みたいにオリジナルを保持しているようには見えませんね。

私が想像したのは、
例えば大きいファイルを分割してクライアント側でブロック別にハッシュ値を計算するなどすれば、
差分を取るのに必ずしもsrc-dest両方の全バイトが必要ではないですよね。
もともとDropBoxは差分を記憶するVC機能も有しているので、こういった仕組みを用いている可能性はあるか、
といったところです。
が、今回の騒動を見るとあんまり凝ったことはしてない可能性の方が高いかなとも思います。

Re:暗号化されてないならすれば良いじゃない

[s02222 (20350)]

>差分を作るには、比較対象の元ファイルと現在のファイルの二つが必要です。

クライアントにある最新のファイルを適当なサイズのブロックに分割、各ブロックのハッシュをサーバに送る、サーバ側でブロック毎のハッシュと元ファイルの対応部分のハッシュを比較、変更のあったブロック番号をクライアントに通知、その部分だけアップロード、みたいな戦略もあり得るかと。

Re:

[Anonymous Coward]

暗号化ドライブ内のファイルを1ビットでも変更すると、TrueCryptのイメージファイル全体が変更されると思ってるんじゃないですか? いくらなんでもそこまで局所性のない設計にはなっていないと思っているんですが(安全性は高いかもしれませんが書き込みが遅すぎて使いものになりませんよね)。