TLS 1.2では（1.3を念頭に置いて）どのブロック暗号を使用する必要がありますか？
TLSのさまざまなブロック暗号について少し調べてきました。誰もが（パイプの夢）TLS 1.2に移行しているはずなので、TLS 1.3が実装されたら、それをどのように準備するかを検討する必要があります。
私の日常の作業では、1.3を念頭に置きながら、TLS 1.2にどのブロック暗号アルゴリズムを推奨するかを検討してきました。 Wikipediaで （情報の宝庫） AES-GCMはTLS 1.3で使用可能であり、パフォーマンスを考慮した優れた暗号の1つであるため、ブロック暗号の良い候補である可能性があることがわかりました（参照） AES GCMに関するスタンフォード大学のプレゼンテーション ）。
この質問の一部は「GCMまたはCCMを使用する必要があります」ですが、これは-ある程度-回答済み こちら です。私にとって重要な部分は、使用する暗号は、少量の送信データを使用して計算および処理できる必要があるということです。私のコンテキストでは、処理能力と送信されるデータの量の両方に制限があるので、TLS 1.2と将来の1.3でサポートされているブロック暗号のどれがこの点で最適であるかを誰かが提案または証明できますか？
編集：コメントに答えるため。クライアント自体はブラウザではなく、TLSで保護されたチャネルを使用します。エンジン...それが完全に決まっているのか実際にはわかりません。集中型サーバーに接続するように設定されているマシン上にあります。これはC＆Cっぽく聞こえますが、もっとIoTっぽいです。私はそれが質問に答え、私の質問に対する答えが何であるかについてのヒントを私に与えるのに役立つことを願っています.
私のコンテキストでは、処理能力と送信されるデータの量の両方に制限があるので、TLS 1.2と将来の1.3でサポートされているブロック暗号のどれがこの点で最適であるかを誰かが提案または証明できますか？
- TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
- TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
理由：
- CHACHA20-POLY1305暗号スイートはTLS1.2の一部です。
- LibreSSL 2.3.0 以降で利用可能であり、OpenSSL 1.1に追加されます（ 2016-08-25 でリリース予定） 。
- モバイルデバイスは使いやすく、はるかに より効率的です （特に、ハードウェアアクセラレーションAESをサポートしていないデバイス）。
- デフォルトで256ビットのセキュリティを提供します（ほとんどの場合、AESの128ビットとは異なります）。
- 新しいバージョンがドロップするため、互換性のあるTLS1.3ですstaticRSAおよびDHキー交換メカニズム（ [〜＃〜] rfc [〜＃〜] ）。 ECDHEがほとんどの場合に優先されます。
- CGMのような関連データ付き認証暗号化（AEAD）構造を使用して構築されています（脆弱化。原因：nonce reusage initial paper 、 BHUSA2016スライド + 元の紙 ）、CCMまたはEAX（ broken ）。