問題タブ [aes-gcm]

GMAC のインターフェイスとして openssl EVP (EVP_aes_128_gcm) を使用しようとしています。NIST の CAVP GCM テスト ベクトル ( http://csrc.nist.gov/groups/STM/cavp/documents/mac/gcmtestvectors.zip ) に対してコードをテストしています。問題は、aad サイズが 16 の倍数の場合、コードが正しい GMAC タグを与えることができることです。しかし、サイズが 16 の倍数でない場合、結果は間違っています。何が問題なのですか？

コードは次のとおりです。

テスト ベクトル (コードのコメント セクション) の場合:

出力がおかしい…

テスト ベクトルの場合:

出力は正しいです：

私が使用しているバージョンは次のとおりです。 OpenSSL 1.0.1 2012 年 3 月 14 日

初めて AES-GCM を実装しようとしているときに、AuthenticationTag の生成で問題に直面しており、暗号化された暗号と GCM の MAC チェックが最終的に失敗します。現在の実装tag[]は移入されていますが、byte[] encrypted空のままです。そして、これcipher.doFinal(data1, offset)により ' mac check in GCM failed' が得られます。バイト配列のサイズに関する問題のようですが、出力バッファのサイズをどのような基準で決定する必要があるかを教えてください。これはチャンクで行う必要がありますか？

AES-GCM実装へのポインタ/リンクは高く評価されます。

以下は私たちの実装です：

次の例外が発生します。

前もって感謝します！！

学習目的で、単純な AES-256-GCM 暗号化と復号化を実装しました。文字列の長さを 6 の倍数で入力した場合にコードをテストすると、正しい出力が得られますが、それ以外の場合は、復号化されたデータにガベージ文字が追加されます。

今、私はhttps://www.openssl.org/docs/crypto/EVP_EncryptFinal_ex.htmlを読みました

しかし、この場合、パディングはデフォルトで有効になっているため、問題は最終ブロックの正しいフォーマットにあると推測しています。以下にコードを添付しました。

暗号を使用しているTLS 1.2セッションを復号化する Java プログラムに取り組んでいますTLS_RSA_WITH_AES_128_GCM_SHA256。Wireshark を使用してテスト セッションを記録しました。マスターシークレットが判明。

Packet 11HTTP GET Request 復号化しようとしているが含まれています。

握手データ:

パケット 11 データ:

私がこれまでに行ったこと：

キーの派生:

Client->Server パッケージを復号化したいので、ここでは Client キーのみが必要です。サーバーとクライアントのキーと IV を RFC に従って拡張しました。 Client Write Key: 4B119DFBFC930ABE130030BD53C3BF78 Client Write IV: 2029CAE2

ノンス:

Salt (= Client Write IV) と明示的なナンス (= 暗号化されたデータの最初の 8 バイト) から AES-GCM ノンスを作成します。 Salt: 2029CAE2 explicitNonce: C91DE005E2AE50A8 Nonce: 2029CAE2C91DE005E2AE50A8

追加の認証データ (AAD):

これはどうやら私が行き詰まったところです。RFC5246 は次のように述べています。

additional_data = seq_num + TLSCompressed.type + TLSCompressed.version + TLSCompressed.length; ここで、「+」は連結を示します。

だから私はこれを作った：

1だと思います。レコードが送信seq_noされると、ゼロにリセットされます。Change Cipher Spec( Packet #8) 次に、暗号化されたFinishedレコードにはseq_no = 0. 次のクライアント パケットはPacket #11 withseq_no = 1です。

コード：

今、すべてを BouncyCastle にフィードしています。

これは常にMAC failed: mac check in GCM failedをスローします。しかし、復号化された出力は正しいです:

これは印刷されGET / HTTP/1.0\nます。

解凍ヘルパー:

結論: 復号化された出力は正しいので、鍵の導出と復号化が正常に機能していると安全に想定できます。認証のみが失敗します。したがって、追加の認証データ (AAD) で何か問題が発生している可能性があります。したがって、この質問は次のように要約されます。

追加認証データ (AAD) はどのように正しく組み立てられますか?

ありがとうございました！

PHP エンジン バージョン 5.4.34 を実行している共有 Web ホスティング アカウントで以下を実行する必要があります。(つまり、サードパーティのライブラリをインストールできません。)

バイナリ文字列にGalois/Counter Mode (GCM) 認証暗号化 ( AES標準)を実装する標準機能はありますか?

Crypto++ を使用してテキストを暗号化しようとしています。前回は AES CTR を使用したときはうまくいきましたが、CBC または GCM を使用する場合、使用できるキーの最大長は 32 ビットですか??

暗号化を処理するコード:

この Crypto++ を実行すると、次のものがスローされますException。

Wiki で提供されている example.zip を使用する場合 (およびキーの長さを 256 または 128 に変更する場合) に同じことが起こることに注意してください。

Exceptionがスローされている理由はありますか？

これが私のコードです：

暗号化されたメッセージを取得しましたが、復号化しても結果もエラー メッセージも表示されません。同じコードが、aes-256-cbc などの別の方法で機能しています。

そのため、CBC と GCM のさまざまな AES 実装を広く探していました。間違いを犯した場合に備えて、これを自分で実装したくないので、次の AES CBC コードを見つけて、RX63NB でそれらの速度をテストしました。 （レンネサスのテストボード）。

Cyclone の方がはるかに高速であることに驚きました。明確にするために、CycloneSSLから AES、CBC、および Endian ファイルを取得し、それらのみを使用しました。

次に、CycloneSSl から GCM を試したところ、次の出力が得られました。

HMAC 時間 (CycloneSSL から) を調べて、どれくらいかかるかを確認しました。

最も遅いのはワールプールです。

128 バイトの whirlpool の hmac に 128 バイトの cbc 暗号化時間を追加すると、GCM の約半分の時間である 6795 μs が得られます。

これで、galios フィールドなどのために GHASH は HMAC よりも少し時間がかかることを理解できましたが、私が知っている最も遅い HASH アルゴリズムと比較して 2 倍遅いことは正気ではありません。

それで、私が何か間違ったことをしたのか、それとも CycloneSLL gcm 実装が本当に表示されているのか疑問に思い始めました。残念ながら、C での他の使いやすい GCM 実装を見つけて比較することはできませんでした。

私が使用したすべてのコードは pastebinにあります。異なるファイルは -------------------- で区切られています

これは、GCM で暗号化するために使用するコードです。

out[] のデータは、in[] からの gcm 暗号化データであり、すべて正常に機能します。(正しく復号化し、認証に合格します。

質問

• すべての GCM 実装はこれほど遅いのでしょうか?
• 他の (より良い) GCM 実装はありますか?
• 高速な暗号化と検証が必要な場合は、HMAC を使用する必要がありますか?

編集

mbedTLS (PolarSSL)から GCM メソッドを動作させることができました。これはサイクロンよりも約 11 倍高速です (128 バイトの暗号化/復号化に 880us かかります)。それは cylcone GCM と同じ出力を生成するので、これが適切に機能すると確信しています。