問題タブ [block-cipher]

Crypto++ v5.6.2用の C++ ラッパー ライブラリを実装しましたが、対称アルゴリズム (Blowfish など) とブロック モード (GCM など) の組み合わせについて質問があります。

Blowfish/EAX を介してデータを暗号化および復号化できますが、Blowfish/GCM を使用して同じことを行うことはできません。AES/EAX と AES/GCM の両方が機能します。

次の簡単なアプリケーションは、私の問題を示しています。

上記のCryptoPP::InvalidArgumentコードを次のテキストで実行すると、例外がスローされます。

ただし、代わりにブロック モード EAX を使用してコードを実行すると、例外はスローされません。だから私の質問は：

• GCM は AES でのみ動作しますか? GCM は Blowfish や 3DES でも使用できますか?
• 対称アルゴリズムとブロック モードのすべての可能な組み合わせをリストしたマトリックスはありますか?
• または、これは Crypto++ のバグですか? メソッドBlockSize() は常に戻ります0が、AES の代わりに Blowfish (または 3DES) を使用する場合にのみ例外が発生するためです。これにより、言及された例外が発生するようです。

このキーは 16 進文字列で与えられ"140b41b22a29beb4061bda66b6747e14"、ECB を実装する AES で 1 ブロック暗号を解読するように要求されました。

ご存知のように、キーの長さは 16 バイトでなければなりません。ただし、指定されたキーには、1 バイトより大きい文字に対応する要素が含まれています (たとえば0xb2、char 値が²2 バイトに対応する)。

実際、16 進文字列キーを取得したキー文字列に変換すると" A²*)¾´Úf¶t~ "、メソッドを適用するkey.getBytes().lengthと、キーの長さが 21 バイトであることがわかります。

私の質問は: Java でこのキーを指定して、16 バイト長の暗号文を AES で暗号化する方法はありますか?

暗号文を解読するために、このコードを Java で記述しました。私は鍵を持っています。私にはすべてが正しいように思えますが、説明する問題があります。
これが私のコードです：

以下のエラーが表示されます。

何がうまくいかないのですか？問題が何らかの形でパディングに関連していることは知っていますが、正確な解決策はありません。暗号文、IV、およびキーが 1 つだけあります。

私は暗号化の分野に不慣れだと言って始めましょう。そうは言っても、私はアプリケーションを開発しており、データベーステーブルに暗号化されたユーザー名、パスワード、およびフルネーム (名、ミドル、ラスト) を保存する必要があります。IV は発生する暗号化ごとにランダムにする必要があり、IV を暗号文の先頭に追加できるという記事を読んでいました。

ここがややこしいところです。文字列のどこで IV が終わり、暗号文が始まるか正確にわからない限り、文字列の先頭にテキストを追加すると、どのように文字列を復号化できますか? また、実際に暗号化する前に、追加のテキストを追加または追加して文字列をソルトする必要があることを読んでいました。IE、私が作成し、それをプレーンテキストに追加または追加する文字列、ソルティングの理解は正しいですか?

暗号化されたユーザー名とパスワードをデータベースに保存している場合、ユーザーを認証する必要があるときに問題を心配する必要があります。ユーザーがフィールドに入力した後にユーザー名とパスワードを確実に暗号化し、暗号化された値をデータベース内の暗号化された列と比較できますか? これが問題になると思われますが、もしそうなら、これを処理するための推奨される方法は何ですか?

ECB 暗号モードと Threefish 対称ブロック暗号を使用して、.NET で文字列を暗号化および復号化しています。その実装は、プロジェクトに .dll として添付されています。.NET 実装へのリンクは次のとおりです。

キーのサイズはブロック サイズと同じで、私の場合は 256 ビットです。

問題は、私が理解している限り、入力文字列、平文の長さは暗号文の長さと等しくなければならないということです。それともしなければなりませんか？たとえば、私の場合、ASCII エンコーディングを考慮すると、平文は各ブロックに 32 文字を含むブロックに分割されますが、各ブロックには常に 12 文字の暗号文が追加されていることがわかりました。つまり、暗号文の長さ = 最初のテキストの長さ + 12*n、ここで n はテキストのブロック数、つまり str.Length/32 (str - 最初の文字列、32 の倍数になるように既にパディングされています) .

私のコード (以下) にエラーがありますか、または複雑な .NET 暗号化システムではこのルールが満たされないのに対し、暗号化に XOR 操作のみを使用する非常に単純なブロック暗号の場合にのみ私の理解は有効ですか? 後者の場合は、実際にこれらの長さが異なる理由を説明してください!!! 前もって感謝します。

私の会社は、カードリーダーを現場に置くプロジェクトに取り組んでいます。リーダーは DUKPT TripleDES 暗号化を使用するため、サーバー上のカード データを復号化するソフトウェアを開発する必要があります。

私はこの問題の表面をなぞり始めたばかりですが、一見単純な問題に行き詰まっていることに気付きます... IPEK を生成しようとしている (対称鍵を再作成するための最初のステップ)。

IPEK は、2 つのトリプル DES で暗号化された 8 バイトの 16 進文字列を連結して作成された 16 バイトの 16 進値です。

パディングの有無にかかわらず、ECB および CBC (IV のゼロ) モードを試しましたが、入力と同じサイズの結果が必要な場合、個々のエンコーディングの結果は常に 16 バイト以上 (2 ブロック以上) になります。実際、このプロセス全体を通して、暗号文はエンコードされる平文と同じサイズである必要があります。

結果: 3C65DEC44CC216A686B2481BECE788D197F730A72D4A8CDD

NoPadding フラグを使用すると、結果は次のようになります。

3C65DEC44CC216A686B2481BECE788D1

また、平文の16進メッセージをbase64としてエンコードしようとしました（キーがそうであるように）。上記の例では、次の結果が返されます。

DE5BCC68EB1B2E14CEC35EB22AF04EFC。

NoPadding フラグを使用する以外は同じことを行うと、「入力長が 8 バイトの倍数ではありません」というエラーが表示されます。

私は暗号化に慣れていないので、ここで非常に基本的なエラーを犯していることを願っています。これらのブロック暗号アルゴリズムによって生成された暗号文が平文メッセージと同じ長さでないのはなぜですか?

もう少し背景を知るために、「それを実行する」演習として、ここで説明されている作業を複製しようとしました。

https://www.parthenonsoftware.com/blog/how-to-decrypt-magnetic-stripe-scanner-data-with-dukpt/