Signatures

Choosing between BLS aggregation, BBS+ selective disclosure, ECDSA canonicalization, verifiable random functions, and the chain-specific Schnorr variants.

Five very different things live under this heading, and they are not interchangeable. Before you pick one, decide which property you actually need: aggregation (many signatures collapse into one), selective disclosure (a holder proves a subset of signed attributes), determinism and canonical encoding (the same message always yields the same bytes), verifiable randomness (an output nobody can predict but everybody can check), or wire compatibility with a specific blockchain.

Every package here is a distinct construction with its own key type. There is no shared Signer interface across them, and keys from one scheme are never valid in another.

Pick a scheme

Some adjacent things are documented elsewhere:

• The interactive Schnorr proof of knowledge (zkp/schnorr) is a ZKP, not a signature scheme — see zero-knowledge/schnorr.
• Threshold ECDSA and threshold Ed25519 (FROST) produce ordinary ECDSA / Ed25519 signatures from distributed shares — see threshold ECDSA and threshold Ed25519. BLS threshold signing on this page is a different, much simpler construction: it needs no rounds of interaction.

What these packages assume about curves

signatures/bbs and the Mina scheme are written against the core/curves Curve / Point / Scalar abstraction — BBS+ specifically requires a *curves.PairingCurve (curves.BLS12381(...)). signatures/bls/bls_sig bypasses the abstraction entirely and calls the low-level core/curves/native/bls12381 backend directly, so it is hard-wired to BLS12-381. The ecdsa package operates on stdlib crypto/ecdsa and crypto/elliptic types, and vrf on a vendored Edwards25519 implementation.

The shared proof toolkit: signatures/common

signatures/common holds the sigma-protocol plumbing that BBS+ (and code composing proofs with BBS+) builds on. It is a building-block package — you rarely import it alone, but you will import it to construct BBS+ proof messages.

The four aliases are Go type aliases, not defined types: a common.Nonce is a curves.Scalar, so no conversion is needed and the compiler will not stop you passing a challenge where a nonce belongs. Treat the names as documentation, not as type safety.

ProofMessage and its three implementations

ProofMessage is how a BBS+ prover declares, per message, whether it is disclosed:

type ProofMessage interface {
	IsHidden() bool
	GetBlinding(reader io.Reader) curves.Scalar
	GetMessage() curves.Scalar
}

ProofCommittedBuilder

A small accumulator for Schnorr-style proofs of knowledge of a linear combination:

import "github.com/sonr-io/crypto/signatures/common"

builder := common.NewProofCommittedBuilder(curve)
_ = builder.CommitRandom(basePoint, crand.Reader) // blinding for a secret you know
_ = builder.Commit(otherPoint, knownScalar)       // fixed scalar

bytes := builder.GetChallengeContribution() // feed into your transcript
proofs, err := builder.GenerateProof(challenge, secrets)

GetChallengeContribution returns the compressed encoding of SumOfProducts(points, scalars) — the aggregate commitment. GenerateProof then returns one response scalar per commitment, computed as secret*challenge + blinding, and errors if len(secrets) does not match the number of commitments. Get(index) retrieves the (point, scalar) pair at a position, returning (nil, nil) out of range. The builder caps out at roughly 65535 commitments.

HmacDrbg

drbg := common.NewHmacDrbg(entropy, nonce, personalization, sha256.New)
buf := make([]byte, 64)
_, _ = drbg.Read(buf)
drbg.Reseed(moreEntropy)

It satisfies io.Reader, so it can be handed to any API here that takes a reader — which is how you make an otherwise randomised proof reproducible in a test.

Caveats that apply across this section

Where to next