問題タブ [aescryptoserviceprovider]

私の質問によると、Aes Encryption ...重要な部分が欠けていますが、文字列に可逆暗号化を作成するという私の仮定が少しずれていることを学びました。私は今持っています

これにより、一貫した結果が得られます。ただし、初期化ベクトルを知らない/設定しないと復号化できません。このメソッド（IVの場合はオン）に3つの値を渡したくないので、IVをハードコーディングしたり、キーから派生させたりする必要があります。これが良い習慣なのか、それとも暗号化された値が何らかの形で攻撃に対して脆弱になるのかを知りたいのですが...それとも私はこれを本当に考えすぎて、IVをハードコーディングする必要がありますか？

更新 イリジウムの提案に従って、私は代わりに次のようなものを試しました：

ただし、これは私の単体テストで奇妙なことを示しています。

復号化されたテキストは「92ʪ�F」と表示されます。hpv0��暗号化しています。似たようなものはたくさんありますが、これは私の暗号化です。」これはほぼ正しいように見えますが、もちろん完全に間違っています。しかし、私は近くにいるようです。メモリストリームのオフセットが欠落していますか？

私はAESで暗号化/復号化を試みていました.CBCモードとECBモードを試しましたが、3つすべてから同じ暗号化された出力が得られました! これはどうですか？
それは間違っていないかもしれませんが、私は何を期待すべきかわかりません。そして、それらがすべて同じ暗号を生成する場合、モードを持つことのポイントは何ですか? それは時間ですか、それともパフォーマンスの複雑さですか?

AES とその暗号モードの違いを説明できますか? デフォルトの暗号モードは何ですか? または、MSDNが十分に明確ではないため、参考文献を教えていただければ

ありがとうございました

だからここに私の混乱があります。ランダムなUnicode文字を返します。両方のメソッドに同じキーと同じIVを使用し、両方に同じエンコーディングを使用しています。ランダム応答の原因は何ですか？

私は Windows Phone 開発の初心者です。WP7 で AES/ECB/PKCS7Padding アルゴリズムを使用するにはどうすればよいですか?

グーグルで検索しているうちに、バウンシー キャッスルについて多くの提案が寄せられました。しかし、この弾む城についてはよくわかりませんでした。これはアルゴリズムですか？

サーバーに送信するためにパスワードを暗号化/復号化する必要があります。他のすべての電話 (Android、iPhone、Blackberry) では、これに AES/ECB/PKCS7Padding アルゴリズムを使用します。それらはすべて、入力に対して同じ暗号化/復号化結果を提供します。しかし、Windows Phone では、暗号化に AesManaged クラスを使用しました。ただし、暗号化された結果は異なります。AESManaged クラスに関するmsdn ドキュメント ( MSDN ドキュメント) では、「暗号モードは常に CBC であり、パディング モードは常に PKCS7 です」と述べています。他の電話と比較して、ここで暗号化された結果が異なるのはそのためだと思います。

それが問題ですか？その場合、WP7 で AES/ECB/PKCS7Padding アルゴリズムを使用するにはどうすればよいですか?

AesManaged クラスで暗号モードを設定するためのプロパティが表示されません。

ありがとう。

私はこの関数を使用して実行可能ファイルを復号化します：

しかし、この関数は文字列出力を返します。対応する復号化されたファイルのASCII出力を見ることができます。しかし、私はbyte[]出力を取得する必要があります。

私は多くのことを試みましたが、行き詰まっています：DecryptBytesToBytes関数が必要です

ECB と ZeroBytePadding で AES を使用してデータを暗号化する Android アプリがあります。その環境ではすべてが正常に機能します。次のように、暗号化されたデータは問題なく Android で復号化されます。

しかし、最近、Web アプリでデータを復号化することに決め、同じ decrypt() メソッドを使用しようとすると、Cipher.getInstance("AES/ECB/ZeroBytePadding") が例外をスローしました。

一部の Android ライブラリが、javax.crypto.Cipher にない適切な暗号プロバイダーを提供していると思います。他の誰かがこの問題を抱えていましたか、それとも私に何ができるか知っていますか? 以前のオプションですでに多くのメッセージが暗号化されているため、暗号パディングを PKCS5PADDING に変更することはできません。

AES を使用して暗号化と復号化を実行するために、AesCryptoServiceProvider を使用します。暗号化は機能しているようですが、復号化すると「パディングが無効であり、削除できません」という例外がスローされます。

これが私のコードです：

ユーザー/パスワードとその他のデータを保持するテーブルがあります。各レコードのパスワード フィールドは暗号化する必要があります。暗号化に AesCryptoServiceProvider を使用することにし、手動で rgbKey を 1 回作成しました。次に、すべてのユーザー パスワードを暗号化し、パスワード フィールドが rgbKey で暗号化されたテーブルにレコードを挿入しました。

ロード バランサーの背後に複数のサーバーがあり、各サーバーはこれらのレコードを読み取り、パスワード フィールドの値を復号化する必要があります。最初に、base64StringFormat の rgbKey を dll(API) に配置しました。同様に、すべてのサーバーがこの API を使用し、暗号化された値を復号化できます。

ただし、rgbKey を dll ファイルに保持するのは非常に安全ではありません。キーを DPAPI に保持するかどうかについて話し合いました。復号化時に、任意のサーバーで、DPAPI からキーを取得し、暗号化された値を正常に復号化します。

現在のユーザーモードのサーバーで一度だけ保護されたキーを生成し、それを共通のdllに保存できると思いました。共通のdllを使用する各サーバーは、この保護されたキー(byte[])を同じユーザーでDPAPIに与えると、保護されていないキーの値を取得できます。ただし、保護されているマシンでのみ機能し、他のマシンでは「指定された状態での使用に対してキーが無効です」というエラーが発生します。

私の質問は、永続的な rgbKey を保護して、すべてのマシンからアクセスできるようにするにはどうすればよいですか? 以下の同様のテスト コンソール アプリケーションを見てください。私のアプローチの何が問題なのですか?

テスト コンソール アプリケーションのサンプル コードを示します。

まず、ローカル マシンで PDPAPI() 関数を実行します。

次に、上記の実行から取得した UDPAPI() 関数の base64ProtectedData 値をハードコーディングして追加し、ソリューションを再構築します。

ローカル マシンで UDPAPI() 関数を実行すると、データの保護が正常に解除されますが、コンソール アプリケーションを他のサーバーに移行し、ネットワーク ユーザーでそのサーバーにログインすると、コンソール アプリケーションで「Key not valid for指定された状態で使用してください。」

私は暗号化の初心者です。私の要件は、openssl を使用して暗号化/復号化されたテキストを復号化/暗号化することです。私たちが使用しているアルゴリズムは、Openssl の aes-256-cbc です。そのため、アプリケーションに同じ機能を実装しようとしています。これまでのところ、たくさんのグーグル検索の後、私ができたのは..

私のopensslコマンドは

私のキーの長さは 32 桁で、iv は 16 桁です

サンクス...