Skip to main content
ObsidianLog handles operational logs and the encryption keys that protect them. ObsidianLog is a self-hosted, user-controlled system.

​
Practices followed

  • Client-side encryption only. No plaintext log data ever leaves your infrastructure. Encryption happens before data is written to the Sia network and registered via indexd.
  • User-controlled keys. Key generation happens locally during obsidianlog init. The encryption key and (if configured) the Sia app key are stored together as one bundled credential in your OS keychain via the keyring crate, with a direct macOS Keychain API call used only for the initial creation step (see ADR-0015), or an explicit local secrets file with 0600 permissions if the keychain is genuinely unreachable. There is no key escrow and no key transmission.
  • Authenticated encryption. AES-256-GCM provides both confidentiality and ciphertext integrity. Tampered ciphertext is rejected at decryption time. Each chunk is sealed under its own key, derived with HKDF-SHA256 from your encryption key and a random per-chunk salt, so a key/nonce pair is never reused, even after a failed write or a restore from backup (ADR-0016).
  • Append-only storage model. Chunks are write-once. The storage model prevents in-place modification, relying on append-only writes combined with indexd-coordinated retrieval and SHA-256 hash chaining for tamper-evidence (obsidianlog verify).
  • No intermediary in the storage path. ObsidianLog connects to an indexd-backed Sia indexer for indexing and retrieval coordination, without any centralized intermediary. There is no ObsidianLog-operated proxy, gateway, or relay. ObsidianLog has zero access to user data. This holds whether you use the hosted default or bring your own indexer.
  • Dependency audit. The Rust dependency tree is audited with cargo audit in CI. Critical dependencies (zstd, aes-gcm, sha2) are maintained by the RustCrypto and zstd-rs communities with strong security track records.

​
Out of scope

The security of your own indexd deployment (if self-hosting), Sia host selection, and your own operational key-management practices are outside ObsidianLog’s control.

​
Reporting a vulnerability

Please report vulnerabilities privately using GitHub’s private vulnerability reporting (Security tab → “Report a vulnerability”). Do not open a public issue. Include, where possible: affected crate/version, a description, reproduction steps, and impact.