在 DHE 交換期間，客戶端和伺服器如何就 p 和 g 的值達成一致？

使用有限域 DHE 的通信方如何就 DHE 的值達成一致 $ p $ 和 $ g $ 變數？每個 DHE 組的值是否固定？

通讀TLS 1.3 RFC (8446)，客戶端和伺服器（使用key_share擴展）僅交換：

1. DHE 命名組和
2. 的價值 $ Y=(g^X \bmod p) $

但沒有提及各方如何就價值達成一致 $ p $ 和 $ g $ 而且我找不到任何明確說明的資源 $ p $ 和 $ g $ 每組是固定的。

每個 DHE 組的值是否固定？

是的，按照慣例，命名組至少包括 $ (g,\mathbb G,q) $ 和 $ \mathbb G $ 是組參數的描述（即 $ (p,a,b) $ 對於素數橢圓曲線或 $ p $ 對於 FFDH), $ g $ 作為發電機和 $ q $ 是發電機的訂單。

使用有限域 DHE 的通信方如何就 g 和 p 變數的值達成一致？

目前 TLS 1.3 中的流程是：

1. 客戶端發送（在supported_groups中）它能夠並願意使用的組的“名稱”（真正的程式碼編號）列表，可以是FFDHE和ECDHE的任意組合，以及可選的（在key_share中）新生成的公鑰部分或全部這些組；如果它想首先查看伺服器的選擇，或者如果它（也）提供並且更喜歡基於 PSK 的會話恢復，它可能會發送空的 key_share。
2. 如果選擇了 xxDHE（即除非客戶端提出並且伺服器同意僅恢復 PSK 時），伺服器會在 key_share 中檢查它也能夠並願意使用的組，如果找到，則在該組中發送生成的公鑰。如果不是，但伺服器在客戶端的supported_groups 中找到了一個可接受的組，它發送HelloRetryRequest 指定該組（但還沒有任何公鑰）。如果兩者都不是，則伺服器中止握手。
3. 如果請求，客戶端會發送一個新的 ClientHello，其中包含伺服器指定的組的公鑰（但其他更改嚴格限制在 4.1.2 中），伺服器使用該組中的公鑰響應（不允許更改）。

在 TLS 1.2 及以下版本中，流程取決於兩個系統是否實現RFC 7919，該標準是在大多數 TLS 1.2 實現編寫多年後發布的，更不用說更低的版本了：

1. 在 RFC 7919 中，客戶端在supported_groups（最初稱為elliptic_curves）中指明它支持的命名組，FF 或ECC。沒有跡象表明支持其他（任意）FF 組，因為這是在創建此擴展之前很久的預設設置。對於 ECC 組/曲線，以前（在 RFC 4492 中）有程式碼值以 X9.62 和 63 定義的 Weierstrass 形式表示 Fp 或 F2^m 上的任意/未命名曲線，但這很少被實施或使用，並且RFC 8422 刪除了這個選項。
2. FFDHE 的伺服器始終以早於 RFC 4492 定義的格式在 ServerKeyExchange 中發送 p、g 值及其公鑰（和簽名），無論這些值對應於命名組還是另一個任意組。伺服器或其管理員可以生成任意組，或者從幾乎任何來源導入。例如，Logjam 研究人員發現大量公共伺服器使用一個 FFDHE 組，該組被編碼到某些版本的 Apache httpd 中。
3. 客戶端要麼接受伺服器選擇的組並在該組中生成並發送他們的公鑰，要麼中止握手。例如，特別是在最近幾年，如果伺服器發送的組 p 太小而無法提供所需的安全級別，則某些客戶端實現會中止。（Java 使它成為一個執行時可配置的選項：jdk.tls.disabledAlgorithms 包含“DH keySize < $number”。）但即使是數字上足夠大的 FF 組也可能由於不太明顯的原因而變得弱；有關於這方面的現有問題。

引用自：https://crypto.stackexchange.com/questions/81896