web-dev-qa-db-ja.com

AES暗号化に最適な暗号モードとパディングモードはどれですか？

PCI-DSS 3.4要件に従って：

クレジットカードデータの保存には強力な暗号化を使用する必要があります。

私は、クレジットカードの詳細を暗号化するための強力でほとんど推奨される暗号であるAES暗号化を使用することにしました。

AESには暗号モードとパディングモードが含まれていることがわかりました。

検索したところ、 NIST Special Publication 800-38A に従って、対称鍵暗号アルゴリズムの5つの機密動作モードが指定されていることがわかりました。

したがって、5つの暗号化モードのいずれかを使用できるのか、または以下にリストされている5つの暗号化モードのなかで最良のものがあるのか​​どうか、私は完全に混乱しています。

暗号モード：

  1. ECB
  2. CBC
  3. OFB
  4. CFB
  5. クリック率

5つの中で最高の暗号モードはどれですか？

また、AES暗号化に最適なパディングモードはどれですか？

encryptionpci-dssaescipher-selectionnist
26
RajeshKannan

「ベスト」はかなり主観的です-それはあなたの要件に依存します。とはいえ、各モードの概要を説明します。

[〜＃〜] ecb [〜＃〜]-電子コード帳。このモードは最も単純で、各ブロックを個別に変換します。キーといくつかのデータが必要ですが、追加機能はありません。残念ながらそれはひどいです-初めに、同じ鍵で暗号化されるとき、同一の平文ブロックは同一の暗号文ブロックに暗号化されます。ウィキペディアの 記事 は、この失敗をグラフィックで表現しています。

良い点：非常にシンプルで、暗号化と復号化を並行して実行できます。

悪い点：恐ろしく安全ではない。

[〜＃〜] cbc [〜＃〜]-暗号ブロックキャンニング。このモードは非常に一般的で、かなり安全であると考えられています。平文の各ブロックは、変換される前に暗号文の前のブロックとXOR演算されます。これにより、同一の平文ブロックが順番に並べられたときに同一の暗号文ブロックが生成されないようにします。プレーンテキストの最初のブロック（前のブロックはありません）では、代わりにinitialization vectorを使用します。この値は、メッセージごと、キーごとに一意である必要があります。これにより、同一のメッセージによって同一の暗号文が生成されることがなくなります。 CBCは、SSL/TLS暗号スイートの多くで使用されています。

残念ながら、CBCに対する一連の強力な整合性および信頼性チェックが実装されていない場合、CBCに対する攻撃があります。それが持つ1つのプロパティは、ブロックレベルの可鍛性です。つまり、攻撃者が暗号文をいじることができる場合は、メッセージの平文を意味のある方法で変更できますキーを知らなくても。そのため、実装には通常、HMACベースの認証レコードが含まれます。ただし、HMACと暗号化を実行する順序でも問題が発生する可能性があるため、これは扱いにくいテーマです。件名の詳細については、「MACの暗号化」を参照してください。

良い点：適切に使用すると安全で、並列復号化。

悪い点：並列暗号化がなく、真正性チェックが悪い/欠落している場合、展性攻撃の影響を受けやすい。しかし、正しく行われると、それは非常に良いことです。

[〜＃〜] ofb [〜＃〜]-出力フィードバック。このモードでは、基本的にストリーム暗号を作成します。 IV（一意のランダムな値）は暗号化されてキーストリームの最初のブロックを形成し、次にその出力は平文とxorされて暗号文を形成します。キーストリームの次のブロックを取得するために、前のキーストリームのブロックは同じキーで再度暗号化されます。メッセージの全長に対して十分なキーストリームが生成されるまで、これが繰り返されます。これは理論的には問題ありませんが、実際にはその安全性について疑問があります。ブロック変換は、一度実行すると安全になるように設計されていますが、E（E（m、k）、k）が独立して安全なすべてのブロック暗号に対して安全であるという保証はありません-間に奇妙な相互作用があるかもしれません適切に研究されていない内部プリミティブ。部分的なブロックフィードバックを提供する方法で実装した場合（つまり、前のブロックの一部のみが前方に購入され、残りの半分には静的または弱いランダム値が含まれる）、短いキーストリームサイクルなどの他の問題が発生します。一般に、OFBは避けてください。

良い点：キーストリームを事前に計算でき、高速なハードウェア実装が利用可能

悪い点：セキュリティモデルに問題がある、一部の構成ではキーストリームサイクルが短くなる

[〜＃〜] cfb [〜＃〜]-暗号フィードバック。 CBCと非常によく似た別のストリーム暗号モードは、逆方向に実行されます。その主な利点は、暗号化トランスフォームnot復号化トランスフォームのみが必要であることです。これにより、小さなデバイス用のコードを記述するときにスペースを節約できます。それはちょっと変わったボールであり、頻繁に言及されることはありません。

良い点：小さなフットプリント、並列復号化。

悪い点：一般的に実装または使用されていません。

[〜＃〜] ctr [〜＃〜]-カウンターモード。これは本質的に、キーストリームを生成するためにナンス（number used once）が前に付けられた一連の増分番号を暗号化することを含み、これもストリーム暗号モードです。このモードは、OFBモードで見たように、相互に変換を繰り返し実行する問題を取り除きます。これは一般的に良いモードと考えられています。

良い点：正しく行われた場合の安全性、並列の暗号化と復号化。

悪い点：多くはありません。 「関連する平文」モデルの安全性に疑問を投げかける人もいますが、それは一般的に安全であると考えられています。

パディングモードは注意が必要ですが、一般的には常にPKCS＃7パディングをお勧めします。これには、パディングの長さを表すバイトを追加することが含まれます。 04 04 04 04 4つのパディングバイト、または03 03 03 3人用。他のいくつかのパディングメカニズムに対する利点は、パディングが破損しているかどうかを簡単に判別できることです。パディングが長いほど、ランダムデータが破損する可能性が高くなりますが、パディングの長さのコピー数も増加します。検証して削除するのも簡単です。パディングが壊れて実際に正しいと検証される可能性はありません。

一般に、CBCまたはCTRを使用し、必要に応じてPKCS＃7を使用し（ストリーム暗号モードでのパディングは不要）、暗号テキストで認証チェック（HMAC-SHA256など）を使用します。 CBCとCTRはどちらもNiels FergusonとBruce Schneierから推薦されており、どちらも暗号学者として尊敬されています。

そうは言っても、newモードがあります！ [〜＃〜] eax [〜＃〜] および [〜＃〜] gcm [〜＃〜] は最近多くの注目を集めています。 GCMはTLS 1.2スイートに組み込まれ、CBCおよびストリーム暗号に存在していた多くの問題を修正しました。主な利点は、どちらもauthenticated modeであり、個別に適用する必要がなく、暗号モード自体に認証チェックを組み込むことです。これにより、Oracle攻撃のパディングやその他のさまざまなトリックに関するいくつかの問題が修正されます。これらのモードは説明するのが簡単ではありませんが（実装は言うまでもなく）、非常に強力であると考えられています。

53
Polynomial