Register

How SkiveCore Protects Your Private Chats

Guide Updated: September 2026

At SkiveCore, we believe true privacy is not a matter of trust or corporate promise—it is a mathematical guarantee. SkiveCore Messenger implements modern, Signal-grade End-to-End Encryption (E2EE) paired with state-of-the-art anonymous metadata protection. Your messages are encrypted directly on your device before they ever touch the network, and they can only ever be decrypted by the intended recipient.

Scope Notice: This advanced cryptographic protection applies to all direct, one-on-one conversations in SkiveCore Messenger. Publicly visible features—such as public posts, blog entries, video comments, and public profile bios—are designed for public discovery and are delivered securely over HTTPS without private-key encryption.

The Foundation: Signal-Grade Cryptography

SkiveCore uses industry-standard, battle-tested cryptographic primitives powered by libsodium. We do not invent custom ciphers; we utilize the highest-grade mathematics reviewed and trusted by global cryptographers:

  • Curve25519 (X25519): Ultra-fast, high-security elliptic curve Diffie-Hellman key agreement used to negotiate shared secrets without ever exposing them across the wire.
  • Ed25519: State-of-the-art digital signature algorithm used to cryptographically verify identity keys and prevent impersonation or man-in-the-middle attacks.
  • XChaCha20-Poly1305 & ChaCha20-Poly1305: Authenticated Encryption with Associated Data (AEAD) delivering symmetric message encryption with tamper-proof cryptographic integrity verification.
  • HKDF-SHA256: HMAC-based Key Derivation Function used to continuously ratchet and evolve message keys forward.

Your Device, Your Master Key: When you register on SkiveCore, your client device generates your primary Identity Key Pair. Your private key never leaves your device unencrypted. Before it is ever backed up to secure storage, it is encrypted using an encryption key derived locally from your password using memory-hard key derivation. SkiveCore servers never see your password and never have access to your unlocked private key.

The Handshake & Server-Side Metadata Eradication

Most messaging apps protect message content but constantly log and preserve who is talking to whom (the social graph). SkiveCore is architected specifically to eliminate this metadata trail using our two-tier identity architecture:

  • Public ID (Discovery Only): A user-facing handle used solely to look someone up or accept an initial conversation invitation.
  • Private ID (Routing Token): A cryptographically secure, randomized token generated specifically for anonymous message delivery.

How a Conversation Begins: The Greeting Card Handshake

  1. Asynchronous Session Setup (X3DH): When you reach out to someone new, your device fetches their public Pre-Key Bundle (containing their Identity Key, Signed Pre-Key, and an ephemeral One-Time Pre-Key). Your device generates an Ephemeral Key and performs an Extended Triple Diffie-Hellman (X3DH) exchange.
  2. The Sealed Greeting Card: Your device packages your encrypted Private ID along with the session setup parameters into a temporary "Greeting Card" addressed to the recipient's Public ID.
  3. The Mutual Acknowledgment: When the recipient opens SkiveCore, their device decrypts the greeting card, calculates the matching secret keys, registers your Private ID, and sends an encrypted acknowledgment back.
  4. Permanent Public ID Eradication: The moment the handshake is complete, the server executes a permanent nullification of both public identifiers (sender_public_id = NULL and recipient_public_id = NULL).

What this means: Once a conversation is initiated, all ties to your public profile and usernames are permanently eradicated on our servers. Subsequent messages are routed exclusively through anonymous, random routing tokens. The platform literally cannot reconstruct your social graph or tell who you are speaking with.

The Double Ratchet: Continuous Key Rotation

In traditional systems, an entire chat history relies on one static session key. If that key is ever exposed, all past and future communications are compromised. SkiveCore prevents this by implementing the Double Ratchet Protocol:

  • Symmetric KDF Ratchet (Every Single Message): Every time you send or receive a message, the internal key ratchet advances forward. A single-use message key is derived, used to encrypt or decrypt that single message, and then immediately destroyed from memory. It can never be used again.
  • Diffie-Hellman Ratchet (Every Conversational Turn): Whenever the flow of conversation switches between participants (Alice sends, then Bob replies), both devices exchange a new ephemeral Curve25519 public key in the message header. This creates a brand new Diffie-Hellman secret, generating entirely fresh root keys.

This dual-ratchet architecture provides two critical security properties:

  • 1. Forward Secrecy (PFS): Even if an adversary were to gain physical access to your device today, they cannot decrypt messages sent in the past, because past keys were permanently erased and cannot be calculated backward.
  • 2. Break-In Recovery (Post-Compromise Security): If an attacker temporarily intercepts keys from an active session, as soon as you and your conversation partner exchange a new turn, the Diffie-Hellman ratchet self-heals. New secrets are established that the attacker cannot calculate, restoring complete privacy immediately.

Sender-Blind Sealed Delivery (Sealed Sender)

On most platforms, even if the message body is encrypted, the server still inspects the header: "User A sent this envelope to User B."

SkiveCore uses Sealed Sender Delivery:

  • When your device dispatches a message, it wraps both your identity and the message content inside a cryptographically sealed payload addressed only to the recipient's private routing token.
  • The server receives only an opaque destination mailbox token (recipient_token) and the sealed ciphertext blob.
  • The server has no record of who transmitted the envelope. To the server, an anonymous package was dropped into an anonymous drop box. Only the recipient possesses the private key required to unseal the payload and verify who sent it.

Exactly What Is Encrypted vs. Visible

We believe in complete transparency. Here is the precise technical breakdown of what is encrypted on your device versus the minimal operational parameters processed during transit:

Message Element Encrypted On Device? Who Can Read or Inspect It?
Message Text / Content ✔ Yes (Double Ratchet AEAD) Only sender and recipient. Completely unreadable to SkiveCore.
Sender Identity ✔ Yes (Inside Sealed Envelope) Only recipient. Server delivers blindly without sender tags.
Media & Attachments ✔ Yes (Client-Side Encrypted) Encrypted with random symmetric keys passed through E2EE text. Server holds raw ciphertext only.
Replies, Quotes & Reactions ✔ Yes (In Encrypted Payload) Only sender and recipient.
Chat History & Transcripts ✔ Yes (Stored in Local Browser/Device) Stored in browser local sandboxes. Server retains no decrypted history.
Ephemeral Ratchet Public Key Transmitted in Header Random Curve25519 point. Mathematically useless without private DH keys.
Recipient Routing Token Opaque Routing Identifier Used exclusively by delivery queue to route envelope to the right mailbox. Contains no username or profile identity.

What Zero-Knowledge Means for Us as a Platform

When we say SkiveCore knows virtually nothing about your private conversations, we mean it literally:

  • We Cannot Read Your Messages: We do not hold decryption keys. We have no master backdoor, no escrow keys, and no algorithmic bypass. It is mathematically impossible for any SkiveCore engineer or server admin to read your chats.
  • We Cannot Reconstruct Conversation Graphs: Because the server erases public IDs as soon as a conversation begins and utilizes sender-blind envelopes, our databases do not show who is corresponding with whom.
  • We Cannot Be Compelled: You cannot be forced to turn over what you do not have. Even if served with legal subpoenas, warrants, or court orders, SkiveCore can only produce unintelligible ciphertext blobs and random cryptographic routing tokens.
  • Strict Moderation Non-Intervention: Our moderation team never monitors, inspects, or intervenes in one-on-one private chats. Your private messages are sacred, personal communications.
  • Zero Inspection of Exported Transcripts: When users export or download a cryptographic chat transcript, your device verifies the digital signatures locally. SkiveCore moderation does not review or arbitrate direct chat exports. The export exists so you have verifiable, tamper-evident proof to present to external mediators, legal representatives, or law enforcement if you ever need to resolve a matter independently outside of SkiveCore.

The Browser Environment: Extension Risks, XSS & Code Integrity

A common and critical question asked by security analysts and privacy researchers is:

"The platform relies on solid components: libsodium primitives, standard X3DH/Double Ratchet, memory-hard key derivation for browser recovery, and a database that automatically wipes public IDs to break social graphs.

The primary remaining vulnerability is inherent to browser-based encryption: because the client code runs in a web browser, users must trust that the web server serves clean JavaScript on every page load without intercepting the passphrase or keys in memory."

This observation is technically astute and completely accurate. In cybersecurity, this is known as the Browser Cryptography Dilemma. While our underlying mathematical algorithms (Curve25519, XChaCha20-Poly1305, Double Ratchet) are mathematically unbreakable by network eavesdroppers or database compromise, the runtime environment inside your web browser is the physical boundary where encryption meets the user interface.

Below is a transparent analysis of the real-world browser threat vectors, how SkiveCore defends against them, how you can independently verify the code executing on your device, and recommended best practices for high-security environments.

1. Browser Extensions: The Silent Eavesdropper

The Threat: Web browser extensions (ad blockers, grammar checkers, translation utilities, coupon tools, crypto wallets) run with elevated permissions above the normal webpage sandbox. Many popular extensions routinely demand permissions such as: "Read and change all your data on the websites you visit."

An extension with this capability can inject background scripts directly into the webpage Document Object Model (DOM). It can monitor keystrokes as you type your message into the chat input, capture cleartext messages straight from your screen after your browser decrypts them, or attempt to inspect localStorage. Even initially safe extensions can pose severe risks if their developer accounts are compromised or sold to third-party data brokers.

How to Protect Against Extension Snooping:

  • Dedicated Clean Browser Profile: For high-privacy communications, configure a separate browser profile (in Chrome, Brave, Firefox, or Edge) dedicated solely to SkiveCore with zero third-party extensions installed.
  • Incognito / Private Browsing Windows: By default, modern browsers disable all extensions in Private/Incognito windows unless you have explicitly granted them permission. Using a private window provides a clean, isolated sandbox.
  • Audit Extension Permissions: Regularly audit your extensions via chrome://extensions or about:addons. Disable or uninstall extensions that request blanket access to all websites without a compelling, verifiable justification.

2. Cross-Site Scripting (XSS) & Memory Isolation

The Threat: If an attacker could inject unauthorized JavaScript into the origin (XSS), that foreign code would execute in the same origin as the encryption engine, potentially attempting to read cleartext variables or export session keys in memory.

How SkiveCore Mitigates XSS & Code Injection:

  • Strict Content Security Policy (CSP): SkiveCore enforces strict CSP directives that forbid the loading of unapproved external scripts and restrict network connections (connect-src). Even in the theoretical scenario of an injection attempt, the browser blocks foreign code from exfiltrating data to external servers.
  • Safe DOM Rendering & Context Escaping: All usernames, text fields, and incoming payloads are sanitized and inserted using safe DOM properties (such as textContent) rather than unescaped innerHTML, eliminating script execution avenues.
  • Ephemeral Memory & Immediate Key Destruction: Message keys generated during the Double Ratchet process are used once and immediately destroyed. Private keys are never stored in raw plaintext on disk; they remain shielded behind memory-hard key derivation.

3. Verifying "Clean JavaScript" On Every Page Load

The Threat: Because web applications load JavaScript dynamically over the network, how can users be certain that the server is serving authentic, untampered code rather than a modified payload attempting to exfiltrate keys?

We provide full transparency and independent verification mechanisms:

  • Public Cryptographic Checksums: Every production release of SkiveCore's cryptographic engine (SignalWebCrypto.js and chat.js) is tagged to public git commits with published SHA-256 and SHA-384 cryptographic checksums.
  • Independent Verification via Terminal or DevTools: Anyone can audit the exact code executing in their browser:
    1. Open your browser's Developer Tools (F12 or Ctrl+Shift+I) and view the Sources or Network tab.
    2. Inspect the loaded cryptographic script, or fetch its checksum directly from your terminal:
      curl -s https://skivecore.com/js/crypto/SignalWebCrypto.js | sha256sum
    3. Compare this hash against the published release hash in our official repository. A match guarantees the code running on your machine is identical to the audited open-source implementation.
  • Strict Transport Security (HSTS) & TLS 1.3: SkiveCore enforces HSTS with preloading, ensuring that no intermediate network, rogue Wi-Fi access point, or hostile ISP can intercept or alter JavaScript files in transit.

4. Web Browsers vs. Native Apps: Maximum Hardware Isolation

While browser-based messaging provides seamless cross-platform accessibility, users with elevated threat models should understand the fundamental difference between a browser and a native client:

  • Compiled & Signed Binaries: Unlike a browser where code is fetched over HTTP on each session, native applications (like the official SkiveCore Android App) are compiled, cryptographically signed binaries audited as a fixed release.
  • Hardware-Backed Keystore (TEE / StrongBox): On native mobile devices, cryptographic private keys can be bound to hardware security chips (Hardware Security Modules / Android Keystore). Keys generated inside a hardware enclave cannot be extracted even if the host operating system is compromised.
  • Complete Immunity from Browser Extensions: Native mobile apps run inside their own isolated operating system sandboxes, completely free from browser extension hooks, DOM scrapers, or browser-based session hijacking.

Recommendation: For everyday communications, a clean browser profile offers strong, practical privacy. For sensitive investigative, journalistic, or high-risk communications, we strongly recommend using the official SkiveCore Android App for hardware-isolated protection.

User Security Checklist: Browser Best Practices

  • 🔒 Profile Isolation: Use a dedicated browser profile with zero extensions for sensitive communications.
  • 🛡️ Disable Blanket Permissions: Remove extensions with broad "read and change data on all websites" permissions.
  • 💻 Operating System Hygiene: Keep your browser and OS updated to ensure prompt patching of V8 and WebKit vulnerabilities.
  • 🔍 Audit Code Hashes: Verify the SHA-256 checksum of SignalWebCrypto.js against our public repository whenever you require absolute verification.
  • 🚪 Log Out on Shared Hardware: Always log out and close browser sessions when using workstations shared with other individuals.
  • 📱 Use Native Clients When Stakes Are High: Leverage the official Android client for hardware-isolated cryptographic key storage.

Crucial Trade-Off: Account Recovery & Password Responsibility

Absolute privacy requires user responsibility. Because SkiveCore maintains no backdoor to your private keys, there is an unavoidable architectural reality:

If you lose your password and perform an account reset, your previous private key is permanently lost.

  • Your private key on our servers is locked with a key derived from your original password. If you reset your password without your old credentials, your existing encrypted private key cannot be decrypted.
  • Past encrypted message history will become permanently unreadable.
  • A fresh set of cryptographic keys will be generated for all messages sent and received *after* the reset.

Recommendation: Always use a strong, unique password and store it safely in a reputable password manager.

What Isn't End-to-End Encrypted?

End-to-End Encryption is specifically designed for confidential, bilateral communications. Features that are inherently intended for community discovery and public consumption are not end-to-end encrypted:

  • Public forum posts and feeds
  • Comments and replies on public posts
  • Blog articles and blog discussions
  • Public video comments
  • User profile information (display names, bios, public avatars)
  • Public community channels

All public features are transmitted securely using Transport Layer Security (TLS/HTTPS), but they do not use client-side end-to-end encryption because their purpose is to be indexed and displayed publicly across the community.

Questions About Our Security?

Have a question about our cryptographic implementations, or interested in reporting a vulnerability? We welcome scrutiny from security researchers and privacy advocates.

Contact Security & Privacy Team