BLINDFLARE

Blindflare is a zero-trust encrypted web system. All encryption, authentication, and validation are performed on your device. The server never sees your secrets.

Blindflare: A Zero-Trust Encrypted Web System

How It Works:

• Client-side ECC key generation: Your device creates a secure elliptic curve keypair. Private keys never leave your device.
• Zero-trust encrypted storage (ztStorage): All data is encrypted before upload. The server only stores encrypted blobs, never plaintext.
• Key-based authentication: No passwords are ever sent to the server. Authentication uses public key cryptography and cryptographic hashes.
• End-to-end encryption above the transport layer: Even if TLS is terminated at a proxy, your data remains encrypted and unreadable.
• Resistant to reverse proxy and backend compromise: If the server is breached, attackers gain nothing but encrypted data and public keys.

Technical Summary:

• Uses secp256k1 ECC for keypairs and signatures
• All encryption and decryption is performed locally
• ztStorage blobs are signed and verified client-side
• API requests and responses are encrypted with ECDH-derived symmetric keys
• No metadata, passwords, or secrets are ever exposed to the server

Core Principles

• Zero Trust: Assume the network and server are adversarial. Design so that compromise yields nothing useful.
• Client Sovereignty: Keys, crypto, and validation live on the client. The server is an untrusted courier.
• Minimized Metadata: Avoid leaking identities, relationships, or content-type hints whenever feasible.
• Cryptographic Verifiability: Every blob is signed; integrity and authenticity are validated locally.

Protocol at a Glance

1. Device generates an ECC keypair (secp256k1).
2. Registration publishes the public key and a verifier derived from the private key; the private key never leaves the device.
3. For each request, an ECDH exchange derives a fresh symmetric key to encrypt the payload and response.
4. Data is encrypted and signed locally, uploaded as opaque, content-addressed blobs.
5. On retrieval, the client verifies signatures and decrypts locally.

Cryptography

• Asymmetric: secp256k1 for keypairs and signatures.
• Key Agreement: ECDH on secp256k1 per-session or per-request.
• Symmetric: A modern AEAD cipher for payload confidentiality and integrity.
• Hashing: Fast, secure hash for key derivation and content addressing.

Threat Model

• Server compromise exposes only ciphertexts and public information.
• Reverse proxy/TLS termination cannot read application payloads.
• Replay and tamper attempts are detected by signatures and nonces.
• Phishing-resilience by avoiding password transmission entirely.
• Centralized proxies can become surveillance chokepoints (cf. “Room 641A”) unless payloads are encrypted above transport.

Use Cases

• Secure personal notes and vaults
• Team document sharing with client-held keys
• End-to-end encrypted APIs over untrusted infrastructure

Get Started

• Read the whitepaper for the full protocol.
• Explore the system overview.
• Check the FAQ and Legal pages.

The user owns the keys. The client owns the logic. The server is just a courier.