Boneh-Lynn-Shacham 簽名的標準參數？
Boneh-Lynn-Shacham 簽名（據我所知）在緊湊性方面無與倫比，很有前途 $ b $ -位安全性 $ 2b $ -位簽名（也許：漸近）。
是否有 BLS 簽名的標準參數，（正在？）由標準機構、安全機構或其他公認的機構定義；或其他常見/推薦？
特別是，是否有大小建議，可能在ISO/IEC 15946-5 中：資訊技術 - 安全技術 - 基於橢圓曲線的密碼技術 - 第 5 部分：橢圓曲線生成？
什麼是最先進的（
$$ BD 2019 $$我猜）暗示 BLS 簽名的大小 $ b $ 位安全，實用 $ b $ 像128？
一些參考文獻（現在已過時，最後兩個除外）：
$$ BLS 2004 $$：Dan Boneh、Ben Lynn、Hovav Shacham，來自 Weil 配對的短簽名，密碼學雜誌，2004 年（最初$$ BLS2001 $$是Asiacrypt 2001的會議記錄）。 $$ BN 2005 $$: Paulo SLM Barreto, Michael Naehrig, Pairing-Friendly Elliptic Curves of Prime Order , 在SAC 2005 的程序中；幻燈片。 $$ SSS 2006 $$：Mike Scott、Hovav Shacham、Terence Spies， 2006/10 年的P1363 展示文稿。 $$ NNS 2010 $$：Michael Naehrig、Ruben Niederhagen、Peter Schwabe，加密配對的新軟體速度記錄，在Latincrypt 2010的會議記錄中；參考頁面連結的軟體。 $$ ABLR 2013 $$：Diego F. Aranha、Paulo SLM Barreto、Patrick Longa、Jefferson E. Ricardini，The Realm of the Pairings ，在SAC2013的會議記錄中，附有幻燈片（報告自 2002 年以來的實際使用情況）。 $$ KB 2016 $$: Taechan Kim, Razvan Barbulescu, Extended Tower Number Field Sieve: A New Complexity for the Medium Prime Case ,$$ KB16 $$在Crypto 2016 的程序中，最初$$ K 2015 $$ 2015 年 10 月和$$ B 2015 $$2015年11 月。 $$ BD 2019 $$：Razvan Barbulescu，Sylvain Duquesne，更新配對的密鑰大小估計，密碼學雜誌，2019 年 10 月
嗯，Boneh-Lynn-Shacham“BLS”簽名方案目前正在通過一個名為“draft-irtf-cfrg-bls-signature-00”的網際網路草案（網際網路工程任務組的工作文件）進行標準化。 IETF")，您可以在此處跟踪。看來 Algorand 可能是這個過程的幕後推手，還有 Dan Boneh 自己的支持。
如那裡所述：
該方案有兩種變體：
- （最小化簽名大小）將簽名放在 G1 中，將公鑰放在 G2 中，其中 G1/E1 具有更緊湊的表示。例如，當使用配對友好曲線 BLS12-381 實例化時，這會產生 48 字節的簽名大小，而曲線 25519 上的 ECDSA 簽名的簽名大小為 64 字節。
- （最小化公鑰大小）將公鑰放在 G1 中，將簽名放在 G2 中。後一種情況出現在我們進行簽名聚合時，其中大部分通信成本來自公鑰。這在區塊鍊和壓縮證書鍊等應用中尤其重要，其目標是最小化多個公鑰和聚合簽名的總大小。
雖然它們（尚未）指定要使用的明確參數，但它們確實參考了Internet 草案“配對友好曲線”，該草案又根據您想要達到的安全級別提供了多項建議。關於上述引用，它特別在建議中列出了 BLS12-381 以具有 128 位安全性。
此外，與 ECDSA 相比，他們提到（強調我的）：
以下比較假設 BLS 簽名具有曲線 BLS12-381，針對 128 位安全性。
$$ … $$
在大小方面，ECDSA 使用 32 字節的公鑰和 64 字節的簽名；而 BLS 使用 96 字節的公鑰和 48 字節的簽名。或者，BLS 也可以用 48 字節的公鑰和 96 字節的簽名來實例化。BLS 還允許簽名壓縮。換句話說，單個簽名足以驗證多個消息和公鑰。
因此，目前的“標準”似乎是擁有約 384 位的簽名才能達到 128 位的安全性，這意味著擁有 $ 3b $ 位簽名為 $ b $ 一點安全感。（正如布里斯托爾已經說過的那樣，BN 曲線已經“失去”了優勢，而他們目前的 128 位競爭者是 BN462。）
另外，請注意這是一份工作文件，因此並不完整。例如，它缺少尚未添加的內容：
待定：對此進行額外討論，例如
$$ Ristenpart-Yilek 06 $$，以及用於保護聚合免受惡意密鑰攻擊的替代機制，例如 $$ Boneh-Drijvers-Neven 18 $$; 在那裡，預處理公鑰將加快驗證速度。
在我們想要擁有聚合簽名的情況下，流氓密鑰攻擊通常是需要防禦的重要東西，這是 BLS 的優點之一。
請注意，在基於配對的加密貨幣中，我們不得不在過去 3 年內顯著改變我們的安全估計，這主要是因為 FFDLP 的進步（參見$$ KB16 $$)，並附上您的最新參考資料
$$ BD 2019 $$，是有關安全估計和建議的目前最先進的技術。 因此，上述 IETF 草案完成並成為真正的“標準”可能還需要一段時間，但這仍在進行中。