GCM（Galois / Counter Mode）は、特にAESと組み合わせて、長年にわたって事実上のゴールドスタンダードとなっています。暗号化と認証を1つのステップで実行できます。これはすごすぎます。また、AEADのような用語は、女の子を感動させるのに適しているため、Win-Winになります。しかし、冗談はさておき…
何がそんなに特別なのかといつも思っていましたが、考えれば考えるほど理解できなくなります。それを見ると、全体的な魔法はそれほど素晴らしいものではありません。あるいは、私は愚かすぎてそれを理解できないかもしれません（したがって私の質問です）。
私の考え：
まず、GCMはカウンターモードの一種です。つまり、たとえば暗号ブロック連鎖。1つのブロックの出力は、入力の1つのブロックにのみ依存します。さらに悪いことに、1つのビットを変更すると、復号化された結果はそのビットで正確に異なります。正直なところ、カウンターモードのブロック暗号は”ブロック暗号”ではなく、（キー付き）PRNGであるためです。 XOR操作が続きます。基本的に、” blocky “ストリーム暗号。誰かがこれを悪用してメッセージを有害な方法で変更する可能性があるシナリオを想像するのにそれほど時間はかかりません（例：change ” transaction：+5,000 \ $ “から”トランザクション：-5,000 \ $ “）ブロック暗号には通常、完全なジブリッシュに変わるという固有の特性があります。 1ビットを反転すると（さらに、メッセージの残りの部分全体がチェーンされます）、これは実際には非常に優れた望ましいプロパティであり、正当な理由もなく船外に投げ出されました。
確かに、オーセンティケーターを使用します。 、改ざんが発見されるため、上記の攻撃を実行することは困難です。ただし、基本的に、オーセンティケーターは、操作モードの選択が導入されたという問題を修正するだけです。
GHASHは、追加の認証済みデータをサポートするMACです。私の知る限り、それは完全な嘘です。または、必要に応じて”楽観的な誇張”と呼んでください。 （非数学者にとって）直感的でない数学が背後にある圧縮関数ですが、最終的には単純な乗算と、”オーバーフロー”。これは、より平凡な計算で、1ダースサイクル内のブロックごとに2行のCコードで実行できることです（または、64ではなく32ビットの乗算を使用しても問題がない場合は、AVX2などを使用して並列に実行できます。」 ■最大4サイクルで2つの完全なブロックのvpmulld）。
IDEAをまだ覚えている人は、加算mod 2 16 と乗算mod2 16 +を使用したことを思い出すでしょう。 1は、リバーシブルであるという優れた特性を備えたSボックスです（復号化する場合は必要です）。残念ながら、2 32 +1がないため、これを32ビットに拡張することはできませんでした。素数であるため、すべての入力が比較的素数であることが保証されているわけではないため、操作を逆にするのに問題があります。しかし…この場合は問題ありません。必要ありません圧縮関数は反転可能です！つまり、”単純な”、通常の乗算でもうまくいくはずです。
つまり、その単純で、特別ではなく、魔法のない圧縮です。関数はキーとIVで初期化されるであるため、偶然に最終出力が何らかの方法でキーに依存するようになります。その通常の機能は事実上MACになります。 “追加データ”がある場合は、データを暗号化する前にハッシュにフィードするだけです。繰り返しになりますが、これは特別なことではありません。
全体として、他のすべてのハッシュ関数でも達成できなかったことは何もありません。
現在、ガロア/カウンターはカウンターモードが使用されていることを前提としています。カウンターモード（およびその派生物）とGHASHには、ブロックを並列に暗号化/復号化できるという利点があります。また、GHASHは簡単に並列化できます。
はい、パフォーマンス！しかし、正直に言うと、これは本当に利点なのか、それとも大きな欠点なのか？
ギガバイトまたはテラバイトサイズの復号化にかかる時間は重要ですか？メッセージ、そしてその作業をどれだけうまく並列化できますか？または、” “をランダムな位置にシークできるようにしたいアプリケーションはありますか？まあ、それが問題になるかもしれないアプリケーションが確かにあります。フルディスク暗号化が思い浮かびます。ただし、入力サイズと出力サイズを同じにしたいので、その場合はGCMを使用したくないでしょう。
ビジー状態のサーバー（またはVPN）の場合は、またはそう思われます。 ですが、多数の同時接続があるため、これらはとにかく何でも並行して処理できます。したがって、 1つのストリームを並列化できるかどうかは、全体的にはまったく違いはありません。接続が少ないアプリケーションはどうですか？通常、ログイン端末を介してテラバイトのデータを送信することはありません。送信する場合でも、7〜8年前のデスクトッププロセッサでもシングルコアのパフォーマンスがGbE帯域幅を簡単に上回ってしまうため、インターネット接続が制限要因になる可能性があります。 。
了解しました。ハードディスクに暗号化された2TB7zファイルを抽出するときは、2〜3秒長く待たなければならない場合があります（数千のディレクトリエントリを作成することがボトルネックではない場合、私はそうする傾向があります）去年の間にどれくらいの頻度でそれをしましたか？私：ゼロ回。
それが本当に違いを生むのはだけです。 div id = “035371e193”>
悪者”、つまり、簡単な生活を送りたくない人。案の定、簡単に並列化できれば、攻撃ははるかに簡単になります。問題のある場所に専用ハードウェア（GPU、FPGAなど）でいっぱいの部屋を投げて、それをすりつぶしてください。ノード間の通信は必要ありませんか？まあ、完璧です、それはこれ以上良くなることはできません。
これは本当に利点ですか？私にはわかりませんが、それは大きな欠点のように見えます。どちらかといえば、並列化をできるだけ難しくし、できるだけ簡単ではないようにしたいと思います。
それで…十分に熟考し、質問に答えます。
絶対に使用する必要があるほど素晴らしいGCMについて私が見逃している基本的なことは何ですか？
コメント
- しかし、
- i> “悪者” を定義することは不可能です。そして、それはこのフォーラムの政府の推奨事項と回答に大きな影響を与えます。
回答
TL; DR： GCMは、今日の暗号（AEAD）に期待される最高のセキュリティプロパティを備えた優れたパフォーマンスを提供します。
GCMは、CTRを使用してストリーム暗号を構築します。これはよく研究された方法ですが、欠点は1つだけです。ビットフリッピングを防ぐために、何らかの認証が絶対に必要です。 GCMの前は、CTR-then-MACがソリューションでした。ストリーム暗号の主な利点の1つは、パディング攻撃がないことです（パディングの必要がないため）。もう1つの利点は、AES-CTRがAES-NI命令の恩恵を受けることができることです。
GCMはCTR-then-MACであり、パフォーマンスが向上します。 CRT-then-MACに対する重要な改善点の1つは、暗号化と認証の実行をオーバーラップさせる機能です。さらに、具体的なセキュリティモデルで安全であることが証明されており、特許に邪魔されないため、「使用するのは簡単です。
いくつかの欠点があります。組み込みハードウェアでは効率的ではありません。最後の点は、他の人が作成したライブラリを使用することで解決されます。ただし、これがxchacha20-poly1305がGCMで普及した理由です。
コメント
- ChaCha20が人気を博したもう1つの理由は、AESではないからです。’誤解しないでください、AESは優れたアルゴリズムですが、文字通りすべての卵を1つのバスケットに入れることは、すべてのアイデアの中で最も賢いわけではないかもしれません。また、AES以外に十分にテストされたアルゴリズムを1つ持つことは、非常に価値があります。
- @ MechMK1同意します。 、しかし、ChaCha20 ‘の人気の理由はすべてであるとは書きませんでした。’ここで尋ねられた質問ではありません。私のポイントはtでした。 OPが考えるように、帽子GCMは” awesome “とは見なされません。
- 絶対に真実です。 ‘はゴールデングースではありませんが、いわばAES-GCMを使用したことで解雇されたことはありません。
- そして’特許に邪魔されていません。
- @StephenTousetありがとうございます。コメントを含めるように投稿を編集しました。
回答
まず、GCMはカウンターモードの一種です。つまり、たとえば暗号ブロック連鎖。1つのブロックの出力は、入力の1つのブロックにのみ依存します。さらに悪いことに、1つのビットを変更すると、復号化された結果はそのビットで正確に異なります。正直なところ、カウンターモードのブロック暗号は「ブロック暗号」ではなく、（キー付きの）PRNGとそれに続くXOR演算であるためです。基本的に「ブロック状」のストリーム暗号。誰かがこれを悪用してメッセージを有害な方法で変更する可能性があるシナリオを想像するのにそれほど時間はかかりません（たとえば、「トランザクション：+ 5,000 \ $」を「トランザクション：-5,000 \ $」に変更します）。
GCMがCTRの上に重ねるメッセージ認証により、その可鍛性は重要ではなくなります。
ブロック暗号には通常、1ビットを反転すると完全なジブリッシュに変わるという固有の特性があります（さらに、チェーンを使用すると、メッセージの残りの部分全体が） 。これは実際には非常に優れた望ましいプロパティであり、正当な理由もなく船外に投げ出されました。
これは非常に間違っています。まず第一に、 、CBCモードにも、一種の可鍛性の弱点があります。暗号文の1ビットを反転すると、1つのブロックとネットブロックの対応するビットを反転します。CBCに対する他の可鍛性攻撃があります。たとえば、 EFail攻撃を参照してください。
より一般的には、「完全なジブリッシュに変わる」というメッセージの非公式な考えは十分ではありません。暗号化されたメッセージが偽造された場合、明確な「はい/いいえ」の答えで機械的に検出するコンピューターが絶対に必要です。人間が「ジブリッシュ」を見つけるのに十分早い段階でループに入ると信じるだけでは不十分です。
GHASHは、追加の認証済みデータをサポートするMACです。私が言えることから、それは完全な嘘です。または、必要に応じて「楽観的な誇張」と呼んでください。これは、（非数学者にとって）直感的でない数学が背後にある単なる圧縮関数ですが、最終的には、単純な乗算と、「オーバーフロー」に相当する入力ビットの半分を破棄するだけです。
ユーザーが数学を理解していないためにMACが機能しなくなることはありません。つまり、人々は衛星テレビを視聴できないために視聴できないと言っているようなものです。 「計算がわからない。有限体MACは標準的な構造であり、数十年前から知られています。
これは、より平凡な計算で、2行のCで実行できるものです。十数サイクル以内のブロックごとのコード（または、64ではなく32ビットの乗算を使用しても問題がない場合は、AVX2のvpmulldを使用して最大4サイクルで2つの完全なブロックを並列に実行できます）。
GHASHのようなガロア体に基づくMACと、Poly1305のようなプライム体に基づくMACのどちらがより実用的な選択であるかについては、実際の議論があります。その多くはトレードオフにかかっています。ソフトウェアとハードウェアの実装を強調するようにMACを設計する間。たとえば、ガロア体の乗算はソフトウェアでは悪夢ですが、ハードウェアでの数学的な乗算よりもはるかに単純です。トレードオフのかなりの部分は、電力分析などのサイドチャネル攻撃に対する脆弱性にも依存します。 。
しかし、ガロア体とプライム体のどちらが根本的に不確かであるかについては議論がありません。 nd。数学は両方をチェックします。
はい、パフォーマンスです。しかし、正直に言うと、これは本当に利点なのか、それとも大きな欠点なのか？
何十年にもわたるエンジニアの果てしないパレードにそれを伝えてください。パフォーマンスのために製品に暗号化を追加することに抵抗してきました。そして、強力なPCだけを考えないでください。組み込みデバイスについて考えてみてください。モノのインターネットを非常に恐れています。
つまり、これは致命的な問題ではありません。過去2年間、活発な議論が行われ、新しい暗号化構造の開発が行われ、ローエンドのAndroidデバイスでフルディスク暗号化をサポートすると判断されました。 Androidが以前に提供したAESベースのアルゴリズムには十分に強力ではありません。
[パフォーマンス]が実際に違いを生むのは「悪者」、つまり、あなたが望んでいない人だけです。簡単な生活。確かに、簡単に並列化できれば、攻撃ははるかに簡単になります。問題に専用ハードウェア（GPU、FPGAなど）でいっぱいの部屋を投げて、それを粉砕してください。
暗号は、暗号を遅くするのではなく、十分に大きなキーサイズを使用することでこれを解決します。あなたが提起する懸念は、パスワードベースの暗号化で発生します。 「十分なエントロピー秘密鍵がありません。256ビット対称鍵は、私たちの宇宙でのブルートフォース攻撃を打ち負かすのに十分な大きさです。
GCMについて私が見逃している基本的なことは、絶対に使用する必要があるほど素晴らしいものですか？
GCMを絶対に使用する必要はありません。 。同時に：
- Fundamentall yサウンドであり、ハードウェアで非常に広くサポートされています。
- ソフトウェアのパフォーマンスの低下やノンスの再利用による壊滅的な信頼性の失敗など、発生しなかった多くの欠点に悩まされ、実際の状況では失格となることがよくあります。
ネイティブのAES-GCMをサポートするハードウェアと、それを活用する十分に監査されたソフトウェアがある場合、それを最有力候補に含めないのは賢明ではありません。