詳解Sui的密碼學靈活性

編譯：Alan｜SophonLabs

Sui 在設計底層技術時考慮到了密碼學的靈活性。該系統支持多種密碼算法和cryptography primitives（密碼原語），並可以在它們之間快速切換。开發人員不僅可以為系統選擇同類最佳的best-of-breed cryptography（公开密鑰密碼體系），還可以實施最新的algorithms（可用算法）。

Sui 在一個統一的類型別名或整個存儲庫共享的枚舉包裝器下定義其cryptography primitives（密碼學原語），例如公鑰、籤名、聚合籤名和哈希函數。對這些原語進行更改會影響應用程序的所有組件。开發人員可以快速更新應用程序密碼並確保統一的安全性。

目前Sui 通過執行交易端點支持以下用戶交易籤名方案：

• Pure Ed25519

• Secp256k1 ECDSA

用戶账戶密鑰對的接口實現

下面是 Sui 中密鑰對表示的Demo。擴展到新的籤名方案非常簡單：

1. 把它添加到 enum（枚舉類）

1. 實現fastcrypto庫中定義的 KeyPair trait

用戶籤名通過擴展一個額外的 1 字節標志來序列化，該標志標識關聯的籤名方案。盡管Sui團隊考慮過使用Multiformats（用於自描述數據的協議），但其可變標志長度的性質使得序列化存在問題。相反，Sui採用了單字節零起始標志模型。籤名方案及其對應的標志定義如下：

當用戶提交籤名交易時，交易執行指定以下參數：

• BSC（Binary Canonical Serialization）序列化transaction bytes 為Base64

• Signature scheme flag（籤名方案標識），可以傳參為“ed25519”或“secp256k1”

• 公鑰的Base64格式

• 其scheme對應的籤名的Base64

如下代碼是執行已籤名的交易，curl 如果成功則返回證書和交易結果。

如下代碼展示了 Sui 的全節點如何將 API 請求字段組裝成序列化籤名flag || signature || pubkey並在執行前進行驗證檢查。

Sui支持不同的籤名方案的緣由剖析

使用 secp256k1 橢圓曲线的 ECDSA 被比特幣、以太坊和其他加密貨幣廣泛採用。用戶可能更喜歡這種籤名方案，因為他們想利用現有的錢包和托管密鑰管理工具，例如閾值籤名（國內密碼學中的 翻譯為“門限密碼體系的門限籤名”）和多籤。此外，它與雲基礎設施和硬件安全模塊（常見的如密碼機 uk 硬件錢包等）具有更好的兼容性，同時支持從消息和籤名負載中恢復公鑰。

同時，Ed25519 是一種更現代的籤名方案，具有確定性快速籤名和簡化數學的特點。雖然 Typescript SDK 支持這兩種籤名方案。但是Sui還是選擇 Ed25519 作為推薦的 Sui 錢包算法。

因為Sui 支持不同籤名方案，在後面使用secp256r1曲线（也稱為 NIST-P256）添加諸如 ECDSA 之類的方案將花費很少的精力，這條曲线目前是原生手機和未來密碼學中都要支持的一條曲线，也是目前社區一個普遍要求的功能。

對這種靈活的籤名方案支持還使 Sui 系統與不安全的空籤名方案進行基准測試。對於像 Sui 這樣的快速執行系統，並行設計籤名和驗證也發生在事務級別，而不僅僅是區塊層，加密靈活性讓Sui Check出加密操作給系統帶來的开銷。這些基准測試結果已經能夠為Sui提供識別瓶頸和優化方向。

授權密鑰對

Authority on Sui（驗證者集合）持有三個不同的密鑰對：

• Protocol keypair 協議密鑰對

• Account keypair 帳戶密鑰對

• Network keypair 網絡密鑰對

Protocol keypair 協議密鑰對

如果用戶籤名的交易經過驗證，協議密鑰對會提供授權籤名。當為用戶交易提供籤名的權力機構的佔比超過所需的三分之二門檻時，Sui 將執行交易。目前選擇 BLS12381 方案來快速驗證給定數量的授權機構的聚合籤名。特別是決定使用 minSig BLS 模式，根據該模式，每個單獨的公鑰為 96 字節，而籤名為 48 字節。後者很重要，因為通常驗證者在每個紀元开始時注冊一次他們的密鑰，然後他們不斷地籤署交易；因此Sui優化了最小籤名大小。

注意！使用 BLS 方案，可以聚合獨立籤名，從而產生單個 BLS 籤名有效負載。Sui還將聚合籤名與bitmap（位圖）一起表示籤名的驗證器。這有效地將當局的籤名大小從(2f + 1) × BLS_sig大小減少到只有一個BLS_sig有效負載，這反過來具有網絡开銷優勢，可以獨立於驗證器集大小的壓縮交易證書。

密鑰材料類型別名集中在整個存儲庫使用的單個位置。事實上，僅通過changing the alias(更改別名)（對聚合籤名代碼中對的alias參數序列化傳參時候修改）就將協議密鑰的 Sui 從 Ed25519 切換到了 BLS12381。

為了解決 BLS12381 聚合籤名的潛在惡意密鑰攻擊，在權限注冊期間使用密鑰知識證明 ( KOSK )。當授權機構請求添加到驗證器集時，將提交並驗證所有權證明。校驗協議密鑰  kosk || protocol public key || sui address。與大多數標准不同，Sui的知識證明方案也提交到地址，這提供了額外的保護，防止來自另一個惡意驗證器的驗證器的BLS密鑰被惡意重用。

聚合籤名在兩種情況下很有用：

1. 當仲裁驅動程序從多個授權機構返回的SignedTransaction形成CertifiedTransaction時

1. 當權限形成SignedCheckpointSummary時，每個權限都會對檢查點內容進行籤名。

Account keypair 帳戶密鑰對

監管機構用來接收質押獎勵付款的账戶由账戶密鑰對保護，使用 Ed25519 作為籤名方案。

Network keypair 網絡密鑰對

私鑰用於執行QUIC對Narwhal primary 及其 worker 網絡接口所需的TLS握手。公鑰用於驗證節點 ID，Ed25519 用作籤名方案。

哈希和編碼靈活性

目前，Sui 的默認哈希函數是 sha3256，正在運行基准測試以與 sha256 和 blake2/blake3 系列進行比較。為了支持編碼靈活性，Base64和Hex在fastcrypto中定義了一個編碼特性，作為一個包裝器base64ct::Base64和 hex 及其定制的序列化和驗證。值得注意的是，選擇了base64ct crate 而不是最流行的 base64 Rust crate，因為 a) 它是恆定時間 b) 明確拒絕損壞的編碼以防止解碼時的延展性攻擊。Sui的研究團隊成員最近報告了大多數 base64 解碼器庫中令人驚訝的延展性問題，獲得了AsiaCCS 2022 最佳Poster獎，這是密碼學和安全領域的重要會議之一。

下面的代碼片段顯示了如何在fastcrypto中實現包裝器結構：

加密靈活性順應密碼學趨勢

憑借在密鑰對、籤名和哈希函數方面的加密的靈活性，Sui 在庫選擇、基礎籤名方案、編碼和哈希函數方面非常便捷。這不僅允許 Sui 在庫有發現漏洞或某種方案有bug的情況下快速升級，還允許根據選擇的cryptography primitives（密碼學原語）作為參數對整個系統進行基准測試。

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。