Sui 在設計底層技術時考慮到了密碼學的靈活性。該系統支持多種密碼算法和cryptography primitives（密碼原語），並可以在它們之間快速切換。開發人員不僅可以為系統選擇同類最佳的best-of-breed cryptography（公開密鑰密碼體系），還可以實施最新的algorithms（可用算法）。
Sui 在一個統一的類型別名或整個存儲庫共享的枚舉包裝器下定義其cryptography primitives（密碼學原語），例如公鑰、簽名、聚合簽名和哈希函數。對這些原語進行更改會影響應用程序的所有組件。開發人員可以快速更新應用程序密碼並確保統一的安全性。
目前Sui 通過執行交易端點支持以下用戶交易簽名方案：
1.Pure Ed25519
2.Secp256k1 ECDSA
用戶賬戶密鑰對的接口實現
下面是Sui 中密鑰對錶示的Demo。擴展到新的簽名方案非常簡單：
1.把它添加到enum（枚舉類）
2.實現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密鑰被惡意重用。
聚合簽名在兩種情況下很有用：
- 當仲裁驅動程序從多個授權機構返回的SignedTransaction形成CertifiedTransaction時
- 當權限形成SignedCheckpointSummary時，每個權限都會對檢查點內容進行簽名
Account keypair 帳戶密鑰對
監管機構用來接收質押獎勵付款的賬戶由賬戶密鑰對保護，使用Ed25519 作為簽名方案。
Network keypair 網絡密鑰對
私鑰用於執行QUIC對Narwhal primary 及其worker 網絡接口所需的TLS握手。公鑰用於驗證節點ID，Ed25519 用作簽名方案。
哈希和編碼靈活性
目前，Sui 的默認哈希函數是sha3256，正在運行基準測試以與sha256 和blake2/blake3 系列進行比較。為了支持編碼靈活性，Base64和Hex在fastcrypto中定義了一個編碼特性，作為一個包裝器base64ct::Base64和hex 及其定制的序列化和驗證。值得注意的是，選擇了base64ctcrate 而不是最流行的base64 Rust crate，因為a) 它是恆定時間b) 明確拒絕損壞的編碼以防止解碼時的延展性攻擊。 Sui的研究團隊成員最近報告了大多數base64 解碼器庫中令人驚訝的延展性問題，獲得了AsiaCCS 2022 最佳Poster獎，這是密碼學和安全領域的重要會議之一。
下面的代碼片段顯示瞭如何在fastcrypto中實現包裝器結構：
加密靈活性順應密碼學趨勢
憑藉在密鑰對、簽名和哈希函數方面的加密的靈活性，Sui 在庫選擇、基礎簽名方案、編碼和哈希函數方面非常便捷。這不僅允許Sui 在庫有發現漏洞或某種方案有bug的情況下快速升級，還允許根據選擇的cryptography primitives（密碼學原語）作為參數對整個系統進行基準測試。
