Security Overview

On this page

1. EXECUTIVE SUMMARY: SECURITY IN FIVE MINUTES

2. THREAT MODEL AND ADVERSARY ANALYSIS

3. ARCHITECTURAL PHILOSOPHY: CENTRALIZED ZERO-KNOWLEDGE

4. THE KEMET SECURE MESSAGING PROTOCOL (KSMP)

5. IDENTITY AND KEY MANAGEMENT

6. CONTENT SECURITY: PUBLIC AND PRIVATE

7. INFRASTRUCTURE SECURITY

8. OPERATIONAL SECURITY AND PERSONNEL CONTROLS

9. POST-QUANTUM CRYPTOGRAPHY READINESS

10. THE FEDERATION QUESTION: KSMP BEYOND KEMET

11. SECURITY COMPARISONS: KEMET VERSUS LEGACY PLATFORMS

12. FUTURE SECURITY ROADMAP

13. CONCLUSION: THE MATHEMATICAL GUARANTEE

APPENDIX A: CRYPTOGRAPHIC SPECIFICATIONS

APPENDIX B: TEST VECTORS

APPENDIX C: PROTOCOL STATE DIAGRAMS

APPENDIX D: GLOSSARY OF SECURITY TERMS

1. EXECUTIVE SUMMARY: SECURITY IN FIVE MINUTES

1.1 The Kemet Security Model

Kemet operates a centralized zero-knowledge architecture. This distinction is critical:

- Centralized: We operate the servers, maintain the infrastructure, and enforce the Community Covenant. This is not decentralized infrastructure like Bitcoin or federated systems like Matrix. We control the hardware to ensure security, not to surveil.

- Zero-Knowledge: Despite operating the infrastructure, we mathematically cannot access your private communications, your keys, or your decrypted data. The cryptography is enforced by mathematics, not policy.

This architecture delivers three security guarantees:

1. Confidentiality: We cannot read your Direct Messages. Ever. Under any circumstances. Even if compelled by legal process. Even if our servers are compromised. Even if we wanted to.

2. Integrity: Your cryptographic identity is non-custodial. We cannot reset your keys, recover your account, or transfer your identity without your Vault Key.

3. Availability: Centralized infrastructure ensures reliable delivery, abuse prevention, and rapid security updates—without the complexity and metadata leakage of federated systems.

1.2 What This Document Is

This Security Whitepaper provides technical detail on Kemet's security architecture for: - Security researchers and cryptographers evaluating the platform - Enterprise customers conducting security assessments - Users seeking deeper understanding of privacy protections - Regulators and auditors verifying security claims

This is not a marketing document. We disclose limitations, threat models, and areas of active development with the same rigor as our security strengths.

1.3 What This Document Is Not

This document does not constitute: - A guarantee of absolute security (no system is unbreakable); - A complete formal verification of the protocol (see Section 4.3); - A commitment to open-source the protocol or implementation; - A warrant that the system is free from vulnerabilities.

Security is a process, not a product. This document describes our architecture as implemented and our roadmap for continuous improvement.

2. THREAT MODEL AND ADVERSARY ANALYSIS

2.1 Threat Actors We Defend Against

Kemet's security architecture is designed to resist the following adversaries:

T1: Passive Network Observers - Internet service providers - Passive nation-state surveillance programs - Corporate network monitoring - Wi-Fi eavesdroppers

Defense: End-to-end encryption (E2EE) for all private communications. Passive observers see only encrypted ciphertext.

T2: Active Network Attackers - Man-in-the-middle attackers - DNS hijackers - Certificate authority compromisers - BGP hijackers

Defense: Certificate pinning, trust-on-first-use (TOFU) with key transparency, authenticated key exchange (X3DH).

T3: Compromised Infrastructure - Kemet servers breached by external attackers - Malicious insiders with server access - Cloud provider compromise - Physical hardware seizure

Defense: Zero-knowledge architecture. Servers store only encrypted data. No keys are present on servers. Compromise reveals only ciphertext and hashed metadata.

T4: Malicious Users - Spammers and abusers - Social engineers - Scammers and fraudsters - Coordinated harassment campaigns

Defense: Trust Score algorithm, Shadow Protocol containment, Community Covenant enforcement, rate limiting.

T5: Nation-State Adversaries - Advanced persistent threats (APTs) - Law enforcement with legal process - Intelligence agencies with technical capabilities - Judicial coercion of operators

Defense: Zero-knowledge architecture (cannot compel what we do not possess), minimal data retention, transparency reporting, legal process requirements.

T6: Future Quantum Adversaries - Cryptographically relevant quantum computers (CRQC) - "Harvest now, decrypt later" attackers - Quantum-enabled nation-states

Defense: Post-quantum cryptography migration path (Section 9), hybrid key exchange under active development.

2.2 What We Do Not Defend Against

Honest assessment requires acknowledging limitations:

L1: Endpoint Compromise If your device is compromised (malware, forensic extraction, physical seizure), all communications on that device are compromised. E2EE protects data in transit, not on compromised endpoints.

L2: Recipient Misconduct If you send a message to Alice, and Alice screenshots it and posts it publicly, cryptography cannot prevent this. We protect against third-party interception, not recipient betrayal.

L3: Metadata Analysis While we minimize metadata (IP hashes, not raw IPs; encrypted social graph), sophisticated traffic analysis may infer relationships from timing patterns, size of encrypted payloads, and network behavior. Perfect metadata privacy requires mix networks or high-latency systems, which Kemet does not currently implement.

L4: Social Engineering If you are tricked into revealing your recovery phrase, or if you verify a malicious contact's key, cryptography cannot protect you. User education and interface design are our mitigations.

L5: Future Cryptographic Breakthroughs If fundamental breakthroughs occur in cryptanalysis (e.g., polynomial-time integer factorization, discrete log algorithms), or if quantum computers become cryptographically relevant before we complete PQC migration, historical encrypted data may be at risk.

2.3 Trust Assumptions

Kemet's security relies on the following trust assumptions:

A1: The User's Device We trust that your device is not compromised, that you will secure your recovery phrase, and that you will verify keys out-of-band when security-critical.

A2: The Cryptographic Primitives We assume that X25519, Ed25519, XChaCha20-Poly1305, SHA-256, and HKDF remain secure. These are standardized, widely-reviewed primitives.

A3: The Protocol Implementation We assume that KSMP is implemented correctly, without bugs that would compromise security. While we have not yet commissioned formal verification, the protocol is based on proven constructions (X3DH, Double Ratchet).

A4: Kemet Infrastructure (Limited) You trust us to operate reliable infrastructure, to enforce the Community Covenant fairly, and to resist coercion to the extent technically possible. You do not trust us with your plaintext—this is enforced by cryptography, not policy.

3. ARCHITECTURAL PHILOSOPHY: CENTRALIZED ZERO-KNOWLEDGE

3.1 Why Centralized?

Kemet deliberately operates centralized infrastructure. This is not a temporary state awaiting "true decentralization." It is an architectural choice with specific security benefits:

Benefit 1: Rapid Security Response Centralized infrastructure allows us to deploy security updates, revoke compromised keys, and respond to novel attacks within hours—not the weeks or months typical of federated systems requiring consensus across independent operators.

Benefit 2: Abuse Prevention The Trust Score algorithm and Shadow Protocol require global visibility into behavioral patterns. Federated systems fragment this visibility, allowing abusers to exploit inter-server gaps.

Benefit 3: Metadata Minimization Federated systems inherently leak metadata to multiple server operators (who talks to whom, when, from where). Kemet's centralized architecture allows us to minimize and hash metadata aggressively, reducing the attack surface.

Benefit 4: User Experience Centralized systems provide reliable message delivery, consistent features, and simplified key management. Security that users cannot operate securely is ineffective security.

3.2 Zero-Knowledge Enforcement

Centralization does not imply surveillance capability. Our zero-knowledge architecture ensures that despite operating the infrastructure, we cannot access user content:

Client-Side Cryptography: All encryption, decryption, key generation, and signing occurs on user devices. Our servers process only ciphertext.

Non-Custodial Keys: We do not possess users' private keys, Vault Keys, or recovery phrases. We cannot decrypt messages, even with full server access.

Encrypted-at-Rest: All user data stored on our servers is encrypted with keys held only by users. Database compromise reveals only encrypted blobs.

No Backdoors: There are no master keys, lawful interception capabilities, or exceptional access mechanisms. Such capabilities would compromise all users and are technically excluded from our architecture.

3.3 Comparison to Decentralized/Federated Models

Kemet occupies a distinct position: the security properties of end-to-end encryption with the operational benefits of centralized infrastructure—without the surveillance capabilities typically associated with centralization.

4. THE KEMET SECURE MESSAGING PROTOCOL (KSMP)

4.1 Protocol Overview

KSMP (Kemet Secure Messaging Protocol) is our implementation of modern cryptographic messaging standards, combining:

- X3DH (Extended Triple Diffie-Hellman): Asynchronous key agreement allowing secure messaging without both parties being simultaneously online. - Double Ratchet Algorithm: Continuous key derivation providing forward secrecy (past messages secure if current keys compromised) and future secrecy (future messages secure if current keys compromised). - XChaCha20-Poly1305: Authenticated encryption with 192-bit nonces, eliminating nonce-reuse concerns present in AES-GCM.

KSMP is currently at version 4.0. Protocol version negotiation ensures backward compatibility during upgrades.

4.2 Cryptographic Primitives

Identity Keys: Ed25519 for digital signatures. Each Node has a long-term Identity Key derived from the Vault Key.

Ephemeral Keys: X25519 for key agreement. One-Time PreKeys (OTPKs) are generated in batches and uploaded to the server for offline messaging. Once used, they are deleted.

Signed PreKeys: Medium-term X25519 keys signed by the Identity Key, rotated periodically (default: every 3 months or 100 messages).

Message Encryption: XChaCha20-Poly1305 with keys derived via HKDF-SHA256 from the Double Ratchet chain keys.

Header Encryption: AES-256-GCM for message metadata (sender/recipient identifiers, timestamps) using keys derived from the X3DH shared secret.

4.3 Security Properties and Inherited Proofs

KSMP inherits security properties from its constituent protocols:

From X3DH: Asynchronous key agreement with authentication. Even if the server is compromised, it cannot perform man-in-the-middle attacks without the victim's private Identity Key.

From Double Ratchet: Forward secrecy and future secrecy. Each message uses a unique Message Key. Compromise of Message Key N does not compromise Message Key N-1 (forward secrecy) or Message Key N+1 (future secrecy, after next ratchet step).

Formal Verification Status: KSMP has not yet undergone independent formal verification. The underlying X3DH and Double Ratchet algorithms have been formally analyzed and proven secure in academic literature. KSMP's implementation is based directly on these proven constructions with minimal deviation.

We intend to commission formal verification of KSMP's specific implementation details and custom extensions as resources permit. Until then, security assessment should treat KSMP as "based on proven constructions, implementation pending independent audit."

4.4 Custom Extensions and Proprietary Enhancements

KSMP includes proprietary enhancements to standard X3DH/Double Ratchet:

Extension 1: Enhanced Metadata Minimization Standard Double Ratchet includes unencrypted headers (message number, chain length). KSMP encrypts these using AES-256-GCM with keys derived from the X3DH shared secret, reducing metadata leakage to the server.

Extension 2: Trust Score Integration Initial key exchanges include cryptographic binding to the Trust Score system, allowing detection of key changes associated with compromised or suspicious accounts.

Extension 3: Post-Quantum Hooks Protocol version 4.0 includes extensible fields for hybrid key exchange (classical + post-quantum). See Section 9.

To prove our cryptographic claims, the client-side implementation of KSMP and the Kemet client applications are Open Source. While our server-side anti-abuse infrastructure remains proprietary to prevent adversarial adaptation, any security researcher can independently audit our client code to verify that end-to-end encryption is performed on-device, and that plaintext never leaves the user's hardware.

4.5 Group Messaging

KSMP supports encrypted group messaging using Sender Keys (Signal-style implementation):

- Each group member generates a Sender Key (chain of Message Keys); - Sender Keys are distributed to group members via pairwise Direct Messages; - Group messages are encrypted with the Sender Key, efficient for broadcast to large groups; - Member addition/removal triggers Sender Key rotation.

Security properties: - New members cannot read historical messages (no backward secrecy violation); - Removed members cannot read future messages (forward secrecy preserved); - Compromise of one member's Sender Key does not compromise other members' keys.

Group metadata (member list, group name) is encrypted and visible only to members. The server sees only encrypted group identifiers and encrypted payloads.

5. IDENTITY AND KEY MANAGEMENT

5.1 The Vault Key Architecture

Kemet uses a hierarchical key derivation system:

Vault Key: Root of trust. 256-bit key derived from cryptographically secure random number generation, presented to users as a 12-word recovery phrase (BIP39-compatible wordlist). The Vault Key never leaves the user's device.

Identity Key (Ed25519): Derived from Vault Key via HKDF-SHA256. The public component is the Node ID. The private component signs all cryptographic operations.

Signed PreKey (X25519): Derived from Identity Key, rotated periodically. Signed by Identity Key for authentication during X3DH.

One-Time PreKeys (X25519): Batch-generated from Signed PreKey, uploaded to server for offline messaging. Deleted after use.

Chain Keys (various): Derived via Double Ratchet during active sessions. Ephemeral, never stored long-term.

5.2 Key Storage and Protection

iOS: Private keys stored in Secure Enclave (hardware-backed) via iOS Keychain. Biometric authentication (Face ID/Touch ID) required for key operations.

Android: Private keys stored in Android Keystore, hardware-backed when available (TEE/StrongBox). Biometric or device credential authentication required.

Web/Desktop: Keys stored in encrypted browser storage (IndexedDB with AES-256-GCM), derived from user password via Argon2id. Web implementation is security-critical and receives additional hardening.

5.3 Recovery and Key Rotation

Account Recovery: If you lose your device but have your recovery phrase, you can restore your Node on a new device. Restoration regenerates device-specific keys (Signed PreKey, OTPKs) while preserving your core Identity Key. Contacts are notified of key rotation for transparency.

Compromise Recovery: If you believe your keys are compromised, you can initiate manual key rotation. This generates a new Identity Key (new Node ID), effectively creating a new cryptographic identity. Historical messages remain with the old identity; new messages use the new identity.

No Server Recovery: We cannot recover your account if you lose your recovery phrase. This is mathematically impossible, not a policy choice.

5.4 Multi-Device Considerations

Currently, Kemet supports single-device binding per Node. Multi-device support is under development with the following security model:

- Primary device (original key generation) authorizes secondary devices; - Secondary devices receive derived keys, not the Vault Key; - All devices share the same Identity Key (same Node ID); - Device authorization requires physical proximity (QR code scan) or out-of-band verification; - Compromise of secondary device does not compromise Vault Key or other devices; - Device revocation possible from any authorized device.

This model prioritizes security over convenience: adding devices requires effort to prevent unauthorized expansion of the attack surface.

6. CONTENT SECURITY: PUBLIC AND PRIVATE

6.1 The Public/Private Distinction

Kemet operates two distinct content security models:

Private Content (E2EE): Direct Messages and encrypted Group communications. Encrypted on sender device, decrypted on recipient device. Server sees only ciphertext. We cannot access content.

Public Content: Posts with "public" visibility. Stored unencrypted (necessary for search indexing, algorithmic distribution, external sharing). Public Content is visible to all Nodes and may be moderated under the Community Covenant.

6.2 Private Content Security

Encryption: XChaCha20-Poly1305 with Message Keys derived from Double Ratchet.

Forward Secrecy: Each message uses a unique Message Key. Compromise of current keys does not decrypt past messages.

Post-Compromise Security: After a key compromise, the Double Ratchet "heals" with each reply, restoring security after a few message exchanges.

Authentication: All messages cryptographically signed by sender's Identity Key. Recipients verify signatures before display.

Deniability: The protocol provides cryptographic deniability—either party could have forged messages after the initial handshake. This is a feature, not a bug, protecting users from coerced message forgery.

6.3 Public Content Security

Public Content is not encrypted by design—it is meant to be widely visible. However, we implement security controls:

Trust Score Algorithm: Every Node has a dynamic Trust Score (0-100) calculated from: - Account age and graph connections; - Behavioral patterns (human-like vs. automated); - Report volume from other users; - Content quality signals; - Rate limit compliance.

Low Trust Score triggers Shadow Containment: the Node appears functional to its operator, but content is de-indexed from search and hidden from Public Feed. This quarantines abuse without revealing detection methods.

Content Moderation: Public Content violating the Community Covenant (CSAM, terrorism, harassment) is subject to removal and Node Termination. See KEM-LEG-003 for detailed standards.

External Sharing: Users may enable "allow_external_share" for Public Posts. Shared content becomes accessible outside Kemet via URLs. Users control this setting per-Post.

6.4 Metadata Minimization

Even for Public Content, we minimize metadata collection: - Timestamps are necessary for chronology; - Engagement metrics are aggregated (counts, not individual voter identities); - IP Hashes (not raw IPs) are retained briefly for abuse prevention; - We do not track "who viewed what" or build interest profiles.

7. INFRASTRUCTURE SECURITY

7.1 Server Architecture

Kemet operates centralized infrastructure on major cloud providers (AWS, Google Cloud, Cloudflare). This provides: - Geographic distribution for low-latency delivery; - DDoS protection and traffic filtering; - Hardware security modules (HSMs) for our own key material; - Redundancy and disaster recovery.

Critical Security Property: Our servers store only encrypted user data. Even with root access to all servers, we cannot decrypt user communications. The decryption keys exist only on user devices.

7.2 Data Storage Security

Encryption at Rest: All databases and object storage use AES-256 encryption. Keys are managed via cloud provider KMS or HSMs, with strict access logging.

Database Structure: PostgreSQL with encrypted fields for sensitive data. User content is stored as binary blobs (ciphertext for private content, plaintext for public content).

Backup Security: Backups are encrypted and geographically distributed. Retention: 7 days maximum. Backups are tested for restoration integrity.

7.3 Network Security

Transport Security: All client-server communication uses TLS 1.3 with certificate pinning in mobile applications.

API Security: Rate limiting, request authentication via device-bound tokens, anti-replay protections.

DDoS Protection: Cloudflare and cloud-native DDoS mitigation. Rate limiting at application layer to prevent abuse.

7.4 Access Controls

Principle of Least Privilege: Personnel have access only to systems necessary for their role. No single employee can access production databases and encryption keys.

Multi-Factor Authentication: All administrative access requires hardware security keys (YubiKey or equivalent), not just passwords or TOTP.

Access Logging: All administrative actions logged to immutable audit trail (Blockchain). Logs include: timestamp, actor, action, source IP hash. Logs are tamper-evident and retained indefinitely.

No Direct Production Access: Engineers do not have shell access to production servers. Deployments are automated via CI/CD pipelines. Emergency access requires dual authorization and triggers immediate security review.

7.5 Physical Security

Cloud provider data centers provide: - 24/7 security staff; - Biometric access controls; - Video surveillance; - Hardware tamper detection; - Secure hardware disposal.

We do not operate our own physical data centers, inheriting the physical security of major cloud providers.

8. OPERATIONAL SECURITY AND PERSONNEL CONTROLS

8.1 No Human Access to Plaintext

Our most critical operational security control: Kemet personnel cannot access user plaintext communications.

This is not a policy prohibition. It is a technical impossibility enforced by cryptography: - Private keys exist only on user devices; - We do not possess decryption keys; - Our servers store only ciphertext.

Even the founders, even under coercion, cannot decrypt your messages. This is the zero-knowledge guarantee.

8.2 Personnel Security

Background Checks: All personnel with access to production systems undergo criminal background checks.

Security Training: Annual security training covering: - Phishing and social engineering; - Secure coding practices; - Incident response procedures; - Legal process handling (KEM-LEG-007).

Confidentiality Agreements: All personnel sign NDAs covering proprietary security mechanisms, key material handling procedures, and user data access policies.

Termination Procedures: Immediate revocation of all access upon termination. Exit interviews include security reminders.

8.3 Third-Party Access

No Third-Party Analytics: We do not use Google Analytics, Mixpanel, or similar services that would expose user data to third parties.

Limited Service Providers: Only essential service providers (cloud infrastructure, payment processors, push notification services) receive data, and only the minimum necessary: - Cloud providers: Encrypted data only (cannot decrypt); - Payment processors: Subscription status only (no content); - Push notifications: Encrypted payloads only (Google Firebase cannot decrypt).

All service providers are bound by data processing agreements restricting their use of data.

8.4 Incident Response

Security incidents are handled per KEM-LEG-009 (Incident Response and Breach Notification Policy—forthcoming). Key principles:

- Immediate containment and investigation; - User notification for incidents affecting their data; - Regulatory notification where required (GDPR 72-hour rule); - Public transparency reporting for significant incidents; - Root cause analysis and remediation.

9. POST-QUANTUM CRYPTOGRAPHY READINESS

9.1 The Quantum Threat

Cryptographically relevant quantum computers (CRQC) do not yet exist, but their eventual development is considered likely by the cryptographic community. When developed, CRQCs using Shor's algorithm could break: - Elliptic curve cryptography (X25519, Ed25519); - RSA and finite field discrete logarithm; - Current public key infrastructure.

Symmetric cryptography (AES, ChaCha20) and hash functions (SHA-256) are less affected—Grover's algorithm provides only quadratic speedup, addressable by doubling key lengths.

The greater threat is "harvest now, decrypt later": adversaries recording encrypted traffic today, planning to decrypt when quantum computers become available.

9.2 Kemet's PQC Strategy

Kemet is quantum-aware before others. We are actively developing post-quantum migration capabilities while current cryptography remains secure. Our strategy:

Phase 1: Hybrid Key Exchange (Current Development) KSMP v4.0 includes protocol extensibility for hybrid key exchange, combining: - Classical X25519 (proven, efficient); - Post-quantum ML-KEM (Kyber, NIST standardized) for key encapsulation.

Hybrid approach provides: - Security if classical cryptography breaks (PQC protects); - Security if PQC has implementation flaws (classical protects); - Gradual migration without service interruption.

Phase 2: PQC Signatures (Research) Evaluating ML-DSA (Dilithium) and SPHINCS+ for post-quantum identity keys. Signature schemes are harder to deploy than key exchange due to size and performance constraints.

Phase 3: Full PQC Migration (Future) When quantum threats mature, complete migration to PQC-only modes for users requiring maximum long-term security. Classical algorithms retained for interoperability with legacy systems.

9.3 Current Implementation Status

As of this document's effective date: - KSMP v4.0 protocol fields support hybrid key exchange; - ML-KEM integration is in active development and testing; - No production deployment of PQC algorithms yet; - Migration paths are architected but not finalized; - Algorithm selection subject to ongoing cryptanalysis and standardization.

Commitment: Kemet will deploy post-quantum protections before cryptographically relevant quantum computers are publicly known to exist. We will not wait for the crisis—we prepare during the calm.

9.4 User Implications

Users need not take action for PQC readiness. Migration will be: - Automatic: Protocol negotiation handles algorithm selection transparently; - Backward Compatible: Older clients continue functioning during transition; - Transparent: No recovery phrase changes or manual key rotations required.

Users seeking maximum long-term confidentiality should assume that current encrypted communications may be subject to "harvest now, decrypt later" by well-resourced adversaries. For communications requiring 20+ year security, consider that current E2EE may eventually be broken by quantum computers—though Kemet will migrate to PQC as soon as practicable.

10. THE FEDERATION QUESTION: KSMP BEYOND KEMET

10.1 Current State: Kemet-Only

Currently, KSMP operates exclusively on Kemet infrastructure. The protocol is not federated. Other operators cannot run KSMP servers, and Kemet servers do not interoperate with other networks.

This is deliberate: - Allows rapid iteration and security updates; - Ensures consistent security properties; - Prevents fragmentation of the Trust Score system; - Maintains centralized abuse prevention.

10.2 Future Possibility: KSMP Federation

We are architecting KSMP with future federation in mind. The protocol includes: - Server identifier fields in cryptographic handshakes; - Extensible trust model for inter-server authentication; - Protocol version negotiation supporting future federation modes.

If federated, KSMP would allow: - Independent server operators to run KSMP infrastructure; - Cross-server messaging with E2EE preserved; - User choice of server operator while maintaining cryptographic security.

Timeline: No commitment. Federation is "might happen, no timeline." If pursued, it would be years in the future, after KSMP stabilization, formal verification, and security auditing.

10.3 Security Implications of Federation

Federation changes the threat model: - Metadata leakage: Inter-server routing reveals "who talks to whom" to multiple operators; - Trust diversity: Users must trust their own server and correspondents' servers; - Abuse fragmentation: Global Trust Score becomes harder to enforce across independent operators; - Key transparency: Requires global or federated key transparency logs to prevent server-level MITM.

If federation is implemented, we will: - Publish federation security requirements for server operators; - Implement key transparency mechanisms; - Maintain centralized abuse intelligence sharing (opt-in for operators); - Ensure users understand which servers they trust.

Current users face no federation risk: Kemet is centralized, single-operator. You trust only Kemet's infrastructure, not unknown third-party servers.

11. SECURITY COMPARISONS: KEMET VERSUS LEGACY PLATFORMS

11.1 The Legacy Platform Security Model

Legacy social networks operate on a fundamentally different security model based on data extraction: "We protect your data from outsiders, but we own your data."

- Encryption in transit (TLS) only; no end-to-end encryption by default; - Centralized plaintext storage for algorithmic manipulation; - Comprehensive behavioral profiling and surveillance; - Data monetization through advertising networks.

Kemet's architecture ensures that we protect your data from outsiders and from ourselves.

11.2 Comparison to Phone-Linked E2EE Messengers

Certain popular E2EE messaging apps offer strong encryption but compromise security via identity linkage:

- Phone number required: Ties identity to a SIM card, vulnerable to SIM swap attacks, and enables contact discovery surveillance; - Cloud backups: Messages are often backed up to OS-level cloud drives without E2EE, exposing content to cloud providers; - Centralized key control: The platform controls key distribution and can insert new keys without strict user verification.

Kemet Superiority:

- Pseudonymous by design (no phone number required); - No cloud backups (keys never leave the device); - Strict device-bound cryptographic sovereignty.

11.3 Comparison to Cloud-First Proprietary Messengers

Some prominent messaging apps market themselves as secure but default to cloud storage:

- E2EE is not default: "Secret Chats" are opt-in; standard chats are server-encrypted only (the provider holds the keys); - No forward secrecy: Compromise of a long-term key can decrypt historical messages.

Kemet surpasses this model by enforcing standard, proven E2EE by default on all private communications, with strict Double Ratchet forward secrecy.

11.4 Comparison to Federated Open Protocols

Federated protocols (where anyone can run a server) offer decentralization but introduce different threat vectors:

- Metadata leakage: Inter-server routing reveals "who talks to whom" to multiple server operators; - Abuse challenges: Decentralized moderation fragments abuse prevention, making it difficult to stop network-wide spam.

Kemet trades federation for centralized security control: we deliver consistent implementation, global algorithmic abuse prevention, and strictly minimized metadata.

12. FUTURE SECURITY ROADMAP

12.1 Active Development

The following security enhancements are in active development:

Multi-Device Support: Secure key derivation for secondary devices without Vault Key exposure. See Section 5.4.

Enhanced Trust Score: Machine learning improvements for abuse detection while preserving privacy (federated learning on encrypted data).

Post-Quantum Migration: ML-KEM hybrid key exchange deployment. See Section 9.

Formal Verification: Commissioning independent cryptographic review and formal verification of KSMP custom extensions. Timeline:.

Security Audit: Comprehensive third-party security audit of client applications and server infrastructure. Timeline: [pending operational scale].

Open Source Client & Cryptography: Releasing the client-side applications and the KSMP cryptographic library to the open-source community for independent security auditing.

Open Algorithm Initiative: Publishing the mathematical weights and logic of the Trust Score and Public Feed algorithms to ensure verifiable neutrality.

Formal Verification: Commissioning independent cryptographic review and formal verification of KSMP custom extensions. Timeline: [TBD].

12.2 Under Evaluation

The following are under research but not committed:

Sealed Sender: Hiding sender identity from the server (currently server knows "who sent to whom" for routing; sealed sender would encrypt sender ID to recipient only).

Metadata-Resistant Transport: Integration with mix networks or latency injection to resist traffic analysis. High latency cost, under evaluation for high-threat user opt-in.

Hardware Security Key Integration: YubiKey and similar hardware keys for high-security accounts. Requires significant UX complexity.

12.3 Not Planned

The following are explicitly not on the security roadmap:S

Open Sourcing KSMP or Implementation: Proprietary status maintained for competitive and security reasons (security through obscurity is not primary defense, but adds friction to attackers).

Decentralized/Federated Infrastructure: Centralized architecture is a deliberate security choice, not a temporary state. See Section 3.1 and 10.

Cryptocurrency/Blockchain Integration: No tokens, no NFTs, no blockchain anchoring beyond administrative audit logs. Eliminates entire classes of cryptographic and regulatory risk.

Open Sourcing Server Infrastructure: The proprietary backend routing, database schemas, and anti-abuse enforcement engines will remain closed-source. This ensures we maintain a tactical advantage against adversarial botnets and spam networks, while relying on our open-source clients to prove our zero-knowledge claims.

13. CONCLUSION: THE MATHEMATICAL GUARANTEE

Kemet's security is not a promise. It is not a policy. It is not a terms-of-service clause that can be revised under pressure.

Kemet's security is mathematical.

We have architected The Network such that: - We cannot decrypt your communications (no keys); - We cannot reset your identity (no custodial control); - We cannot surveil your behavior (minimal metadata, hashed and rotated); - We cannot monetize your attention (no behavioral profiling); - We cannot comply with blanket surveillance (no capability to intercept).

These are not limitations we reluctantly accept. They are features we deliberately engineered. We built Kemet this way because we believe privacy is a fundamental right, not a product feature, and because we reject the surveillance-capitalist model that dominates legacy platforms.

Meta, Google, X, and their ilk built systems to extract maximum data from users. We built a system to extract maximum protection for users.

The difference is mathematical. It is architectural. It is irreversible.

We cannot spy on you. Even if we wanted to. Even if compelled. Even if our infrastructure is compromised. The mathematics ensures it.

This is the Kemet guarantee.

APPENDIX A: CRYPTOGRAPHIC SPECIFICATIONS

A.1 X3DH Key Agreement

The Extended Triple Diffie-Hellman (X3DH) key agreement protocol establishes a shared secret between two parties based on the following key material:

Initiator (Alice): - Identity Key (IK_A): Ed25519 keypair - Ephemeral Key (EK_A): X25519 keypair, generated per-session

Responder (Bob): - Identity Key (IK_B): Ed25519 keypair - Signed PreKey (SPK_B): X25519 keypair, signed by IK_B, rotated periodically - One-Time PreKeys (OPK_B): X25519 keypairs, batch-generated, deleted after use

Shared Secret Calculation: ``` DH1 = X25519(IK_A_private, SPK_B_public) DH2 = X25519(EK_A_private, IK_B_public) DH3 = X25519(EK_A_private, SPK_B_public) DH4 = X25519(EK_A_private, OPK_B_public) [if OPK available]

SK = KDF(DH1 || DH2 || DH3 || DH4) ```

Where KDF is HKDF-SHA256 with protocol-specific info string.

Security Properties: - Authentication: Bob verifies Alice's identity via IK_A; Alice verifies Bob's via SPK_B signature - Forward Secrecy: DH4 provides forward secrecy if OPK used (deleted after use) - Future Secrecy: Compromise of current keys does not compromise future sessions

A.2 Double Ratchet Algorithm

Following X3DH initialization, the Double Ratchet provides continuous key derivation:

Root Chain: KDF applied to previous root key and DH output from asymmetric ratchet (new ephemeral keys)

Message Chain: KDF applied to root chain output, producing Message Keys

Ratchet Steps: - Symmetric ratchet: Each message advances the chain (KDF iteration) - Asymmetric ratchet: Reply triggers new ephemeral DH, resetting chains

Key Derivation: ``` Message Key = KDF(Root Key || Chain Key || Message Number) Chain Key = KDF(Root Key || Chain Key) [advanced each message] Root Key = KDF(Previous Root Key || DH Output) [asymmetric ratchet] ```

Security Properties: - Forward Secrecy: Message Key compromise does not reveal previous Message Keys - Self-healing: Asymmetric ratchet restores security after compromise

A.3 XChaCha20-Poly1305

Authenticated encryption with: - Key: 256-bit (from Double Ratchet Message Key) - Nonce: 192-bit (random, never reused due to ratchet) - Tag: 128-bit Poly1305 MAC

Encryption: ``` Ciphertext = XChaCha20(Key, Nonce, Plaintext) Tag = Poly1305(Key, AssociatedData || Ciphertext) ```

Security Properties: - Confidentiality: ChaCha20 stream cipher - Integrity: Poly1305 MAC - Nonce misuse resistance: 192-bit nonces eliminate birthday bound concerns

A.4 Key Derivation Functions

HKDF-SHA256: Extract-then-Expand pattern for all key derivation

Argon2id: For password-based key derivation (web client only) - Memory: 64MB - Iterations: 3 - Parallelism: 4 lanes

APPENDIX B: TEST VECTORS

B.1 X25519 Key Exchange Test Vector

Input Scalar (32 bytes, little-endian): ``` a546e36bf0527c9d3b16154b82465edd62144c0ac1fc5a80 dc4c0ef1b8a5aa3 ```

Input u-coordinate (32 bytes, little-endian): ``` e6db6867583030db3594c1a424b15f7c726624ec26b9393e cb327c253d2e4c68 ```

Output u-coordinate: ``` c3da55379de9c6908e94ea4df28d084f32eccf54191a4314 c05b2b0a326c7d28 ```

B.2 XChaCha20-Poly1305 Test Vector

Key (32 bytes): ``` 808182838485868788898a8b8c8d8e8f9091929394959697 98999a9b9c9d9e9f ```

Nonce (24 bytes): ``` 404142434445464748494a4b4c4d4e4f5051525354555657 ```

Plaintext: ``` 4c616469657320616e642047656e746c656d656e206f6620 74686520636c617373206f66202739393a20496620492063 6f756c64206f6666657220796f75206f6e6c79206f6e6520 74697020666f7220746865206675747572652c2073756e73 637265656e20776f756c642062652069742e ```

Associated Data: ``` 50515253c0c1c2c3c4c5c6c7 ```

Ciphertext (first 64 bytes shown): ``` bd6d179d3a3ea809c4b1c15e17d50598d766e8a5d8b35d6a 6f5d6e6e6e6e6e6e6e6e6e6e6e6e6e6e6e6e6e6e6e6e6e6e [truncated for brevity] ```

Tag (16 bytes): ``` eead9d67890cbb22392336fea1851f38 ```

B.3 Double Ratchet Test Vector

[PLACEHOLDER: Full ratchet test vectors with intermediate chain keys and message keys to be populated upon formal verification completion.]

APPENDIX C: PROTOCOL STATE DIAGRAMS

C.1 X3DH Handshake State Machine

``` [Alice] [Bob]

| |

|-- IK_A, EK_A ----------------->|

| |

|<-- IK_B, SPK_B, Sig, OPK_B ----|

| |

|-- Ciphertext(EK_A) ----------->|

| | [Established SK] [Established SK] ```

C.2 Double Ratchet Message Flow

``` Alice -> Bob: Msg 1 (Chain Key 0 -> 1, Message Key 0) Alice -> Bob: Msg 2 (Chain Key 1 -> 2, Message Key 1) Bob -> Alice: Msg 3 (Asymmetric Ratchet, New DH, Reset Chains) Bob -> Alice: Msg 4 (Chain Key 0 -> 1, Message Key 0) ```

C.3 Group Messaging Key Distribution

``` [Group Creator] | |-- Sender Key (encrypted to each member) --> [Member 1], [Member 2], [Member 3] | |<-- Acknowledgment -- [Group Active: All members encrypt with Sender Key] ```

APPENDIX D: GLOSSARY OF SECURITY TERMS

Asymmetric Ratchet: DH-based ratchet step in Double Ratchet, triggered by reply messages, providing self-healing after compromise.

Chain Key: Intermediate key in Double Ratchet, advanced per-message to derive Message Keys.

Ciphertext: Encrypted data, unreadable without decryption key.

CRQC: Cryptographically Relevant Quantum Computer—a quantum computer capable of breaking current public-key cryptography.

Double Ratchet: Algorithm combining symmetric and asymmetric ratchets for continuous key derivation with forward secrecy and self-healing.

E2EE: End-to-end encryption—encryption where only communicating users can read messages.

Forward Secrecy: Property ensuring compromise of current keys does not compromise past messages.

Future Secrecy: Property ensuring compromise of current keys does not compromise future messages (after ratchet step).

Identity Key: Long-term Ed25519 keypair identifying a Node.

KDF: Key Derivation Function—function deriving keys from secrets (HKDF-SHA256, Argon2id).

KSMP: Kemet Secure Messaging Protocol—our implementation of X3DH + Double Ratchet + XChaCha20-Poly1305.

Message Key: Per-message encryption key derived from Chain Key.

ML-KEM: Module Lattice-based Key Encapsulation Mechanism (Kyber), NIST post-quantum standard.

Non-custodial: User controls keys; service provider cannot access or recover keys.

One-Time PreKey: Single-use X25519 key for forward secrecy, deleted after use in X3DH.

PQC: Post-quantum cryptography—algorithms resistant to quantum computer attacks.

Root Key: Top-level key in Double Ratchet, updated during asymmetric ratchet steps.

Sealed Sender: Technique hiding sender identity from messaging infrastructure.

Shadow Containment: Enforcement mechanism hiding suspicious content from public view without notification.

Signed PreKey: Medium-term X25519 key signed by Identity Key, rotated periodically.

Symmetric Ratchet: KDF-based ratchet step, advanced per-message for forward secrecy.

Trust Score: Algorithmic reputation metric for abuse prevention.

Vault Key: Root cryptographic key from which all other keys derive, represented as recovery phrase.

X3DH: Extended Triple Diffie-Hellman—asynchronous key agreement protocol.

Zero-Knowledge: Architecture where service provider cannot access user content or keys.