問題タブ [aes]

AES 暗号化 (.net フレームワーク) では、公開鍵と秘密鍵はどのように使用されますか?

公開鍵と秘密鍵を組み合わせて完全な鍵を形成し、アルゴリズムは公開鍵と秘密鍵を使用してデータを暗号化しますか?

(以下では、例として簡略化されたキーを使用しています)

例: 公開鍵 = 12345 秘密鍵 = 67890

したがって、暗号化結果を生成するときに使用されるキーは次のとおりです: 1234567890

AES 128 ビット暗号化を使用したきれいな例が見つからないようです。

誰かサンプルコードを持っていますか?

new RijndaelManaged() の場合、ドキュメントによると、128 ビットおよび最大 256 ビットのキーをサポートしています。

new RijndaelManaged() をインスタンス化すると、キーと IV が作成されます。

デフォルトのサイズは 128 ビットですか?

インスタンスを作成すると、KEY と IV が生成されます。

キーをデータベースまたは web.config ファイルに保存するにはどうすればよいですか?
そして、どのような形式で？

明らかに、暗号化された文字列を復号化しようとするときにキーをロードする必要があるためです。

このトピックについて少し迷ってしまいました。

Rijndael 暗号化アルゴリズムは、次の例の 3 つのストリームを使用して .NET に実装されています: Rinjdael。

これらのストリームが何をしているのか誰か説明してもらえますか? それらはどのように/なぜ使用されますか?

Rijndaemanaged（）の暗号化された値を文字列に変換したいと思います。

ToBase64String（）で十分ですか？8ビットアレイ専用と書いてありますが、AESは128ビットでしょ？

アップデート

暗号化には、からのコードを使用していますhttp://msdn.microsoft.com/en-us/library/system.security.cryptography.rijndaelmanaged.aspx

PKCS#7 を暗号化された署名付きコンテンツのコンテナー形式として使用したいのですが、ISO 10126 ベースのパディングを使用して AES を CBC モードで使用する必要があります。この組み合わせに使用するアルゴリズム識別子への具体的な参照が見つからないようです。自分で発明することはできますが、そうすると他のツールとの相互運用性が失われます。

.NET 2.0 と C++ の両方で機能する、Microsoft が提供する標準の暗号化ライブラリが必要です。何を提案しますか？

AES は .NET 3.5 でのみ提供されている (そして C++ で利用可能である) ことがわかりました。

Rijndael は .NET 2.0 で使用されていますが、標準の C++ ライブラリでは使用できないことがわかりました。

私が間違っている場合 (非常に良い可能性があります)、正しい方向に私を向けることができますか?

最悪の場合、PInvoke を使用して .NET から Rijndael アルゴリズムを呼び出すことができると思いますが、むしろネイティブ ソリューションが必要です。

ブロックサイズが 16 バイトの AES 暗号を使用しています。

16 バイトの文字列を暗号化しようとしても問題はありませんが、16 の倍数ではない他の長さでは例外がスローされます。

3-DES では、パディング タイプをアルゴリズムの一部として指定でき、余分な作業なしで処理されることは知っています (DES/CBC/PKCS5Padding など) が、AES でこれを指定する方法はありますか?

それとも、手動で pytes を 16 の倍数にパディングしてから、復号化するときに削除する必要がありますか? 簡略化されたコード サンプルを次に示します。

すべての返信に感謝します。

前もって感謝します, シアラン

私は現在、商用の SFTP サーバーをセットアップしています。現在実装を考えているセットアップに関するいくつかの意見と、どの商用セキュア FTP サーバー ソフトウェアが最適かについての推奨事項を探しています。合う。私が担当しているデータは機密性が高いため、コメントやフィードバックは大歓迎です。

シナリオは次のとおりです。

1) ファイルをアップロードする前に、ファイルは AES 256 とソルトを使用して圧縮および暗号化されます。

2) クライアントのサーバーから SFTP (ポート 22) 経由で SFTP サーバーにアップロードされたファイル。

3) ファイルは、1 回限りのパスワード検証 (強力な 10 文字の英数字パスワード) を使用して、他のクライアントによって HTTPS 経由でダウンロードされます。

私が考えている実装の詳細は次のとおりです。

上記 (2) の場合、接続は、ホスト キーの照合、公開キー認証、およびユーザー名とパスワードの組み合わせを使用して開かれます。両側のファイアウォールは、クライアント サーバーの静的 IP のみが接続できるように制限されています。

パート (3) では、他のクライアントには、サーバー上の投獄されたアカウントにログインするための (監査用の) ユーザーごとのユーザー名/パスワードが提供されます。ファイル自体の暗号化パスワードはファイルごとに提供されるため、ここでは常に 2 つの暗号化モードを適用しようとしています (ファイルがサーバー上にある場合を除く)。

両側の専用ファイアウォールに加えて、SFTP サーバーのアクセス制御は、短時間に一定回数失敗した IP アドレスをブロックするように構成され、無効なパスワードの試行によりユーザーがロックアウトされ、パスワード ポリシーが実装されます。

可能な限りカバーしたと思いたいのですが、この実装について皆さんがどう思うか聞きたいです?

商用サーバー側については、SSH & HTTP モジュールまたは JSCAPE Secure FTP サーバーを使用した GloalSCAPE SFTP に絞り込みました。私もそれについて聞きたいです。