Sui designed the underlying technology with the flexibility of cryptography in mind. The system supports multiple cryptographic algorithms and cryptography primitives (cryptographic primitives), and can quickly switch between them. Developers can not only choose best-of-breed cryptography (public key cryptography) for their systems, but also implement the latest algorithms (available algorithms).

Sui defines its cryptography primitives, such as public keys, signatures, aggregate signatures, and hash functions, under a unified type alias or enum wrapper shared across the repository. Making changes to these primitives affects all components of the application. Developers can quickly update application passwords and ensure unified security.

Currently Sui supports the following user transaction signature schemes through the execution transaction endpoint:

1.Pure Ed 25519 

2.Secp 256 k 1 ECDSA

Interface implementation of user account key pair

Below is a demo of key pair representation in Sui. Extending to new signature schemes is easy:

1. Add it to enum (enum class)

2. Implement the KeyPair trait defined in the fastcrypto library

User signatures are serialized by extending an additional 1-byte flag that identifies the associated signature scheme. Although the Sui team considered using Multiformats (a protocol for self-describing data), its variable-flag-length nature made serialization problematic. Instead, Sui uses a single-byte zero-start flag model. The signature schemes and their corresponding flags are defined as follows:

When a user submits a signed transaction, the transaction execution specifies the following parameters:

1. BSC (Binary Canonical Serialization) serializes transaction bytes to Base 64

2. Signature scheme flag (signature scheme identification), which can be passed as "ed 25519" or "secp 256 k 1"

3. Base 64 format of the public key

4. Base 64 of the signature corresponding to its scheme

The following code executes a signed transaction, and curl returns the certificate and transaction result if successful.

The following code shows how Sui's full node assembles the API request fields into a serialized signature flag || signature || pubkey and performs verification checks before execution.

Analysis of the reasons why Sui supports different signature schemes

ECDSA using the secp 256 k 1 elliptic curve is widely adopted by Bitcoin, Ethereum, and other cryptocurrencies. Users may prefer this signature scheme because they want to take advantage of existing wallet and escrow key management tools, such as threshold signatures (translated as "threshold signatures of threshold cryptosystems" in domestic cryptography) and multi-signatures. In addition, it has better compatibility with cloud infrastructure and hardware security modules (common ones such as cipher machine uk hardware wallets, etc.), and supports recovery of public keys from messages and signature payloads.

Meanwhile, Ed 25519 is a more modern signature scheme featuring deterministic fast signatures and simplified mathematics. Although the Typescript SDK supports both signature schemes. But Sui still chooses Ed 25519 as the recommended Sui wallet algorithm.

Because Sui supports different signature schemes, it will take little effort to add schemes such as ECDSA later using the secp 256 r 1 curve (also known as NIST-P 256 ), which is currently the key to native mobile and future cryptography. It is a curve that must be supported, and it is also a function generally requested by the community.

Support for this flexible signature scheme also enables the Sui system to be benchmarked against the insecure null signature scheme. For a fast-executing system like Sui, the parallel design of signing and verification also happens at the transaction level, not just at the block level, and the cryptographic flexibility allows Sui to check the overhead that cryptographic operations bring to the system. These benchmark results have been able to provide Sui with identifying bottlenecks and directions for optimization.

Authorization key pair

Authority on Sui (validator set) holds three different key pairs:

1. Protocol keypair protocol key pair

2. Account keypair account key pair

3. Network keypair Network key pair

Protocol keypair protocol key pair

The protocol key pair provides authorized signatures if the transaction signed by the user is verified. Sui will execute transactions when the percentage of authorities providing signatures for user transactions exceeds the required two-thirds threshold. The BLS 12381 scheme is currently chosen to quickly verify aggregate signatures for a given number of authorities. In particular it was decided to use the minSig BLS mode, according to which each individual public key is 96 bytes and the signature is 48 bytes. The latter is important because typically validators register their keys once at the beginning of each epoch, and then they sign transactions continuously; thus Sui optimizes the minimum signature size.

Notice! Using the BLS scheme, independent signatures can be aggregated, resulting in a single BLS-signed payload. Sui also aggregates the signature together with a bitmap (bitmap) to represent the signature's verifier. This effectively reduces the authority's signature size from (2f + 1) × BLS_sig size to only one BLS_sig payload, which in turn has the network overhead advantage of compressing transaction certificates independent of validator set size.

Key material type aliases are centralized in a single location used throughout the repository. In fact, only by changing the alias (changing the alias parameter in the aggregate signature code when serializing and passing parameters) the Sui of the protocol key was switched from Ed 25519 to BLS 12381.

To address potential malicious key attacks on BLS 12381 aggregate signatures, Proof of Key Knowledge (KOSK) is used during authority registration. Proof of ownership is submitted and verified when an authority requests to be added to a validator set. Verify protocol key kosk || protocol public key || sui address. Unlike most standards, Sui's proof-of-knowledge scheme is also committed to addresses, which provides additional protection against malicious reuse of a validator's BLS key from another malicious validator.

Aggregated signatures are useful in two situations:

When the quorum driver forms a CertifiedTransaction from SignedTransactions returned from multiple authorities

When the authority forms a SignedCheckpointSummary, each authority signs the checkpoint content

Account keypair account key pair

Accounts used by regulators to receive staking reward payments are secured by account key pairs, using Ed 25519 as the signature scheme.

Network keypair Network key pair

The private key is used to perform the TLS handshake QUIC requires for the Narwhal primary and its worker network interfaces. The public key is used to verify the node ID and Ed 25519 is used as the signature scheme.

Hashing and Encoding Flexibility

Currently, Sui's default hash function is sha 3256 and benchmarks are being run to compare against sha 256 and the blake 2/blake 3 family. To support encoding flexibility, Base 64 and Hex defines an encoding feature in fastcrypto as a wrapper around base 64 ct::Base 64 and hex and its custom serialization and validation. Notably, the base 64 ct crate was chosen instead of the most popular base 64 Rust crate because a) it is constant time and b) explicitly rejects broken encodings to prevent malleability attacks when decoding. Members of Sui's research team recently reported surprising scalability issues in most base 64 decoder libraries, winning the Best Poster Award at AsiaCCS 2022, one of the premier conferences in the field of cryptography and security.

The following code snippet shows how the wrapper structure is implemented in fastcrypto:

Encryption Flexibility Follows Trends in Cryptography

With cryptographic flexibility in terms of key pairs, signatures, and hash functions, Sui is handy in library choice, underlying signature schemes, encodings, and hash functions. This not only allows Sui to be updated quickly if a library has a discovered vulnerability or a scheme has a bug, but also allows benchmarking of the entire system based on selected cryptography primitives as parameters.