Security

Security issues are tracked publicly as advisories (something users should act on) and reviews (an issue was analysed and found not to apply). Report suspected vulnerabilities to security@snowblossom.org (see security.txt).

Advisories

SA-1 - ECDSA signing uses SHA-1 (30 Oct 2020, all versions, severity: none)

The ECDSA (and DSA) signature engines hash their input with SHA-1 before signing. The input is the 32-byte transaction id, itself a Skein-256-256 hash of the transaction bytes. SHA-1 is broken for collisions, but exploiting this would require a second preimage - finding another 32-byte value with the same SHA-1 - and that value would have to be the Skein hash of a different valid transaction. Breaking Skein that way would let an attacker forge transactions regardless of SHA-1. Impact: none; no user action. Planned fix: a signature-mode flag in SignatureEntry selecting SHA-256 (or SHA-3) without changing addresses, to be bundled with a future protocol change.

Reviews

SR-1 - CVE-2022-21449 “Psychic signatures” in Java (20 Apr 2022, severity: none)

Certain Java versions accepted ECDSA signatures with r = s = 0 as valid. Snowblossom always obtains its signature engines from the BouncyCastle provider (Signature.getInstance(algo, "BC")), never from the JDK's SunEC, and the team reproduced the bug on an affected JDK to confirm BouncyCastle rejects the blank signature while SunEC accepts it. Impact: none. A unit test (Cve2022_21449Test) guards against regressions.

Security properties of the design

• Transaction ids are not malleable - they hash opaque bytes that exclude signatures.
• Addresses hide keys until spending; with fresh addresses per payment, an attacker who can break a public key only gets a short window, and first-seen-first-added in the mempool favours the legitimate spend. Post-quantum key modes remove even that window.
• Nodes cannot lie about balances to clients that verify UTXO proofs against headers - they can only withhold.
• Peers cannot spoof identities: TLS certificates are signed by the node key they claim; trust-network membership is signed too.
• Fair launch: no premine, genesis anchored to a Bitcoin block hash.
• Work weighting (SIP-2) blunts snow-storm fork attacks; sharding's collision rule forces all shards onto one braid.

Practices for users and operators

• Wallet directories are not encrypted: seeds and keys are stored in clear. Use disk encryption and file permissions; treat export files as secrets.
• Non-seed wallets (standard, qhard, pqc) need fresh backups whenever new addresses are generated.
• Bind the JSON-RPC server to localhost; it is plain HTTP with basic auth. MrPlow's optional RPC has no auth at all.
• Prefer grpc+tls://…?key=node:… when using a node you do not control, and run your own node for privacy - a node sees which addresses a wallet asks about.
• Keep node, pool and wallet software current: SIP activations are hard forks with deadlines.
• Keep clocks synchronised; skewed clocks produce rejected blocks and signed messages.
• Independent implementers: note the sum-overflow remark on the transactions page, the 1 MB transaction limit, and that block size is a policy limit enforced by gRPC message size rather than consensus.