短い答えははいです。長い答えは "それは依存する"です。
「自分の鍵を計算する」とは、暗号鍵の生成を意味します。鍵の生成方法は、暗号化と復号化にthos鍵を使用するプロセスとはまったく関係ありません。
RijndaelがAES標準になる前にDcpCryptが書かれました(それはずっと前です)。プリスタンダードのRijndaelの実装がAESと同じであると仮定すると(おそらくそうである)、AESの暗号化/復号化の相互運用性は、実装オプションにのみ依存する言語と実装の中立でなければなりません。
しかし、これらのオプションを特定し、これらを暗号化コーデックと復号化コーデックの両方で同じに設定するのは難しい場合があります。
どのようなオプションがありますか?
- 連鎖モード。
- IV
- メッセージはどのように塩化されていますか?もしかして?
- 終了:AESは、非キーストリーミングチェーンモードのブロック方式を指定していません。
- 一般に、AES以外の暗号では、キーのエンコード方法の指定に問題があるかもしれませんが、これはAESには問題ありません。
暗号化プログラムが使用するすべてのオプションを特定したら、それらのオプションを暗号解除プログラムに適用する必要があります。この問題は、Rijndael/AESに固有の問題ではなく、すべての暗号に共通しています。
ちなみに、圧縮の目的で圧縮している場合、暗号化に続く圧縮は無意味です。 Zipは、内容がすでに最大限にランダムなファイル(暗号文など)を圧縮しません。
DcpCryptではなく、AESでTurboPower LockBox 3を使用して暗号化することをお勧めします。 Dave BartonのDCPcryptは当時は良好でしたが、標準では最新ではなく、安全にIVを管理していません。
LockBoxを使用する場合のオプションは何ですか? CBCモードでLockBox 3のAESコーデックを使用する場合、塩析とIVは、IVをナンスに設定してそれを事前に放出することによって管理されます。 1ブロックよりも長いメッセージの場合、ブロックは暗号文の盗聴によって実現されます。 1ブロックよりも短いメッセージの場合、連鎖モードは強制的に8ビットCFBになります。これはキーストリーミングです。
また、SHA256でファイルを暗号化することについてのあなたのコメントは意味をなさない。 SHAはハッシュであり、暗号ではありません。
はい、そうです。最悪の場合:C#から呼び出すことができるDelphi DLLを作成し、それを復号化します。幸いにも、C#用の暗号化/復号化ソリューションがいくつかあり、ジッパー/アンジッピングでさえ問題にはなりません。私はちょうどあなたが使用できるものを知りません。 –