不支持 ECDSA 的低安全曲線嗎？
我在頻寬非常受限的環境中工作，我們正在尋求實施 ECDSA 數字簽名。儘管不再推薦它們，但我們可能希望使用大多數庫（包括 OpenSSL）不支持的曲線：https ://en.wikipedia.org/wiki/Comparison_of_TLS_implementations#Supported_elliptic_curves
我們正在研究諸如secp112r2、secp128r1、sect131r1等曲線。這不是討論這些的安全性，而是他們的支持。
在 Cygwin 中，可以使用大量曲線，包括提到的低安全曲線。但在 URL 中沒有列出這些曲線。我們的團隊觀察到，在其他一些 OpenSSL 源（不是通過 Cygwin）中，不支持這些曲線。OpenSSL 是否不再支持它們，如果是，為什麼我可以通過 Cygwin 使用它們？
順便說一句 - 我假設曲線支持相當複雜，因此不可能“導入”給定庫中不支持的曲線。
我不確定，但我猜兩個不同的 openssl 版本或只是建構可以在支持或不支持具有不安全安全級別的橢圓曲線的情況下完成。
此外，您的曲線具有非常低的安全級別，如果安全是一個問題，您不應該使用它們（如果不是，您可能根本不需要 ECDSA）。
但是，您認為“曲線支持相當複雜”的假設是錯誤的。
使用 libcrypto，OpenSSL 庫，而不是命令行工具，您可以使用EC_GROUP_get_curve_GF創建自己的橢圓曲線。如果您輸入這些曲線的參數，您將能夠與庫一起使用它們，即使這些參數未在 OpenSSL 中編碼。
那篇維基百科文章是關於 TLS 的，並且僅單獨列出了在 TLS中分配了數字的 EC 曲線；對於 TLS，所有其他曲線都屬於“任意素數”或“任意 2^m”。OpenSSL 支持非 TLS 操作，包括 ECDSA很多未編號用於 TLS 的曲線，包括您列出的三個。按照要求，我不評論他們的不安全感；-()
由於 OpenSSL 是開源的，人們可以更改它。特別是 RedHat 直到最近才建構 OpenSSL 並刪除了所有ECC，因為他們模糊地描述為“法律”問題。廣泛傳聞，但 AFAIK 沒有得到證實，他們指的是 Certicom 的專利。然後他們改為只包括 P256 P384——兩條 SuiteB 曲線，可能是因為 NSA 有一個允許任何人使用 SuiteB 的全面許可，然後他們最近對 ECC 普遍懷疑，特別是 SuiteB——以及 P521——沒有明顯原因只是它是最大的標準曲線（迄今為止），因此吸引了那些除了“大數字聽起來令人印象深刻”之外什麼都不理解的人。
您可以選擇獲取 OpenSSL 原始碼並自行建構。與某些 OSS 相比，它相當容易：除了標準的 C 實現和可選（但強烈推薦）每個平台的彙編器之外，您基本上只需要 make（在 Unix 上）和 perl（甚至非常舊的 perl 也可以）。此外，如果您需要或願意，您可以進行其他更改。在許多系統上，您確實需要將自定義建構放入包/安裝管理器中，或者選擇繞過它。
您提到有限的頻寬，但沒有提到記憶體。如果記憶體是個問題，請注意完整的 OpenSSL很大；有一些建構選項可以移除一些碎片並使其更精簡，但仍然遠不及苗條。