アセンブリコードで最適化したwolfSSLを使用してTLS 1.2とTLS 1.3のスループットを比較すると、いくつか興味深い結果が得られました。このブログシリーズではwolfSSLのTLS 1.2とTLS 1.3の間に見られる性能の違いと、その利点をアプリケーションへ最大限に取り入れる方法について説明しています。今回はその6回目です。TLS 1.2と1.3では、データが暗号化される方法に違いがあります。アルゴリズムによっては、これは顕著な差を生じます。
TLS 1.2では、メッセージの平文を暗号化し、暗号化データに対する認証コードとadditional_data を生成します。このadditional_dataには64ビットのシーケンス番号、1バイトのコンテンツタイプ、2バイトのバージョン、2バイトの長さ情報が含まれ、合計13バイトが 使用されます。
TLS 1.3では、メッセージの平文と実際のレコードタイプの1バイトを暗号化し、暗号化データに5バイトのレコードヘッダーを加えた認証コードを生成します。
AES-GCM暗号スイートでは、Intel x86 64ビット最適化アセンブリコードでスループットがわずかに増加する結果がでました。これは追加認証データ（AAD, Additional Authentication data）として渡されたバイト数によるものです。 AADで使われたバイトは暗号化と復号化の前に別々に処理され、TLS1.3の追加5バイトの処理はTLS1.2の追加13バイトの処理より速いことが判明しました。暗号化されたデータの末尾にある余分な1バイトは大きな影響を与えませんでした。
Chacha20-Poly1305では、データが16バイトブロックに配置され、処理される前にパディングされるため、AADとして渡される異なるサイズのデータは目立った影響を与えません。しかし、平文の末尾の余分な1バイトがChacha20とPoly1305の性能に影響を与えました。 Poly1305では、その余分の1バイトがひとつの余分な16バイトブロックを作ってしまいました。これにより Intel x86 64ビット最適化アセンブリコードのスループットは、結果的に 約3〜5％の性能低下 がありました。
TLS 1.3ではAES-GCMを使用するとスループットが向上するため、それがTLS1.3へ変更する1つの理由にもなっています。最善のスループットを得るには、アプリケーションデータメッセージとして1レコードの最大平文サイズより1バイト小さいものを送信することを検討してみてください。これは、AES-GCMとChacha20-Poly1305の両方の暗号スイートで性能の向上につながります。最大平文サイズはデフォルトでは16384バイトです。
このブログシリーズは今回が最終回です。
最後まで読んでいただき、ありがとうございました。
以前のブログ：
TLS 1.3の性能 その1 – セッション再開
TLS 1.3の性能 その2 – フルハンドシェイク
TLS 1.3の性能 その3 – 事前共有鍵（Pre-Shared Key: PSK）
TLS 1.3の性能 その4 – サーバーでの鍵ペアの事前生成
TLS 1.3の性能 その5 – クライアント/サーバー認証
さらに詳しい情報は弊社問い合わせ窓口info@wolfssl.jpまでお問い合わせください。
原文: https://www.wolfssl.com/tls-1-3-performance-part-6-throughput/
wolfSSLホーム：www.wolfssl.jp (English：www.wolfssl.com)
