ZK Protocol

Technical Report & Implementation Guide: The Zero-Knowledge Messenger Protocol

 

1. The Zero-Knowledge Messenger

The Zero Knowledge Messenger (ZKM) is a minimalist and low-friction (easy to use) messaging system engineered for anyone who demands radical, mathematical privacy, including journalists, whistleblowers (sources), c-level executives, investigators and authorities. The ZK Messenger allows all registered users (with an active Gold account) to exchange encrypted messages using AES-256-CBC encryption algorithm locally (on the browser). The primary objective of this system is to guarantee total privacy by design, shifting the paradigm from “Server-Side Trust” to “Client-Side Certainty”.

Gallery (click on thumbnails)

zk-messenger-sendzk-messenger-send
zk-messenger-readzk-messenger-read
zk-messenger-public-ledgerzk-messenger-public-ledger
zk-hasherzk-hasher

The technical architecture of the ZK Messenger is built to ensure that the server (zkm.app.br) acts only as a blind relay, never as a custodian of secrets.

Key features, ZK flow and conditions are the following:

  1. ZKM Users are requested to create an account with an active email and real information if any (true identity) to comply with Brazilian Constitution (Art. 5 IV and XII). In order to maximize privacy and user’s security, whistleblowers can complete the registration process with a pseudonym as username and a Proton Mail as recovery email address to receive the activation link of the ZKM account. They may also opt for data minimization in their profile.
  2. Messages are encrypted locally by sender using the browser with a generated 64-character secret key derived from a SHA-256 hash of any local file or document via our Zero Knowledge hasher (ZK-Hasher).
  3. The recipient party (receiver) uses the same document to create the reading 64-character secret key. Note that all individual messages may be encrypted with a different 64-character secret key derived from a SHA-256 hash (or any password known by both parties: sender and receiver).
  4. ZKM Users may use the ZK Hasher SHA-256 to verify the integrity of any digital document at any time with total privacy.
  5. ZKM Users may delete their accounts and messages at any time (profile section).
  6. ZKM relies on the privacy of your keyboard. Therefore, to limit risk of any malicious “espionage” you shall install a secure keyboard (Florisboard) on your smartphone or use the author’s CR-APP Sovereign Writer (immune to keyboard logger) to write your secret text and copy and paste its content in the message area.
  7. ZKM Users may send encrypted messages to recipients (emails) that do not have an account yet. Once the recipient registers, the messages can be decrypted using the corresponding secret key. Users cannot send messages directly to aliases. The alias is an obfuscation chosen by the sender only.

ZKM Users may use the ZK Messenger in the following circumstances:

  1. Forensic Auditors: Securely exchange sensitive fraud analysis and technical memorandums using confidential workpapers as local entropy keys.
  2. Compliance Officers: Deploy a friction-free corporate whistleblowing line allowing anonymous reports encrypted via the company’s public Code of Ethics PDF.
  3. C-Level Executives: Align sensitive M&A strategies and pre-takeover proposals completely isolated from corporate email servers and network administrators.
  4. Investigative Journalists: Protect whistleblowers and safely receive high-profile government leaks by establishing an unreadable, non-custodial client-side relay tunnel.
  5. Defense Attorneys: Blueprint complex defense strategies and plea-bargain drafts utilizing the client’s digital power of attorney as the offline cipher key.
  6. Tech Founders: Share proprietary source code, patent blueprints, and core AI algorithms before official registration via local browser sandbox encryption.
  7. Expedition Leaders: Coordinate tactical route planning and offline cartographic emergency logs for high-altitude mountaineering directly within remote field terminals.

2. ZKM Accounts

The ZK Messenger messaging service is a premium architecture structured into three operational levels:

  • Bronze (Evaluation Account): Initial baseline access. It allows users to explore the local interface and test the ZK Hasher SHA-256 tool for 7 days.
  • Silver (Trial Terminal Account): Sandbox testing environment. It unlocks full ZK Messenger capabilities for a 7-day testing window via promotional token activation.
  • Gold (Production Node Account): Full production status. It provides continuous, unrestricted access to the ZK Messenger ecosystem for up to 180 days. This is a unique fee. To enforce maximum data hygiene and zero-server footprint, Gold users are highly recommended to manually delete their accounts and purged message histories on a semester basis, prior to their account expiration date, resetting their cryptographic vault. Note that expired accounts may be deleted at any time.

3. Client-Side Key Generation (The Zero-Knowledge Vault)

The core axiom of this protocol is: The server never touches the private encryption keys.

  • User-Defined Entropy: Encryption keys are generated locally on the user’s terminal using high-entropy seeds, bypassing traditional network key-exchange vulnerabilities.
  • Non-Custodial Architecture: At no point in the transmission is the encryption key transmitted to our database. The server only stores the Public Proof (encrypted payload blob), which is mathematically useless for decryption without the key. Encrypted blobs of recent messages are published directly in our Zero-Knowledge Live Public Ledger.

4. The ZK-Hasher Engine: Sovereign Document Entropy

To eliminate the human factor in password vulnerability, the platform integrates a proprietary ZK-Hasher interface designed for absolute cryptographic isolation:

  • Zero-Network Footprint: The ZK-Hasher operates 100% locally within the client’s browser sandbox via the native Web Crypto API (crypto.subtle.digest). The chosen document or seed file is read into the browser’s volatile memory (ArrayBuffer) and processed locally. The source document is never uploaded to the internet or exposed to the website’s host server.
  • Deterministic Key Derivation: Any standard offline file (e.g., a shared digital document, image, or forensic log) acts as a mathematical anchor, generating an identical, reproducible, and unfeasible-to-crack 64-character hexadecimal SHA-256 key. This converts any user asset into a bulletproof symmetric key cipher.

5. Forensic Hashing & Dynamic Alias Masking

To satisfy the ZK Protocol standards, every packet must have a “Digital Birth Certificate” while protecting the identities involved in sensitive communications:

  • Data Integrity & Identity Obfuscation: Each message is mapped via a SHA-256 string before leaving the terminal. Users can optionally define a dynamic Alias or Codename for compliance or internal whistleblowing channels, masking their identity from the recipient’s visual inbox.
  • Immutable Anchoring & Forensic Shield: While the Public Ledger displays only blind cryptographic fingerprints (Hashes), the server anchors the authenticated session (Email and IP) into a separated, isolated Private Ledger. This creates a legal “fuse” against malicious or false accusations, complying with Brazilian constitutional anti-anonymity frameworks without exposing the unreadable, encrypted content.

6. The Public Ledger: Real-Time Audit

The ZK Public Ledger is the transparent heart of the ZK protocol. It is a read-only stream of cryptographic events, visible to all but decodable by none except the intended recipient who holds the corresponding key document.

  • Live Registry: It displays the hexadecimal fingerprints (Hashes) of every successful relay in real time.
  • Status: It confirms that the Zero-Knowledge Tunnel is operational, providing a live, immutable feed of system integrity.

7. Execution Logic: The Triple-Layer Isolation

The system operates on three independent layers connected securely by the authenticated Membership Session, completely eliminating the friction of secondary fake accounts:

  1. Subscription Layer: Manages sovereign account access, billing, and system level control, keeping bots and spam out of the eco-system.
  2. Transmission Layer: Handles the local runtime cryptographic processing (CryptoJS / WebCrypto API) inside the user’s browser.
  3. Audit Layer (ZK Tables): Splits data into a blind Public Ledger for auditing and an anchored Private Ledger for absolute server security and legal compliance.

8. Step-by-Step Guide: Establishing an Open Whistleblowing Channel

To implement an internal reporting line compliance mechanism using the ZK framework, execute the following workflow:

  1. Define the Destination Anchor: The compliance committee, auditor, or ombudsman must hold a stable, secure destination e-mail address registered inside the system to act as the recipient target identifier.
  2. Publish the Sovereign Entropy Asset: The organization must publish an official public file on the portal (e.g., the corporate Code of Ethics PDF or an Institutional Guideline). This file will serve as the public source for local key generation.
  3. Access the ZK Account (destination anchor): Both the organization and the logged-in whistleblower access the ZK Messenger interface to execute the communication (send and read messages), with identity verification and traffic monitoring already handled natively by the platform active session. The whistleblower may use an alias or code-name to protect themselves from any form of retaliation.

9. Operational Manual: Operating inside the ZK Messenger Workspace

Follow these operational protocols to execute secure messaging relays entirely within a single interface:

Phase A: Encrypting and Sending ZK Messages

  • Log into your secure account and navigate to the ZK Messenger panel.
  • Input the destination ombudsman/recipient’s official e-mail address in the Recipient’s Email field.
  • Local Key Generation: Access the ZK Hasher and Drag and drop the company’s published public document (PDF/Image) directly into the integrated dropzone. The interface’s native Web Crypto API will instantly compute the 64-character SHA-256 key without uploading the file. Copy and paste the key in the ZK Messenger panel.
  • Identity Masking: Type a desired identifier into the Alias or Codename field (e.g., anonymous or pseudo) to mask your real e-mail from the recipient’s human eye.
  • Compose the text report inside the message canvas and trigger execution. The client-side cipher seals the payload locally before execution.

Phase B: Receiving and Reversing ZK Messages

  • The authorized recipient logs into their assigned account and accesses the Receive Encrypted ZK Messages tab.
  • Local Key Generation: Access the ZK Hasher and Drag and drop the company’s published public document (PDF/Image) directly into the integrated dropzone. The interface’s native Web Crypto API will instantly compute the 64-character SHA-256 key without uploading the file. Copy and paste the key in the ZK Messenger panel.
  • Execute the synchronization interface sequence. The browser retrieves the matching payload blobs and reverses the AES-256-CBC cipher stack directly inside RAM. The sender will appear strictly under their chosen Alias identifier, keeping the internal environment completely blind.

The Ledger is Live

The protocol is currently executing. By eliminating the “black box” of server-side encryption and placing the keys exclusively in the users’ hands, we have removed the single point of failure.

  • Current Protocol Status: Active.
  • Encryption Standard: User-Defined / AES-256-CBC (Local Client Storage).
  • Key Generation Protocol: Local Client-Side WebCrypto API / SHA-256.
  • Audit Standard: SHA-256 Public / Private Anchored Ledger.