アカウント名:
パスワード:
確かDropboxも嘘がバレる [srad.jp]まではそんなことをほざいていたような。
リンク先ストーリーのこれ。http://security.srad.jp/comments.pl?sid=532506&cid=1954849 [srad.jp]クラウド会社やその他の第三者に見られて困るデータを預けることの意味から見直すべきかと。
銀行の貸し金庫に貴重品を預けるとか頭おかしいですよね。自宅のタンスにでも隠しておいたほうが安全に決まってるのに。# どうしてデジタルの話になった途端にここまで目が曇るんだろう
たとえが突飛すぎて皮肉かマジかわかりにくい
#2453365 に同意なので、部外秘資料を閲覧可能な状態で、他人に預ける奴はそりゃあマジで大馬鹿野郎だよと同意して反応を伺ってみる。
だから前もって暗号化しようというのがこのサービスなわけだね
そりゃストーリーはそうだけど、このスレッドはDropboxから始まる、預けた相手にデータを見られる想定の話よ。
こういうのよりも、手元で暗号化して、各種の普通のクラウドストレージとかのAPIに対応してるツールを作った方がいいような。というか手動で似たようなことしてるけど。
今のところの定番はDropBox上にTrueCryptで暗号化したコンテナファイルを置き、作業時は仮想ドライブをマウントですかね。
それを複数のPCで同時にやると整合性が取れなくなって個別のコンテナが出来てしまうのが難点。どのコンテナに目的のバージョンのファイルがあるか調べるのが面倒になったのは俺だけではあるまい。
.emacs.dの同期のはずが結局PC毎に違うものになるとか、いったい何をしてるのやらw
暗号化gitが有れば…リポジトリがクローンされてもblobオブジェクトが復号されなければ助かる可能性高そう。ファイル名などのメタデータから漏れる情報は諦める。
http://git-annex.branchable.com/encryption/ [branchable.com]"Encryption is needed when using special remotes like Amazon S3, where file content is sent to an untrusted party"これなんてまさしこうそういう用途なんだろうな。
ツールの信頼性はどう担保するの? 作った人を無条件に信用するならそれがクラウドサービスの提供者自身でも同じことじゃないの?
鍵をID等のサーバーに記録されたデータから生成するとしたら、IDと計算式を知っている人(=運営)なら暗号化を解除できるはず。その場合は「鍵を持つユーザーのみが暗号化を解除できる」自体が成立しない。公式サイトを見た限りでは、鍵をユーザーが指定する形式には見えなかった。
あるいは、サーバーをクラックしたついでに偽クライアントを配布するとか。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
鍵を持つユーザーのみが暗号化を解除できる (スコア:0)
確かDropboxも嘘がバレる [srad.jp]まではそんなことをほざいていたような。
Re: (スコア:0)
リンク先ストーリーのこれ。
http://security.srad.jp/comments.pl?sid=532506&cid=1954849 [srad.jp]
クラウド会社やその他の第三者に見られて困るデータを預けることの意味から見直すべきかと。
Re: (スコア:0)
銀行の貸し金庫に貴重品を預けるとか頭おかしいですよね。自宅のタンスにでも隠しておいたほうが安全に決まってるのに。
# どうしてデジタルの話になった途端にここまで目が曇るんだろう
Re: (スコア:0)
たとえが突飛すぎて皮肉かマジかわかりにくい
Re: (スコア:0)
#2453365 に同意なので、
部外秘資料を閲覧可能な状態で、他人に預ける奴はそりゃあマジで大馬鹿野郎だよと同意して反応を伺ってみる。
Re: (スコア:0)
だから前もって暗号化しようというのがこのサービスなわけだね
Re: (スコア:0)
そりゃストーリーはそうだけど、このスレッドはDropboxから始まる、預けた相手にデータを見られる想定の話よ。
Re: (スコア:0)
こういうのよりも、手元で暗号化して、各種の普通のクラウドストレージとかのAPIに対応してるツールを作った方がいいような。
というか手動で似たようなことしてるけど。
Re: (スコア:0)
今のところの定番はDropBox上にTrueCryptで暗号化したコンテナファイルを置き、
作業時は仮想ドライブをマウントですかね。
Re: (スコア:0)
それを複数のPCで同時にやると整合性が取れなくなって個別のコンテナが出来てしまうのが難点。
どのコンテナに目的のバージョンのファイルがあるか調べるのが面倒になったのは俺だけではあるまい。
.emacs.dの同期のはずが結局PC毎に違うものになるとか、いったい何をしてるのやらw
Re:鍵を持つユーザーのみが暗号化を解除できる (スコア:1)
暗号化gitが有れば…
リポジトリがクローンされてもblobオブジェクトが復号されなければ助かる可能性高そう。
ファイル名などのメタデータから漏れる情報は諦める。
屍体メモ [windy.cx]
git-annex encryption (スコア:1)
http://git-annex.branchable.com/encryption/ [branchable.com]
"Encryption is needed when using special remotes like Amazon S3, where file content is sent to an untrusted party"
これなんてまさしこうそういう用途なんだろうな。
屍体メモ [windy.cx]
Re: (スコア:0)
ツールの信頼性はどう担保するの? 作った人を無条件に信用するならそれがクラウドサービスの提供者自身でも同じことじゃないの?
Re: (スコア:0)
鍵をID等のサーバーに記録されたデータから生成するとしたら、IDと計算式を知っている人(=運営)なら暗号化を解除できるはず。
その場合は「鍵を持つユーザーのみが暗号化を解除できる」自体が成立しない。
公式サイトを見た限りでは、鍵をユーザーが指定する形式には見えなかった。
あるいは、サーバーをクラックしたついでに偽クライアントを配布するとか。
Re: (スコア:0)
少なくとも
1.ウェブブラウザ経由でアクセスできる
2.クライアントソフト・アプリに鍵を指定する項目がない
はユーザ側ではなくサーバ側に鍵がある証