使用 EC 加密和 secp256k1 曲線談論 TLS
在 secp256k1 曲線上說 TLS 有多合理？我最初的實驗表明 OpenSSL 支持它（儘管帶有特殊標誌，見下文）：針對 OpenSSL 伺服器（或我發現的一些隨機 node.js 伺服器）執行 OpenSSL 客戶端會協商套件 ECDHE-ECDSA-AES128-GCM-SHA256並建立一個正常的 TLS 1.2 會話。
另一方面，curl 和瀏覽器似乎都不喜歡這種特定的曲線。（儘管這對我的案例來說不是必需的。）
我使用 secp256k1 的原因是因為有一個很好的算法可以從現有密鑰（BIP 32）派生新密鑰。這些密鑰不能相互關聯，這在點對點場景中是一個很大的優勢。
現在我的問題是：為 TLS 使用像 secp256k1 這樣不常見的曲線是否合理？或者，是否有一種安全機制可以從 secp256k1 私鑰中為另一個（更常見的？）曲線派生私鑰？
我上面提到的標誌：
-curves "X25519:P-256:P-521:P-384:secp256k1"編輯：我的問題不是關於 secp256k1 的理論弱點，而是期望什麼樣的實際問題。
在一些原型實現之後，這是我學到的：
- 這個有可能。OpenSSL 和 Java 支持它，這對我的案例來說已經足夠了。
- 客戶端證書可以正常工作。
- 它需要一些配置工作（特別是對於 OpenSSL）。
- TLS 1.3 不支持它，只有 1.2 支持。如果這足夠好，那麼應該沒有問題。
BIP32 使用 secp256k1，因為 BIP 用於比特幣，而比特幣使用 secp256k1。（我覺得像 Buffy 1.01：“[我現在在這裡的原因是] 因為現在是我們來到這裡的時候”。）相同的方法適用於任何橢圓曲線，顯然替換 ser256 和 parse256，並且如果使用像 X25519 這樣的非 Weierstrass 形式，則用於serp。
但在實踐中，TLS 需要證書用於身份驗證密鑰（或 kRSA，不再推薦，在1.3中不再支持），並且證書不能很好地與通過 BIP32 或任何其他方式快速或動態創建密鑰相結合，無論曲線如何（s ） 用過的。（“在實踐中”，因為有一個使用原始密鑰的 RFC，但我從未見過實現，當然不是在 OpenSSL 中。）
PS：nodejs內置的’tls’ 是OpenSSL，編譯到
node[.exe]下面。您可以獲得包括 ECC 在內的替代（純 JS）加密，但我還沒有看到純 JS TLS。