1Bridge Vault

Technology

Four Pillars of Confidentiality

How a document is handled at each stage, from upload through verification.

01

Client-Side Vault Encryption

Documents are encrypted in the browser before they reach us. We store only ciphertext and wrapped keys, so a server breach exposes encrypted data rather than passport scans.

How it works

  • ·Vault password → Argon2id → KEK (key encryption key)
  • ·Each document gets a random DEK encrypted with AES-256-GCM
  • ·DEK is wrapped with your KEK; only wrapped blobs are uploaded
  • ·Share links generate a link session key (LSK); DEKs are re-wrapped for vendor access
  • ·Vendor secret → HKDF-SHA256 → wrapping key to unwrap the LSK
  • ·Ciphertext lives in a private storage bucket; signed URLs expire in minutes
02

Visible + Invisible Watermarking & Verification

Every file is stamped in the browser with a traceable marker before a vendor can view it. If a copy is later leaked, the reference identifies the recipient and the moment it was opened.

How it works

  • ·After client-side decryption, watermarks are applied in the browser
  • ·Each stamp includes vendor label, timestamp, purpose notes, and a unique UUID reference ID
  • ·Invisible carrier watermark + visible overlay on images and PDFs
  • ·Signed contracts get a stable payload: 1Bridge · Blockchain-attested · Verify: {url}
  • ·Public /verify page resolves watermark references against the audit log
  • ·Anyone with a copy can check whether a reference ID is genuine
03

Bitcoin-Based Attestation & Certification

When you counter-sign, the hash of the final PDF is recorded on the Bitcoin blockchain. Anyone can confirm what was signed and when, independently of 1Bridge.

How it works

  • ·Each signing stage records pre- and post-signature SHA-256 hashes
  • ·Tampering between stages breaks the hash chain and rejects the request
  • ·On owner finalization, the document hash is submitted to OpenTimestamps
  • ·Attestation status moves: pending → stamped → confirmed (Bitcoin block)
  • ·A standalone verification certificate PDF is generated and stored encrypted
  • ·Public verification at /verify?sig= recomputes the upload hash against the attestation record
04

Delegation

Ops and legal can manage sharing and signing while you retain the only keys. Delegates work with requests and metadata; the material that decrypts documents never reaches them.

How it works

  • ·Owner invites delegates via email; delegates accept team membership
  • ·Delegates create share requests or signing requests, not live links
  • ·Only the owner approves shares and generates vendor secrets
  • ·Delegates never receive KEK, DEK, LSK, or vendor secret values
  • ·Owner sees full audit trail; delegate actions are logged separately
  • ·Revocation and approval always trace back to the vault owner

See It in Action

Use Cases Built on These Pillars

Secure Document SharingContract Signing & AttestationFree Tools

The entire vault is built on these foundations

Join the waitlist for encrypted sharing, contract signing, and Bitcoin-attested verification in one vault.