Skip to content

Security: AdetsGithub/SonicDrop

Security

SECURITY.md

SonicDrop security (Rust implementation)

This document describes the threat model, cryptographic usage, and operational security considerations for the sonicdrop-rs crate (Tokio + libp2p + SQLite + ring/RustCrypto). It replaces any prior documentation that referred to the removed Python stack.

Threat model (summary)

Adversary Capabilities Mitigations in sonicdrop-rs
Passive network observer Timing, sizes, graph metadata Payloads encrypted; onion layering; chaff worker (workers/chaff.rs)
Malicious DHT / storage node Drop, censor, observe access patterns AES-GCM + AAD binding to H_target; oblivious store semantics in protocol
Malicious relay Drop/delay onion hops Ephemeral layer keys (network/onion.rs); limited visibility per hop
Active network attacker at handshake MITM ultrasonic channel Out-of-band verification expectation; shared k_root only after successful handshake path
Compromised device Full memory, keys, plaintext Out of scope for the protocol - protect endpoints separately

Cryptographic primitives (as implemented)

Mechanism Crate / usage Notes
X25519 x25519-dalek ECDH for handshake and onion layers
Ed25519 ed25519-dalek Onion layer signing where specified in code
HKDF-SHA256 hkdf, sha2 Session keys, onion keys, handshake k_root, hard resync
AES-256-GCM ring Inner payload and onion layer payloads; 12-byte IV, 16-byte tag
SHA-256 sha2 / ring H_target, digests

HKDF salt / info inventory (code)

Exact byte strings are in source; this table is the authoritative list for the Rust tree:

Salt Info Location
SonicDrop_handshake_v1 k_root src/handshake/mod.rs
SonicDrop_session_v1 `session_{A->B B->A}epoch{n}`
SonicDrop_onion_v1 layer_store, layer_relay, per-layer layer_rel_{idx} src/network/onion.rs
SonicDrop_backup_v1 hard_resync src/protocol/epoch.rs

Inner payload AAD is the 32-byte H_target (encrypt_inner_payload / decrypt_inner_payload in src/crypto/mod.rs).

Key material and storage

  • SQLite (sqlx) holds serialized client state (src/state/db.rs, migrations under migrations/). Protect database files with filesystem permissions and full-disk encryption as appropriate.
  • No Python-era key encryption: there is no SONICDROP_KEY_PASSPHRASE path in the Rust crate; keys live in the DB / WAJ files as implemented in handshake and state.
  • Environment: SONICDROP_BOOTSTRAP, SONICDROP_DATA_DIR, relay limits - see src/config.rs and RUNBOOK.md.

Operational checklist

  • Set bootstrap peers (SONICDROP_BOOTSTRAP) to known-good nodes in production.
  • Restrict relay circuit limits (SONICDROP_RELAY_*) to match fleet capacity.
  • Run cargo test after upgrades; pin dependency versions intentionally in Cargo.toml / Cargo.lock.

Known limitations

  • Classical cryptography only - no post-quantum hybrid.
  • Endpoint compromise defeats confidentiality for future messages on that device.
  • SAS / manual verification for the ultrasonic path depends on users comparing secrets out of band.

Reporting

For a private repository, track security fixes with fix: / fix(security): conventional commits and keep SECURITY.md in sync when threat-relevant behavior changes.

There aren't any published security advisories