web-dev-qa-db-ja.com

暗号スイート「トランスレータ」はありますか

次の形式の暗号スイートのリストがあります。

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384

それをより人間が読める形式/管理形式で読める形式に変換する、高速で簡単な方法はありますか？ :)

encryptionciphers
16
mancuss

いいえ、アファイク。

また、技術者以外の人にとっても読みやすく役立つと思われる場合、各翻訳はそれ自体が1つの本であり、これらの文字列の各部分を説明しているため、面倒な詳細が表と裏になります。

ご存じないかもしれませんが、 rfc 5246 は現在この形式をカバーし、 表を含む は便利なトラックを送信する可能性のある暗号スイートを備えています。

あなたの例

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384

「 [〜＃〜] tls [〜＃〜] 楕円曲線で ECDHE_ECDSA を使用 P384 キー交換用、-を使用して接続を暗号化- AES_256 in [〜＃〜] gcm [〜＃〜] 使用中 SHA384 as [〜＃〜] prf [〜＃ 〜] 。」

リンク先からわかるように、使用されている頭字語自体を「簡単に」理解することはできません。しかし、一般的な構文は

TLS_nameOfKeyExchange_WITH_nameOfBlockCipherAndMode_nameOfPRFForMAC_addinionalExtensions

私の編集からわかるように、推論はひどく失敗することもあります;）

13
Tobi Nary

IANAは、定義された暗号スイート用に official registry を維持します。各暗号スイートは16ビットの識別子です。 「記号名」は名目上標準ではありません。ほとんどの実装では、OpenSSLのように、レジストリに示されている名前を使用しますが、使用しない場合もあります。 OpenSSLには 独自の命名方式 があります。

IANAレジストリを使用すると、暗号スイート名を検索できます。これにより、特定の暗号スイートを定義するRFCが示されます。実際の詳細を取得するためにそのRFCを読むのはまだあなた次第です。

ここで困惑しているのは、指定した文字列が not これらの準標準名の1つであるということです。末尾に「_P384」が追加されています。基礎となる暗号を理解している場合は、推論して、「P384」サフィックスが で定義されているNIST標準楕円曲線P-384に関連していると推測できますFIPS 186-4 。したがって、あなたの例 "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384"は、 RFC 5289 で定義されているように "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384"となり、楕円曲線で使用されます。

推論は今のところあなたを得ることができるだけです。 「TLS_ECDHE_ECDSA」接頭辞は、鍵交換がECDHE（楕円曲線Diffie-Hellman、Ephemeral）を使用し、サーバーがECDHEの半分を sign 永続的な秘密鍵（ 1つはサーバー証明書の公開鍵に対応します）、その署名は楕円曲線で動作する署名アルゴリズムであるECDSAを使用します。 「P384」接尾辞がECDHE、ECDSA、またはその両方の楕円曲線を指定するかどうかは不明です（私はそれがECDHE専用であると思いますが、それは単なる直感です）。これは、非標準的な用語の問題です。

したがって、暗号スイート名を理解するための情報源は、これらの名前を生成または使用するツールのドキュメントである必要があります。それに失敗すると、自分の結論に戻ることになります。

6
Thomas Pornin