HTTPS信頼性インデックスを計算するための方法論を準備する際に 、私たちは多くの主題文献を調べ、モバイルクライアントの負荷を軽減するためにWebサーバーでCHACHA20暗号化アルゴリズムに基づく暗号スイートをサポートするという推奨事項に何度も遭遇しました。ハードウェアAESを使用できません。これに関連して、Mediatekプロセッサと「旧予算のモバイルプロセッサ」が通常言及されました。
信頼できるコンパニオンPOLY1305を備えたCHACHA20は、モバイルクライアントを本当にクールに保ちますか？Webサーバーでサポートする価値はありますか？話し合いましょう！
CHACHA20は、特にCurve25519と、暗号スイートで_EXPORT_が何を意味するかをオールドファッグだけが覚えているという彼の擁護活動で私たちが愛している有名な暗号研究者DanielBernsteinによって作成されました。このアルゴリズムは十分に研究されており、AEADモードで動作し、既知の弱点や脆弱性はなく、TLS 1.3で使用するためにIETFによって承認された2つの暗号化アルゴリズムの1つです（もう1つは不滅のAESです）。
TLSで使用した場合の理論上の暗号強度は、GCMモードのAES-128とAES-256の間で異なる方法で推定されます。これは、今日の標準では十分であり、近い将来に十分であると考えられています。同時に、それ は注意されますCHACHA20はAESよりも「高速」です。 「同じレベルの暗号強度を提供するために、より少ないプロセッサリソースを消費します。」この表現は、テレマーケティングのようなにおいがするだけでなく（作成者に敬意を表して）、重要な詳細を見逃しています。ハードウェアAESをサポートしていないプロセッサです。
そしてここでようやく、AESの下で過熱し、抑制を開始して液体窒素（皮肉）を要求する「予算のモバイルプロセッサ」に戻ります。プロセッサの製造元は問題を認識しており、適切な一連の命令を追加することで問題を解決しています。 x86互換プロセッサでは、これはAES-NIであり、他のプロセッサでは、それらの名前（および独自のセット）です。そして、ここで最も興味深い部分に到達します。プロセッサによるAESサポートです。
Intelは、2010年にWestmereプロセッサでAES-NIのサポートを導入しましたが、すべてではありません。Atom、Celeron、Pentium、およびCore i3は、長い間依存していませんでした。ゴールドモントアーキテクチャ（アポロレイクとデンバートン）から始まる仕様を掘り下げることなく、AES-NIのサポートを確信できます。これはすでに2016年です。
AMDの場合、これらはBulldozer（2011）およびJaguar（2013）アーキテクチャであり、ARMではすべてがより複雑です。AES命令のサポートはARMv8-Aアーキテクチャ（2011、最初のデバイスは2013）で提供されますが、実際の実装はそれらのシリコンはメーカーのプロセッサに依存しており、私は個人的に「古い予算のモバイルプロセッサ」についてそれほど自信を持って口笛を吹くことはありません。今日まで生産されています。
簡単に言えば、AESハードウェアサポートなしでプロセッサに出くわすことはそれほど難しくありません。それで、CHACHA20は本当にAESの素晴らしい代替品ですか？たとえば、この研究の結果を見てみましょう 。 AESをサポートしていないプロセッサでは、CHACHA20は、多くの場合、パフォーマンスにおいてそれよりも著しく進んでいます。残念ながら、温度測定値は表示されませんでしたが、サーバープロセッサについて話している場合、消費されたプロセッサリソースの違いが重要であることは明らかです。
AES対応プロセッサに関しては、状況は逆になります。 CHACHA20のせいにする価値はほとんどありません。これは、プロセッサで個人的な命令セットを提供した人が誰もいなかったためです。また、両方のプレーヤーが古いプロセッサで見たのと同じルールでプレイするとどうなりますか（注意：AESはマージされます）。
では、WebサーバーでCHACHA20のサポートに行きましょう。すべての卵が1つのバスケットに入れられていないという理由だけで、明日突然AES自体または特定の暗号ライブラリでの実装に穴が見つかった場合は、「明確になるまで」少しだけオフにすることができます。私たちの手の動き、CHACHA20にとどまり、AESに代わるものを必死に探しているのではなく、それがどのようにオンになるか。
中でCHACHA20の場所の問題
HTTPS接続を確立するときに、暗号スイートが一般的にどのようにネゴシエートされるかを覚えておいてください。クライアントは、サポートする暗号スイートのリストを「ブルドーザーから」の順序でサーバーに送信します。この順序は、Windowsグループポリシーを介してのみ変更できます。 SChannelを使用する
サーバー上の暗号スイートの優先順位は、通常、利用可能な最大のセキュリティの原則に基づいて設定されます。より強力な暗号スイートが最初にリストされ、最後にリストされます。現代のクライアントは強力な暗号スイートに出くわしてそれに同意し、「時代遅れの」クライアントはリストをさらに下にジャンプして、より強力でない暗号スイートにジャンプし、それに同意します。誰もが満足しており、それぞれの能力に応じて、HTTPSを使用するまで、すべてが機能します。
そしてここで、CHACHA20に基づく暗号スイートは、この調和のとれた世界像に適合します。これは、クライアントが同時に「時代遅れ」であるかどうかについて何も知らなくても、ハードウェアの観点から「弱い」クライアントの負荷を軽減する理由で追加します。そうではありません（つまり、中国の3番目の企業からの今年の旗艦、または一流のブランドからのミッドレンジの5歳）。お客様は、TLS 1.3と、AESとCHACHA20の両方の関連する暗号スイートの完全なスイートをサポートすることをお勧めします。あなたのソリューション、管理者、私たちはクライアントにどの暗号スイートに同意していますか？ここで私はほぼ同じです...私
はCHACHA20暗号化アルゴリズムについて上記を 要約します。
- このアルゴリズムはそれ自体が非常に優れており、TLSでの使用に適しています。
- これに基づく暗号スイートは、かなり最新のブラウザでのみサポートされているため、AESはまったく必要ありません。
- その使用によるパフォーマンスの向上は、「古い予算のモバイルプロセッサ」だけでなく、デスクトップやサーバーでも得られます。ハードウェアAESをサポートするプロセッサでは、状況が逆になります。
- HTTPS接続を確立する場合、クライアントのプロセッサがハードウェアでAESをサポートしているかどうかを知る方法はありません。したがって、どの暗号スイートがそれぞれの場合に「高速」になるかを知る方法はありません。