M Minyma
Features Preview Privacy Technical Help
Get Minyma

White Paper

Minyma End-to-End Encryption Overview

Public technical overview Updated May 28, 2026 Minymata, Inc.

Minyma is designed so message and attachment contents are encrypted on sender devices and decrypted on recipient devices. Encryption is hybrid post-quantum: content is protected by both classical (X25519, Ed25519) and post-quantum (ML-KEM-768, ML-DSA-65) cryptography. The service participates in delivery, but it is not intended to hold the private keys required to read plaintext message content.

Technical Privacy

What Minyma does today

The current product uses device-based cryptographic identity and hybrid post-quantum end-to-end encryption that is live and field-tested. Initial key agreement is hybrid PQXDH, combining classical X25519 elliptic-curve Diffie-Hellman with ML-KEM-768 (NIST FIPS 203) post-quantum key encapsulation, with downgrade protection that prevents the post-quantum component from being silently stripped. The Double Ratchet then mixes a fresh ML-KEM-768 secret into the key schedule at every ratchet step, and message payloads are protected with AES-256-GCM authenticated encryption.

Every post-quantum mechanism runs alongside a proven classical mechanism as a defense-in-depth approach to the post-quantum transition. Because this hybrid protection is continuous, recorded ciphertext stays protected against a future cryptographically-relevant quantum computer, making Minyma resistant to "harvest now, decrypt later."

Minyma also uses sealed-sender delivery for current call signaling across direct and group call flows, paired with WebRTC media transport for voice and video calling on iPhone and iPad. Minyma Voice adds an optional, user-started in-app operator for local commands, draft help, translation, and staged sensitive actions.

The relay supports device registration, prekey distribution, message queueing, push delivery, and attachment relay. That means Minyma can operate as a real messaging product with a delivery path that stays clear, practical, and privacy-aware.

What is end-to-end encrypted

  • Message text
  • Message edits and deletes carried in encrypted payloads
  • Receipts carried inside encrypted message payloads
  • Attachment contents
  • Encrypted voice-note audio sent through the attachment path
  • Attachment keys shared inside encrypted message payloads

Voice, translation, and encrypted voice notes

Minyma Voice is designed as an allowlisted local operator. It can help compose, navigate, open New Message and New Group flows, open local pickers, search chats, pin or mute chats, read public Help, Terms, and Privacy pages aloud, answer WeatherKit weather questions, use a user-selected assistant reply language, translate current drafts, and stage sensitive actions, but it will not silently send messages, place calls, attach media, auto-translate, or read private message content.

Translation follows the same boundary. Draft translation uses text the user is actively composing. Translating an existing message requires explicit consent before that message content is read for translation.

Encrypted voice notes are recorded locally, previewed before sending, encrypted through the same attachment protection path, and designed to expire after first listen. Voice transcription is not automatic.

Operational data used for delivery

Minyma uses a limited set of service metadata to route messages, attachments, push notifications, and calls. That includes which user or device is sending, which user or device is receiving, timing and message frequency, ciphertext sizes, push registration and delivery timing, and limited attachment transfer metadata such as encrypted size, upload and download timing, and delivery state. Optional voice and translation features have their own user-started privacy boundary and are not the same as passive message storage.

The accurate public claim is that Minyma protects message and attachment content from relay-side plaintext access while continuing to reduce relay-visible metadata and strengthen private delivery paths.

How the current system works at a high level

  1. Each device holds long-lived local identity keys, including a classical Ed25519 signing key and a post-quantum ML-DSA-65 (NIST FIPS 204) signing key.
  2. Each device publishes signed prekeys and one-time prekeys, classical X25519 and post-quantum ML-KEM-768, to the service.
  3. A sender fetches a recipient device's prekey bundle and derives a shared secret with hybrid PQXDH (X25519 + ML-KEM-768), with downgrade protection against silently removing the post-quantum component.
  4. Direct messaging then runs a Double Ratchet that mixes a fresh ML-KEM-768 secret into the key schedule at every step, for continuous post-quantum forward secrecy and post-compromise security.
  5. Each content message is bound with dual Ed25519 and ML-DSA-65 signatures so authenticity resists a quantum adversary.
  6. Private key material stays in on-device custody rather than on the relay.

Current security posture

Minyma operates with real, live hybrid post-quantum end-to-end encryption for message and attachment content, sealed-sender delivery for call signaling, and a direct-session design built on hybrid PQXDH key agreement, a continuous post-quantum Double Ratchet, and dual-signature identity authentication.

  • Hybrid PQXDH key agreement: X25519 + ML-KEM-768 (NIST FIPS 203), with downgrade protection against silently weakening the session setup
  • Hybrid continuous ratchet: ML-KEM-768 mixed into every Double Ratchet step for ongoing post-quantum forward secrecy and post-compromise security
  • Dual identity signatures: Ed25519 + ML-DSA-65 (NIST FIPS 204) bind every content message
  • AES-256-GCM authenticated payload encryption with private keys held in on-device custody
  • Trust-on-first-use pinning with safety numbers and scan-to-verify QR
  • Resistant to "harvest now, decrypt later": recorded ciphertext stays protected against a future quantum computer
  • Minyma protects message content end to end and continues reducing relay-visible metadata
  • Current call signaling uses sealed-sender delivery across direct and group call flows
  • Encrypted voice notes are sent as protected attachments and are designed for short-lived playback
  • Voice and translation features are bounded by explicit user action and confirmation for sensitive operations
  • Built on the platform's vetted cryptographic implementations; under continuous internal security testing and queued for independent third-party cryptographic review

Security program

Minymata continues publishing deeper protocol documentation, strengthening notification privacy, refining group cryptographic design, and arranging an independent third-party cryptographic review as the hybrid post-quantum implementation finishes hardening, as part of the broader Minyma security program.

Short public description

Minyma uses device-based, hybrid post-quantum end-to-end encryption for message and attachment content - protected by both classical (X25519, Ed25519) and post-quantum (ML-KEM-768, ML-DSA-65) cryptography. Messages are encrypted on sender devices and decrypted on recipient devices. The relay stores and forwards ciphertext and routing metadata, but does not hold the private keys required to read plaintext. Key agreement is hybrid PQXDH with downgrade protection, the Double Ratchet mixes a fresh ML-KEM-768 secret in at every step, each message carries dual Ed25519 + ML-DSA-65 signatures, call signaling uses sealed-sender delivery across direct and group call flows, and encrypted voice notes use the protected attachment path with short-lived playback semantics.

Copyright © 2026 Minymata, Inc. All rights reserved.

Minyma and the Minyma logo are trademarks of Minymata, Inc.

Product

Features Preview Technical

Trust

Security Verification Transparency

Legal

Terms Privacy

Support

Help FAQ Status Contact Us