信頼できるLANでのownCloud暗号化はどの程度安全ですか？
Pascalのブログエントリにはいくつかの弱点があり、その一部は ownCloudの助言 で思い出されていますが、最悪のことは思い出されませんでした。
特に/tmpは多くのLinuxおよび* BSDオペレーティングシステムの真のディスクベースのディレクトリであるため、/tmpにファイルとして暗号化キーを保存することはすでにかなり悪いです（通常、/tmpを設定します）メモリベースのファイルシステムである必要がありますが、これはデフォルトではありません）。そのため、一部の暗号化キーは物理ストレージになります。また、ファイルを削除してもデータが消去されることはよく知られています。対応するブロックを再利用可能としてマークするだけです。新しいファイルがいくつか作成されるまで、データは上書きされません。したがって、電源が入っていないサーバーが盗まれた場合、一部のキーが漏洩することが想定されます。
最悪の弱点は鍵の生成です。パスカルはそれを次のように述べています：
全体的なエントロピーの計算、つまりキーを推測する作業は読者に任されています…言うまでもなく、達成可能な最大量の4 * logです。2（99999-10000 + 1）= 65.8ビットのエントロピー。これは、推奨される最小値である80ビットとはかけ離れています。
「65.8ビット」についてのビットは誤解を招くものです。つまり、ownCloudがキーを生成する方法は、その量の最大エントロピーを意味します...関係するPRNGは完璧ですが、完璧ではありません。65.8は、10000〜99999の範囲の4つの整数としてのキープロダクションに由来します。しかし、それらは、別のPRNGがシードされたメルセンヌツイスターPRNGに由来します。現在の時刻とスレッドIDからシードされます。時間はマイクロ秒に達します。攻撃者がその時刻を1秒の精度で知っていると仮定します。16ビットのスレッドIDも想定しています。これは、せいぜい36ビットのエントロピー。単なるPCが、最悪の場合、数時間でそれを回避します（暗号化は、かなり高価なキースケジュールを持つBlowfishを使用します） それは高価ではありません）。
もちろん、パスワードが含まれているため、パスワードを攻撃することはおそらくさらに簡単ですが、この低エントロピーの鍵生成は、大きくランダムなパスワードからの強化を防ぎます。これはかなり絶望的です。メルセンヌツイスターが適切なシードで適切な、暗号的に強いPRNG=に置き換えられた場合）（たとえば、単に/dev/urandomから読み取る）、他の弱点が深刻な懸念の原因となりますが、弱いシード切り札すべて。
これに対する私の解決策は、Linuxのファイルシステム暗号化（LUKS）を使用することです。必要に応じて、/ boot以外のサーバー上のすべてを暗号化できます。これには、ownCloudが保存するすべてのものが当然含まれます。 AES-256のようなものと適切なパスフレーズを使用すると、物理的な侵害によってデータの機密性が維持されます。これは、すべてのボックスでますます実行していることです。最新のマイクロプロセッサーの能力を考えると、暗号アクセラレーターがなくても、実際には速度低下はそれほど多くありません。
CentOSサイトからの以下のリンクは、これを行う方法を示しています。これらの手順は基本的に他のすべてのGNU/Linuxディストリビューションに適用されます（私は最初のSlackwareを使用しました）。
http://wiki.centos.org/HowTos/EncryptedFilesystem
BSDで実行している場合は、ファイルシステムの暗号化もサポートしています。私はまだ試していないのですが、OpenBSDからのこれはあなたが始めるべきです。 OpenBSDは、ソフトRAIDユーティリティを使用して、ソフトウェアRAIDだけでなく、パーティション全体の暗号化も行います。
http://www.openbsd.org/cgi-bin/man.cgi?query=softraid&sektion=4
お役に立てれば、
--SYG