This paper presents CrypticWave, a secure ephemeral messaging system that implements client-side authenticated encryption (AES-GCM), one-time message access, and volatile in-memory message storage. The encryption model ensures a high level of protection against tampering, as GCM provides built-in integrity verification. The system is deployed in a cloud environment using Docker containers, with a PostgreSQL database mounted on a RAM-based file system ensuring that all data is re-initialized after each restart, thereby enhancing user data protection and eliminating persistent traces. CrypticWave was tested under a threat model involving active adversaries with server access. Results show that proposed architecture significantly reduces metadata leakage and prevents message recovery after first access. System performance and usability were also evaluated through benchmarking and user testing. The findings support CrypticWave as a lightweight, privacy-preserving messaging solution suitable for sensitive information exchange in high-risk or surveillance-prone environments. The service is available at: https://www.crypticwave.tech/.
Information technologies have significantly facilitated remote communication and data exchange,
enhancing convenience and operational efficiency across numerous domains. However, the rapid
increase in the transmission of confidential data through electronic channels poses substantial
security challenges. This concern becomes particularly pronounced when dealing with sensitive
data such as passwords, API keys, access tokens, banking details (account numbers, card numbers,
IBAN, SWIFT), and confidential documents within finance, critical infrastructure, IoT, law,
journalism,
education,
research,
and
personal
communications
[
Traditional
digital
communication tools, including email, messaging applications, and cloud storage, often fail to
consistently meet the required security standards [
As discussed above, current ephemeral messaging services often retain vulnerabilities due to temporary storage of encryption keys, server logs, or persistent databases structures. To address these challenges, CrypticWave implements a zero-persistence architecture characterized by: (1) Client-side AES-GCM encryption with enforced single-use message access; (2) Volatile message storage utilizing tmpfs combined with Docker containerization to ensure RAM-only data handling; (3) Immediate and automatic data deletion after first access, with no key information retained on the server; and (4) Absence of user registration or identity tracking, thereby eliminating any possibility of linking user activities.
Data encryption ensures that transmitted messages are rendered unreadable without a
corresponding decryption key, thereby safeguarding information from malicious interception [
Each plaintext block Xi undergoes XOR operations with CTR-generated encryption output, followed by multiplication by the hash key H. The result of the last iteration is used as the hash value GHASH.
Authenticated data (AAD) and ciphertext are individually padded to 128-bit multiples and combined into a single message Si:
Authentication Tag (Tag)
128-bit hash ensuring data integrity and authenticity
AES-GCM operation begins by generating a 256-bit encryption key (K) and a 96-bit unique initialization vector (IV). Using these parameters, AES encryption in CTR mode encrypts the plaintext. Simultaneously, the GHASH function computes a polynomial-based authentication tag to check whether the data has been modified during transmission. This is done using the special GHASH hash function, which performs mathematical operations on the Galois field GF(2¹²⁸): where H = Ek(0128) denotes the hash key derived from encrypting 128 zero-bits using key; m, n represent the count of 128-bit blocks in AAD and Ciphertext, respectively, and Xi is computed as:
GHASH ( H , AAD , Ciphertext )= X m+n+1 , X i = ∑ S j ∙ H i− j +1= { i j =1
0 , for i =0 , ( X i−1 S i ) ∙ H , for i =1 , … , m +n +1 ,
AAD i , for i =1 , … , m −1 ,
AAD m* || 0128−v , for i =m , Ciphertext i−m , for i =m +1 , … , m +n −1 ,
Ciphertext n* || 0128−u , for i =m +n , len ( AAD ) || len ( Ciphertext ) , for i =m +n +1 , where len(AAD), len(Ciphertext) are 64-bit lengths of AAD and Ciphertext, respectively, v and u represent lengths of the final blocks of AAD and Ciphertext, respectively, || denotes the union of bit strings. Upon reception, the recipient, possessing the key K, decrypts the ciphertext and independently recalculates the authentication tag. If any data tampering occurs, even a single-bit change, the authentication verification fails, thus preventing unauthorized data modifications. This AES-GCM encryption model adopted by CrypticWave robustly secures data against interception, server-side vulnerabilities, and unauthorized alterations, providing strong cryptographic assurances of confidentiality and integrity.
The CrypticWave architecture offers improvements over existing ephemeral messaging tools due to (1) fully client-side encryption, ensuring plaintext never reaches the server, (2) non-transmission (1) (2) (3) and non-storage of encryption keys on the server, (3) exclusive server-side storage of encrypted content without the ability to decrypt, (4) immediate and irreversible message deletion following a single access, (5) scalability and ease of deployment through Docker containerization, and (6) automated provisioning and management of SSL, databases, and web infrastructure. Figure 1 illustrates the system architecture, depicting the communication and data flow between components. 2.2.1. Operational workflow The User1 (Sender) interacts with CrypticWave via a cross-platform front-end, inputting the message content. For each message, a unique message ID and AES encryption key are generated on the client-side. The message undergoes client-side AES-GCM encryption, producing encrypted data and an authentication tag. The encrypted message and tag are transmitted securely via the Web Crypto API to the server, generating a unique one-time-access link. User2 (Recipient) decrypts the message using the key embedded in the unique link. The client-side decryption restores plaintext and verifies the integrity via authentication tag. Immediately after successful access, the message is deleted from volatile RAM storage, ensuring zero recoverability. 2.2.2. Encryption and client-side logic All encryption and decryption of messages happen directly on the user’s device. This means that the server never sees the original message or the encryption key. When User1 creates a message, it is encrypted using a secure algorithm (AES-GCM) in the browser. After the message is encrypted, the system generates a unique link (ID) that includes the necessary information to access the message. This link is sent to User2, who can then open it and decrypt the message on their own device. 2.2.3. Network layer CrypticWave integrates Cloudflare as a secure intermediary between users and the backend infrastructure, serving as both a reverse proxy and a comprehensive security layer. When users access the CrypticWave domain, their requests are first routed through Cloudflare’s global edge network. This setup allows Cloudflare to handle DNS resolution and forward traffic to the appropriate backend services while hiding the true IP address of the host server. Cloudflare also manages SSL/TLS encryption by terminating HTTPS connections at the edge, reducing cryptographic load on the original server. To further protect the system, Cloudflare applies to a web application firewall (WAF), which detects and blocks malicious traffic. In the case of CrypticWave, the WAF is configured to filter out requests that contain SQL injection, cross-site scripting (XSS), or other common attack payloads. It also defends against brute-force attempts to guess valid message links by rate-limiting access to sensitive endpoints. Dynamic API endpoints used to transmit and receive encrypted messages are excluded from caching to maintain message integrity and the one-time access guarantee. Access to the backend server is restricted to Cloudflare’s infrastructure, preventing direct connections from the open internet. This security design reduces the attack surface and ensures that only filtered and validated traffic reaches the CrypticWave host environment. 2.2.4. Host server The main backend of the system runs on a physical or virtual server. The different parts of the application are packaged in Docker containers, which are used to isolate individual components of the CrypticWave system ensuring consistent execution environments across different deployment platforms. Containerization also enhances fault isolation, enables microservice scaling, and simplifies orchestration through Docker Compose. The host server runs Nginx frontend only sends static files (like the webpage) to the user’s browser; Nginx backend handles incoming and outgoing requests, acting as a bridge between the frontend and the database; PostgreSQL (in tmpfs) is a database, but it is stored only in the server’s RAM (temporary memory). Nothing is saved on the hard disk, so once the server restarts or data is accessed and deleted, there’s no way to recover it. 2.2.5. Technology stack and design considerations The PostgreSQL database is deployed entirely in-memory using an RAM-based filesystem (tmpfs). This ensures that all encrypted messages reside only in volatile memory and are irretrievably lost upon access, server reboot, or container restart. This approach eliminates the risk of residual data being recovered through forensic analysis. While it limits the system’s capacity to the available RAM and forfeits persistence across reboots, these are acceptable trade-offs in a design where message permanence is intentionally avoided. The full application stack is containerized using Docker and orchestrated with Docker Compose, enabling isolated, repeatable deployments across cloud infrastructure hosted on Proxmox. This architecture supports CrypticWave’s core objectives: secure message lifecycle control, minimal metadata exposure, and efficient, stateless deployment. While its functionality overlaps with some Docker-native features, PM2 adds another layer of resilience and observability during development and staging without introducing significant complexity.
The CrypticWave service was evaluated across three key dimensions: (i) security against
postcompromise threats, (ii) system performance under realistic load, and (iii) usability and user trust.
Where possible, we compare CrypticWave with two widely used ephemeral messaging tools:
Privnote and OneTimeSecret. To the best of our knowledge, no prior academic work has published
memory-dump analyses of ephemeral messaging systems such as Privnote or OneTimeSecret. At
the same time, extensive memory-forensics research confirms that sensitive plaintext or encryption
artifacts frequently remain in RAM post-deletion [
To evaluate system performance, we deployed CrypticWave in a controlled environment on a Proxmox virtual container with 2 vCPUs and 4 GB RAM. Stress tests were performed using work and custom Python clients simulating concurrent user behaviour under various load conditions (10, 50, and 100 concurrent users). Under varying load conditions, CrypticWave remained highly responsive. Cold response times, which include initial Docker container start-up, averaged 145 milliseconds, while warm response times stabilized around 48 milliseconds after boot. The system sustained a maximum throughput of approximately 620 messages per minute with 100 concurrent users, without degradation in performance. Steady-state memory usage remained around 208 MB, which includes the front-end, back-end, and the PostgreSQL database running entirely in RAM via tmpfs. This in-memory design significantly accelerated message access and deletion operations by eliminating disk I/O, and CPU usage did not exceed 11% even under peak load, confirming the system’s suitability for lightweight, ephemeral messaging in real-time environments.
A usability study was conducted with 24 participants (12 technical and 12 non-technical users), split between an A/B comparison of CrypticWave vs. Privnote. Each participant completed a set of guided tasks (send, view, and delete a message), followed by a post-test survey. Table 3 presents comparison of usability metrics gathered from CrypticWave and Privnote.
Participants particularly appreciated the one-time access feature, lack of registration, and clarity of encryption messages on the UI. However, a few users initially struggled to understand that the system does not retain messages at all, a usability challenge also noted in open-ended feedback. This study presents CrypticWave, a stateless, zero-persistence encrypted messaging service designed around the principle of security by design. Through controlled experiments, we demonstrated that CrypticWave effectively prevents post-compromise data recovery, maintains stable performance under realistic user loads, and delivers a positive user experience with high perceived trustworthiness. These results validate the system’s core architectural choices, particularly full client-side AES-GCM encryption, RAM-only storage using tmpfs, and the absence of user tracking or persistent logs. However, while CrypticWave eliminates several critical vulnerabilities found in traditional ephemeral messaging tools, some residual risks remain inherent to its architecture and operational environment. To further strengthen the security guarantees of CrypticWave, we plan to conduct controlled forensic analyses of self-hosted replicas of Privnote and OneTimeSecret and compare residual artefacts, metadata retention, and RAM persistence behaviour across platforms. Future iterations of CrypticWave will explore deploying a decentralized proxy network to reduce dependence on third-party infrastructure. We also plan to extend the bearer-link mechanism with optional multi-factor access, ephemeral DNS entries, and client-side passphrase layers to reduce the risk of token interception. A formal threat model and penetration testing campaign will be developed to evaluate CrypticWave against known attack vectors. Through these developments, we aim to establish CrypticWave not only as a practical tool for secure ephemeral messaging, but also as a reference model for zero-trust, zero-persistence communication architectures.
Portions of this manuscript were prepared with the assistance of AI-based language tools, including OpenAI’s ChatGPT and Grammarly, for tasks such as editing, grammar correction, and improving technical writing. All scientific content, architectural design, experimental methodology, and analysis were implemented, and validated by the authors. The AI was not used to generate data, conduct experiments, or formulate original research ideas. The authors used also Strike Plagiarism to search for possible plagiarism.