OwnCloudのように、秘密鍵と公開鍵をサーバー上の同じディレクトリに保存することをお勧めしますか？
これは推奨された方法ですか、それとも通常の方法ですか？私はそうは思いません。
OwnCloudがすべての暗号化キーをサーバー上の1つのディレクトリに保存しているのを見ました。 1つのディレクトリには、秘密鍵とすべての公開鍵が含まれています。
しかし、彼らの文書は彼らの暗号化について述べています：「しかし、それはユーザーのファイルを回復する唯一の方法なので、このパスワードを決して紛失しないように注意すべきです。」
doc.owncloud.org/server/6.0/admin_manual/configuration/configuration_encryption.html
これは完全に間違っており、専門家ではないようです。
それとも、両方がそこに保存されている理由はありますか？
https://github.com/owncloud/core/blob/master/apps/files_encryption/lib/util.php#L6 すべてのキーは、特別なキーディレクトリではなく、メインデータディレクトリにありますそうしないと
公開鍵は、セキュリティに影響を与えることなく任意に配布できます。 公開鍵と秘密鍵の保存は完全に適切です –たとえば、OpenPGPは同じことをしています。少なくともLinuxでは、X.509証明書を/etc/sslのサブフォルダーに保存しています。これにより、適切な管理が少し簡単になります。しかし、秘密鍵にアクセスできるようになると、公開鍵の場所（「角を曲がったところ」）がわかります。
問題は次のとおりです。秘密キーを保存する場所。最後にサーバーがキーにアクセスする必要があります。別の場所にキーを保存する場合は、ソフトウェアがキーを見つけられるようにする必要があります（攻撃者もキーを見つけることができます）。サーバーを信頼しない場合は、とにかく失われます。
データを別の信頼できないサードパーティに保存する（Dropbox、Amazon EWSなど）の場合、サーバー側の暗号化が役立ちます。 信頼できるサーバーがデータを暗号化します。3番目に見えるのは暗号化されたデータです。
クライアント側の暗号化を使用すると、サーバーに秘密鍵を保存する必要がなくなります。ただし、これは、クライアント側の暗号化を認識しないWebDAV、CalDAV、CardDAVなどの標準を使用するアプリケーションに影響を及ぼします。これが、owncloudが行うことは、秘密キーをユーザーのパスワードで（対称的に）暗号化することだけである理由です。これは、使用されるプロトコルに関係なく、誰かが接続するとすぐにシステムによって常に認識されます。
公開鍵はそこに保存しても問題ありません。それが彼らが公開されている理由です。とにかく、秘密鍵を分離し、他の誰もそれらにアクセスできないようにする必要があります。したがって、おそらくそれらを別のサーバーに格納することをお勧めします。
既存の非対称アルゴリズムでは、秘密鍵に公開鍵のコピーが含まれるか、効率的に再構築できます。したがって、秘密鍵がある場合、公開鍵もそこにあります。いずれにせよ、公開鍵は公開されているため、潜在的な攻撃者を含め、誰が最初にそれらを配置したかに関係なく、誰もがそれらを持っていると想定する場合があります。公開鍵と秘密鍵を「分離」しておくことは、実際には意味がありません。分離できるのは秘密データのみです。公開キーは、公開であるため、anythingと分離できません。
公開鍵はpublicであり、ディレクトリはそれらを公開する方法であるため、公開鍵をディレクトリに配置します。
ディレクトリがユーザーのプライベートデータのリポジトリでもある場合、そのディレクトリにプライベートキーがある可能性があります。Microsoft/ Active Directoryの世界では、ユーザーのローミングプロファイルと呼ばれます。特定のユーザーだけが自分のプライベートデータにアクセスできるように、適切なアクセス権を維持するのはディレクトリ次第です。秘密鍵ストレージは、パスワードベースの暗号化でさらに保護することもできます。
つまり、MicrosoftドメインのADサーバーは非常に機密性の高いハードウェアであり、攻撃者から保護するほうがよいということです。これは、OwnCloud、またはユーザーの機密データを保存するその他のシステムにも当てはまります。システムのコア機能が実際にそのような機密データをローミングユーザーが利用できるようにする場合、これは避けられません。