Security Protocols

Last Updated: May 12, 2025

Security Overview

Zixt Secure Messaging is built from the ground up with a focus on providing cutting-edge security, including resistance to quantum computing attacks. Our security architecture addresses both current and emerging threats through multiple layers of protection:

Post-Quantum Cryptography

Encryption and signature algorithms resistant to quantum computing attacks.

Blockchain Verification

Tamper-proof message integrity and authenticity verification.

Distributed Architecture

Resilient networking with no single point of failure.

Multi-Factor Authentication

Multiple verification layers for account access.

Secure Key Management

Password-protected key storage with additional encryption.

Forward Secrecy

Protection of past communications if keys are compromised.

Post-Quantum Cryptography

Quantum computers pose a significant threat to traditional cryptographic algorithms. Particularly vulnerable are public-key algorithms based on integer factorization (like RSA) and discrete logarithm problems (like ECC), which could be efficiently broken by Shor's algorithm running on a sufficiently powerful quantum computer.

To counter this threat, Zixt implements NIST-approved post-quantum cryptographic algorithms:

ML-KEM-1024 (Kyber-1024)

Key Encapsulation Mechanism

ML-KEM-1024 is a lattice-based key encapsulation mechanism that provides NIST Level 5 security, which is believed to be resistant against attacks from quantum computers.

Technical Specifications:

  • Public key size: 1568 bytes
  • Secret key size: 3168 bytes
  • Ciphertext size: 1568 bytes
  • Shared secret size: 32 bytes
  • Security: Equivalent to AES-256

How We Use It:

ML-KEM-1024 is used for asymmetric encryption, specifically to securely exchange session keys between users. Each user has a ML-KEM-1024 key pair. When establishing a secure communication channel, we use ML-KEM to encapsulate a shared secret that is then used for symmetric encryption of messages.

ML-DSA-65 (Dilithium5)

Digital Signature Algorithm

ML-DSA-65 is a lattice-based digital signature scheme that provides NIST Level 5 security against quantum attacks, ensuring that messages cannot be forged.

Technical Specifications:

  • Public key size: 1952 bytes
  • Secret key size: 4032 bytes
  • Signature size: ~3300 bytes
  • Security: Equivalent to SHA-384

How We Use It:

ML-DSA-65 is used to digitally sign messages, thread creations, and blockchain transactions. This guarantees the authenticity of the sender and ensures that messages have not been tampered with in transit. Every user in the system has a ML-DSA-65 key pair that is used to sign their communications.

Why Post-Quantum? While large-scale quantum computers capable of breaking traditional cryptography don't exist yet, the threat is real. "Harvest now, decrypt later" attacks mean that encrypted data captured today could be decrypted in the future when quantum computers become available. Our post-quantum approach protects you from this long-term threat.

Symmetric Encryption

In addition to post-quantum asymmetric cryptography, Zixt employs strong symmetric encryption for message content:

AES-256-GCM

Authenticated Encryption with Associated Data (AEAD)

AES-256-GCM provides both encryption and authentication, ensuring message confidentiality and integrity.

Technical Specifications:

  • Key size: 256 bits
  • Nonce/IV size: 96 bits (12 bytes)
  • Authentication tag: 128 bits (16 bytes)
  • Mode: Galois/Counter Mode (GCM)

How We Use It:

We use AES-256-GCM for:

  • Encrypting message content using unique session keys
  • Protecting private keys stored on the server
  • Securing sensitive configuration information

Each encryption operation uses a unique nonce (number used once) to prevent replay attacks and ensure that the same plaintext encrypts to different ciphertexts.

Secure Key Management

Secure key management is critical to the overall security of the system. Zixt implements the following key management protocols:

Private Key Protection

User private keys are never stored in plaintext. Instead:

  1. Each user's private key is encrypted with AES-256-GCM using a key derived from their password using Argon2id with high work factors.
  2. The encrypted private key is stored in the database and only decrypted locally when needed for operations.
  3. Private keys are never transmitted across the network in plaintext form.

Session Key Management

For each message thread, we implement the following:

  1. A unique session key is generated for each thread using a cryptographically secure random number generator.
  2. The session key is encrypted for each thread participant using ML-KEM-1024 with their public key.
  3. Only participants who were members of the thread at the time of key generation can decrypt messages encrypted with that session key.
  4. When a new member joins a thread, a new session key is generated, ensuring forward secrecy.

Key Rotation Policies

To minimize the risk of key compromise, Zixt implements the following key rotation policies:

  • Session keys are automatically rotated when thread membership changes or at regular intervals.
  • Users can manually trigger regeneration of their encryption key pairs.
  • Rotating keys ensures that a compromised key has a limited window of vulnerability.

Blockchain Message Verification

Zixt uses a private blockchain to verify message integrity and authenticity, providing additional security beyond encryption:

How It Works

  1. Message Hashing: Each message is hashed using SHA-384.
  2. Digital Signature: The hash is signed using the sender's ML-DSA-65 private key.
  3. Blockchain Transaction: The message hash, signature, and metadata are recorded as a transaction in the blockchain.
  4. Block Creation: Transactions are grouped into blocks that include a reference to the previous block, creating a chain.
  5. Consensus: Distributed network nodes validate blocks using a Proof-of-Stake mechanism.
  6. Verification: Recipients can verify message authenticity by checking the blockchain record.

Security Benefits

  • Tamper Detection: Any modification to a message will be detected because the hash in the blockchain won't match.
  • Non-Repudiation: Senders cannot deny sending a message that has been signed with their private key and recorded in the blockchain.
  • Historical Verification: Message integrity can be verified even long after sending.
  • Distributed Validation: Multiple nodes validate and store blockchain data, preventing centralized points of failure.

Privacy Considerations

While message hashes are recorded in the blockchain, the actual message content remains encrypted:

  • Only message hashes and signatures are recorded in the blockchain, not the actual message content.
  • The blockchain entries do not allow others to determine the content of messages.
  • Message content remains protected by end-to-end encryption.

Distributed Hash Table (DHT) Network

Zixt uses a Distributed Hash Table architecture for resilient networking and federated deployment, enhancing security through distribution:

DHT Architecture

The DHT implementation in Zixt provides:

  • Decentralization: No single point of failure for network operations.
  • Peer Discovery: Nodes can locate each other without central coordination.
  • Data Distribution: Information is distributed across multiple nodes for redundancy.
  • Scalability: The network can grow to include thousands of nodes.

Security Features of DHT

  • Node Authentication: Nodes authenticate each other using ML-DSA-65 signatures.
  • Secure Routing: Communication between nodes is encrypted using ML-KEM-1024.
  • Data Integrity: Stored data includes integrity verification to detect tampering.
  • Redundancy: Critical data is replicated across multiple nodes to prevent loss.
  • Eclipse Attack Prevention: Mechanisms to prevent malicious nodes from isolating targets.

Federation Security

For federated deployments across multiple servers:

  • Cross-Server Verification: Servers verify each other's authenticity before federation.
  • Encrypted Inter-Server Communication: All data shared between federated servers is encrypted.
  • Limited Data Sharing: Only necessary data is shared between servers, with user privacy controls.
  • Conflict Resolution: Secure mechanisms for resolving data conflicts between servers.

Multi-Factor Authentication

In addition to password authentication, Zixt provides multiple additional authentication factors to protect user accounts:

Time-Based One-Time Password (TOTP)

Our primary MFA method uses TOTP, compatible with applications like Google Authenticator, Authy, and Microsoft Authenticator:

  • Based on RFC 6238 TOTP standard
  • Uses a secure random secret key unique to each user
  • Generates 6-digit codes that change every 30 seconds
  • Provides protection even if a password is compromised

Pre-Shared Key (PSK) Authentication

For high-security environments, users can enable PSK authentication:

  • Requires a separate long-term password in addition to the regular account password
  • PSK is needed for critical account operations
  • Provides an additional layer of security beyond TOTP

Account Recovery Options

Secure recovery methods are available if authentication factors are lost:

  • Email-based verification with secure time-limited tokens
  • Recovery codes generated during MFA setup
  • Administrator-assisted recovery for organizational deployments

Note: Due to our encryption model, message content from before a key reset may become inaccessible if encryption keys are lost.

Additional Security Measures

Password Security

  • Argon2id Hashing: Passwords are hashed using Argon2id with high memory and time costs to resist brute-force attacks.
  • Minimum Complexity: Passwords must meet minimum complexity requirements.
  • Breach Detection: New passwords are checked against known breach databases.

Network Security

  • TLS Encryption: All HTTP traffic is protected with TLS 1.3.
  • HSTS: HTTP Strict Transport Security prevents downgrade attacks.
  • Rate Limiting: Protects against brute force and DoS attacks.
  • IP Filtering: Optional IP-based access restrictions for increased security.

Security Monitoring

  • Intrusion Detection: Continuous monitoring for suspicious activity.
  • Audit Logging: Comprehensive logging of security-relevant events.
  • Automated Alerts: Real-time notification of potential security issues.
  • Regular Audits: Scheduled security reviews and penetration testing.

Security Best Practices for Users

While Zixt implements strong security measures at the platform level, users should follow these best practices:

Use Strong, Unique Passwords

Create a strong, unique password for your Zixt account that you don't use anywhere else. Consider using a password manager to generate and store complex passwords.

Enable Multi-Factor Authentication

Always enable MFA on your account for an additional layer of security. This prevents unauthorized access even if your password is compromised.

Secure Your Devices

Keep your devices and browsers updated with the latest security patches. Use device encryption and screen locks to protect your local data.

Log Out When Not in Use

Always log out from your Zixt account when using shared or public computers. Set up automatic session timeouts for your account.

Security Reporting

We take security seriously and encourage responsible disclosure of potential vulnerabilities:

Reporting Security Issues

If you discover a potential security issue in Zixt, please report it to us immediately at security@zixt.app.

For sensitive reports, you can use our PGP key available at https://zixt.app/security/pgp-key.asc.

We commit to:

  • Acknowledging receipt of your report within 24 hours
  • Providing regular updates about the progress of addressing the issue
  • Notifying you when the issue is resolved
  • Crediting security researchers who responsibly disclose vulnerabilities, if desired