前半で述べたように、OpenSSLのAEAD暗号器は、長いAEADブロックの処理を前提に作られています。平文の暗号化処理においては理論上の上限にあたる速度を叩き出す一方、事前処理と事後処理、および呼出オーバーヘッドについては、あまり最適化が図られているとは言えません。これは、AEAD暗号の主な使用用途が、これまでTLSという長いAEADブロックを使う(ことが一般的な)プロトコルであったことを反映していると言えるでしょう。 一方、QUICにおいては、UDPパケット毎に独立した、短いAEADブロックを暗号化する必要があり、したがって、次のような速度向上の機会があることが分かります。 AEAD処理をひとつの関数にまとめ、事前処理と事後処理を、パイプライン化されスティッチングされた暗号処理と並行に走らせることができれば、AEADブロックが短くても、理論値に近いスループットを発揮するような、AES-
![QUICむけにAES-GCM実装を最適化した話 (2/2)](https://cdn-ak-scissors.b.st-hatena.com/image/square/a5f2169c9b71100bb090cdb26ea4a6b0adf14a51/height=288;version=1;width=512/https%3A%2F%2Fblogger.googleusercontent.com%2Fimg%2Fb%2FR29vZ2xl%2FAVvXsEgw0PJepm3MVEQ92bGGpsDdeTBomfmTkVvCFz9uBpGl7mQc057ECL8xi42xx34UjcP7Hm4nssZ_iaLB2LMvIILa56gFEbaKONLGG4P3JjJrrriZ5AOMTbpeERkvS70aWBvqBCA1FkdHwcWe%2Fw1200-h630-p-k-no-nu%2F%252522fusion%252522%2BAES-GCM%2Bengine%2Bfor%2BQUIC.png)