Acknowledgement
We would like to express our gratitude and appreciation to all those who gave us
the opportunity to complete this project and this report. I and my team thank our
head of department, Mrs. Archana Mate for giving us the accessory environment to
acquire knowledge and skill. Special thanks to Prof. Swati Shelar, whose help,
stimulating suggestions and encouragement, helped us to coordinate our project,
especially in writing this report.
We would also like to acknowledge with much appreciation the crucial role of the
staff of Computer Laboratory, who have given permission to use all required
machinery and the necessary material to complete the report special thanks go to
our friends, who gave suggestions about the project.
i
Abstract
In an era dominated by escalating cyber threats, surveillance concerns, and data
breaches, the need for robust digital privacy in communication has become
imperative. This final-year engineering project presents SecureConnect, an
innovative web-based secure messaging platform that seamlessly integrates end-
to-end encryption (E2EE) with a flexible credit-based top-up monetization model.
Unlike traditional messaging applications that rely on freemium or subscription-
based revenue streams—often at the expense of user data privacy—SecureConnect
empowers users to purchase credits on a pay-as-you-go basis for specific features,
such as one-on-one encrypted chats, voice calls, and media sharing. This model
provides greater control over usage and spending, making it ideal for occasional
users, freelancers, startups, and sectors requiring intermittent secure interactions,
including healthcare, finance, and legal domains.
The architecture leverages modern technologies for scalability and security: a
React.js frontend for an intuitive web GUI, AWS Lambda and API Gateway for
serverless backend processing, Amazon DynamoDB for storing encrypted user data
and credit balances, and AWS Cognito for secure authentication and session
management. E2EE is implemented using protocols inspired by the Signal
Protocol, employing libraries like libsodium or WebCrypto API to ensure messages
remain confidential between sender and receiver. Billing logic is managed via cloud
functions, deducting credits per action (e.g., per message or call minute), while the
system adheres to agile methodologies for modular development and continuous
deployment.
Drawing from literature on E2EE platforms like Signal and WhatsApp, as well as
SaaS pay-per-use models, SecureConnect demonstrates how cloud infrastructure
can facilitate transparent, affordable, and privacy-centric communication without
compromising performance. Future expansions may include group chats, role-
based access, and enhanced media features. Ultimately, this project bridges the
gap between privacy and practicality, offering a sustainable alternative to
conventional models and contributing to the advancement of secure digital
ecosystems.
ii
List Of Figures
Fig No. Name
4.1 System Architecture
4.2 ER Diagram
4.3 DFD Level 0
4.4 DFD Level 1
4.5 DFD Level 2
4.6 Activity Diagram
4.7 Sequence Diagram
iii
Table of Contents
Sr no. Description Page no.
1. Acknowledgement I
2. Abstract II
3. List of Figures III
Chapter 1 : Introduction 5
Chapter 2 : Literature Survey 6
2.1 Survey of Existing System 6
2.2 Limitation Existing System / Research Gap 6
2.3 Problem Statement & Objectives 8
2.4 Scope 9
Chapter 3 : Proposed System 10
3.1 Framework 10
3.2 Details of Hardware & Software 12
3.3 Design Details 12
3.4 Methodology 13
Chapter 4 : System Design 16
Chapter 5 : Conclusion 25
Chapter 6 : References 26
iv
1. Introduction
In today's hyper-connected world, where data breaches and privacy invasions make
headlines daily, the quest for truly secure digital conversations has never been more
urgent. Enter SecureConnect—a groundbreaking web-based messaging platform
designed to redefine how we chat, call, and share without sacrificing security or
breaking the bank. Drawing from cutting-edge encryption techniques inspired by
protocols like those in Signal, this app ensures every message and voice interaction
is locked down with end-to-end encryption, keeping prying eyes at bay.
What sets SecureConnect apart is its smart, user-centric approach to monetization:
forget rigid subscriptions or ad-cluttered free tiers. Instead, users top up a personal
credit wallet and pay only for what they use—whether it's firing off a quick text,
hopping on a voice call, or sending files. This pay-as-you-go vibe is perfect for casual
users, freelancers juggling gigs, or teams in high-stakes fields like healthcare and
finance who need ironclad privacy without ongoing commitments.
Built on a robust AWS backbone, including Lambda for seamless scaling,
DynamoDB for encrypted data handling, and Cognito for bulletproof
authentication, SecureConnect marries top-tier tech with everyday usability. It's
not just an app; it's a statement on making privacy practical and empowering,
proving that secure comms can be as flexible as your lifestyle demands. As cyber
threats evolve, projects like this pave the way for a safer digital future, one
encrypted exchange at a time.
5
2. Literature Survey
2.1 Survey of Existing System :
In the domain of secure messaging, several prominent applications have established benchmarks
for end-to-end encryption (E2EE), cross-platform accessibility, and user privacy, yet they
predominantly rely on free, donation-based, or subscription models that limit flexibility for
occasional users. Signal stands as the gold standard for privacy-focused communication,
implementing default E2EE using its proprietary Signal Protocol with perfect forward secrecy
(PFS) for messages, voice, and video calls across mobile and linked desktop clients, while
remaining completely free through non-profit donations without ads or data tracking. However,
Signal mandates a phone number for registration and lacks a fully independent web client, relying
instead on a companion desktop app tethered to a primary mobile device, which restricts
seamless web-only usage. WhatsApp, utilized by billions, provides default E2EE powered by the
Signal Protocol for one-on-one and group chats, along with a robust web client that mirrors
mobile functionality, but its free model is subsidized by Meta's extensive metadata collection—
including contacts, location, and IP addresses—raising significant surveillance concerns despite
no direct message access
2.2 Limitation of Existing System & Research Gap :
1. Lack of Pay-Per-Use Models: Most apps use free, donation, or subscription fees, causing
overpayment for occasional users; no granular credit-based billing for features like messages or
calls, leading to privacy trade-offs via ads/metadata.
2. Metadata Privacy Risks: E2EE apps collect metadata (e.g., IPs, contacts) for surveillance or
ads; WhatsApp shares with Meta, Telegram logs in non-secret chats, creating vulnerabilities
despite message encryption.
3. Phone/Email Dependency: Mandatory personal identifiers enable tracking/SIM attacks;
Signal and WhatsApp require phones, while Threema uses IDs but limits adoption with fees.
4. Non-Default E2EE: Partial encryption exposes chats; Telegram defaults to server-readable,
Wire logs data for compliance, risking interception.
5. Limited Web Autonomy: Mobile-primary designs tether web clients to phones; Signal lacks
independent web, Element is complex with slow sync.
6. Backup Vulnerabilities: Insecure or absent encrypted backups cause data loss; Signal skips
backups, Threema deletes undelivered messages.
7. Enterprise Scalability Issues: Free models lack admin tools; subscriptions (e.g., Wire) are rigid,
small user bases hinder adoption in sectors like healthcare.
6
8. Protocol Weaknesses: Audits show flaws like timestamp manipulation (Threema) or
federation issues (Element); Signal robust but vulnerable to device hacks.
9. Network Effect Barriers: Small apps (e.g., Threema, Wire) struggle with adoption vs. giants
like WhatsApp, deterring users despite better privacy.
Research Gap :
➢ There is no web-exclusive, E2EE messaging platform leveraging libsodium/Signal-like
protocols, AWS (Lambda/DynamoDB/Cognito), with a feature-based credit wallet for pay-
per-use, addressing occasional/enterprise needs without subscription lock-in.
➢ As of year 2025, we did not find any public application similar to ours
Research Papers :
1.
End-to-end encryption for securing communications in Industry 4.0
Author : Sandeep Gupta, Bruno Crispo (University of Trento)
Published in : 2022 4th IEEE Middle-East & North African Communication Conference
Paper on : Paper proposes a transparent message level end to-end encryption layer (from
publisher to subscriber and vice versa) exploiting Ciphertext-Policy Attribute-based
encryption (CP-ABE)
IEEE Link : https://pure.qub.ac.uk/en/publications/end-to-end-encryption-for-securing-
communications-in-industry-40/
2.
The Economics of Pay-per-Use Pricing
Author : David C. Parkes, Michael P. Wellman
Published in : IEEE Software, vol. 35, no. 4, pp. 59-63, July/Aug. 2018
Paper on : Explores how pay-per-use pricing drives cloud economics for variable demand,
overcoming biases toward subscriptions. While not 2022 or explicitly SaaS-focused, it's
relevant to SaaS billing evolution.
IEEE Link : https://ieeexplore.ieee.org/document/8497014
7
3.
An Understanding and Perspectives of End-To-End Encryption
Author : Ohwo Onome Blaise
Published in : 4th issue Volume 8 of International Research Journal
Paper on : This research focused on providing a performance evaluation experiment of
various cryptographic algorithms, such as Advance Encryption Standard (AES), Blowfish, Data
Encryption Standard (DES), Hybrid (AES-RSA) and Triple Data Encryption Standard (3DES), to
ascertain which is best suited for End-To-End Encryption security
IEEE Link :
https://www.researchgate.net/publication/350850077_An_Understanding_and_Perspectives_
of_End-To-End_Encryption
2.3 Problem Statement & Objectives :
Problem Statement -
In the face of escalating cyberattacks, pervasive surveillance, and frequent data breaches,
traditional messaging applications rely on freemium or subscription-based models that often fail
to accommodate users with sporadic secure communication needs, while compromising
affordability, flexibility, and privacy through data monetization or rigid pricing structures.
Objectives –
▪ To design and implement end-to-end encryption (E2EE) for all one-on-one text messages
and voice calls, ensuring complete data privacy and protection against interception.
▪ To develop a flexible credit-based top-up wallet system that enables pay-as-you-go billing
for features such as message sending, call minutes, and media sharing, providing users
with granular control over usage and expenditure.
▪ To build a scalable, cloud-hosted web platform using AWS microservices (Lambda,
DynamoDB, Cognito) for seamless authentication, data storage, and backend operations
without requiring mobile clients.
▪ To demonstrate a sustainable monetization alternative to conventional subscription or
ad-supported models, making secure communication accessible and practical for
individuals, freelancers, startups, and enterprises in privacy-sensitive sectors like legal,
healthcare, and finance.
▪ To ensure usability, performance, and future extensibility through agile development,
modular architecture, and integration of modern technologies like React.js for frontend
and libsodium/WebCrypto for encryption.
8
2.4 Scope :
1) Development of a web-based secure messaging platform with end-to-end encryption
(E2EE) using libsodium or WebCrypto API.
2) Implementation of 1-to-1 encrypted text chats and voice calls.
3) Integration of a user wallet for credit top-up and balance management.
4) Feature-based billing system (e.g., per message sent, per minute of call, per file shared).
5) Secure user authentication and session management via AWS Cognito.
6) Backend architecture using AWS Lambda for serverless compute, API Gateway for
routing, and DynamoDB for storing encrypted user data, balances, and messages.
7) Frontend user interface built with React.js for responsive and interactive experience.
8) Focus on scalability through AWS microservices and agile methodology with continuous
deployment.
9) Emphasis on privacy, usability, and affordability without data collection for monetization.
Future Scope :
1) Extension to mobile applications (iOS and Android) for cross-platform accessibility.
2) Addition of group chats with multi-user E2EE support.
3) Incorporation of media storage and sharing features with encrypted file handling.
9
3. Proposed System
The proposed system, titled "SecureConnect," is a web-based secure messaging platform
designed to address the limitations of traditional messaging applications by integrating end-to-
end encryption (E2EE) with a flexible credit-based top-up monetization model. This system aims
to provide users with enhanced control over their communication privacy and spending,
particularly suited for occasional users such as freelancers, startups, and professionals in privacy-
sensitive sectors like healthcare, legal, and finance. Unlike conventional freemium or
subscription-based models, SecureConnect allows users to purchase credits on a pay-as-you-go
basis, which are deducted for specific actions such as sending messages, initiating voice calls, or
sharing media files. This approach minimizes user churn and ensures affordability without relying
on data monetization or advertisements, thereby upholding stringent privacy standards.
3.1 Framework :
▪ System Architecture :
The architecture follows a modular, microservices-based design deployed on cloud infrastructure
to ensure scalability, reliability, and security. It employs a client-server model where the frontend
interacts with users, and the backend handles computation, storage, and billing logic. Key
components include:
▪ Frontend (User Interface):
Built using React.js, providing a dynamic and responsive web GUI for user interactions such as
sign-up, chat initiation, credit top-up, and session management. The interface emphasizes
usability with features like real-time messaging and call controls, while integrating WebCrypto
API for client-side encryption operations.
▪ Backend (Core Logic):
Utilizes AWS Lambda for serverless compute, integrated with API Gateway for handling requests.
This setup allows for event-driven processing, where actions like message sending trigger lambda
functions to deduct credits and route communications.
▪ Database:
Amazon DynamoDB, a NoSQL database, stores user data, credit balances, and encrypted
messages. Data is stored in an encrypted form to prevent unauthorized access, with partitioning
for efficient scaling.
10
▪ Authentication and Security:
AWS Cognito manages secure user sign-up, authentication, and session handling, supporting
features like multi-factor authentication (MFA) and token-based access.
▪ Encryption Layer:
Implements E2EE using protocols inspired by the Signal Protocol, leveraging libraries such as
libsodium for cryptographic operations. Messages are encrypted on the sender's device and
decrypted only on the receiver's device, ensuring that intermediaries (including servers) cannot
access content. Additional techniques, such as XSalsa20 for message encryption and Poly1305 for
message authentication codes (MAC), can be incorporated for enhanced integrity and
confidentiality, as seen in similar secure chat architectures.
▪ Billing and Monetization:
Cloud functions manage credit balances, with feature-based billing (e.g., per message, per
minute for calls, or per file shared). Integration with payment gateways (e.g., Stripe or similar)
allows seamless top-ups, and logic ensures actions are only processed if sufficient credits are
available.
The system adopts an agile development methodology with continuous deployment, enabling
iterative enhancements like future support for group chats, role-based access, and tiered features
based on credit levels. For offline handling, messages can be queued using services like Firebase
Cloud Messaging (FCM) if extended, though the initial scope focuses on web-based real-time
interactions.
Key Features
1. One-on-One Encrypted Chats and Calls: Supports secure text messaging and voice calls
with E2EE, ensuring data privacy during transmission.
2. User Wallet and Top-Up System: A digital wallet for purchasing and managing credits,
providing transparency in usage and spending.
3. Secure Sign-Up and Session Management: Robust authentication to prevent
unauthorized access.
4. Scalability and Performance: Leveraged through AWS microservices, allowing the
system to handle increased loads without compromising speed or security.
This proposed system bridges privacy and practicality by combining cryptographic best practices
with innovative monetization, making secure communication accessible and sustainable for
diverse user needs in a college-level major project context.
11
3.2 Details on Hardware & Software :
Hardware -
❖ Standard laptop or PC with at least 8GB RAM and multi-core processor for development
and testing
❖ Reliable internet connection for cloud service access and AWS integration
❖ AWS-hosted infrastructure (no physical servers required)
❖ Optional: External microphone/headset for voice call testing
Software -
❖ Operating System: Windows, Linux, or macOS
❖ Node.js (version 14.x or later) with npm (version 6.x or later)
❖ React.js for frontend development
❖ AWS CLI for managing AWS services
❖ AWS SDK for integrating AWS features like Lambda, DynamoDB, and Cognito
❖ IDE: Visual Studio Code or WebStorm
❖ GitHub for version control
❖ Encryption libraries: libsodium or WebCrypto API
❖ Modern web browser (e.g., Chrome or Firefox) for testing the web application
❖ Optional: Python for AWS Lambda functions if using Python runtime
3.3 Design Details :
High Level Architecture :
The system follows a microservices-based, serverless design with an event-driven approach for
real-time interactions and billing triggers. Key layers include:
• Client Layer: Web GUI built with React.js for user interactions (sign-up, chats, credit top-
up).
• API Layer: AWS API Gateway for handling HTTP/WebSocket requests, routing to backend
services.
• Compute Layer: AWS Lambda functions for business logic, including message
encryption/decryption handling, billing deductions, and event processing.
• Data Layer: Amazon DynamoDB for storing user data, credit balances, and encrypted
messages; Amazon S3 for media files.
• Security Layer: AWS Cognito for authentication; client-side E2EE using libsodium.
• Real-Time Communication: WebSocket connections via API Gateway for instant
messaging and presence detection.
• Billing Integration: Lambda triggers on actions (e.g., message send, call initiation) to
deduct credits from DynamoDB balances.
12
Key Components :
• Frontend (React.js): Dynamic UI for user wallet, chat interface, and voice calls. Uses
WebSocket for real-time updates and WebCrypto/libsodium for E2EE key generation and
message encryption/decryption. Integrates with AWS Amplify for simplified Cognito and
API interactions.
• Authentication (AWS Cognito): Handles secure sign-up, login, and session management
with JWT tokens. Post-confirmation Lambda adds users to DynamoDB.
• Backend Services (AWS Lambda & API Gateway): Serverless functions process requests
(e.g., message routing, credit checks). API Gateway exposes REST endpoints for non-real-
time ops and WebSockets for chats.
• Database (Amazon DynamoDB): NoSQL storage with tables for:
1. Users: PK (userId), attributes (balance, profile).
2. Messages: PK (chatId), SK (timestamp), encrypted content.
3. DynamoDB Streams trigger Lambdas for notifications or billing.
• Encryption Module: Client-side E2EE using libsodium (similar to Signal Protocol),
ensuring servers store only encrypted data.
• Real-Time Engine: AWS AppSync or WebSocket API for pub/sub messaging, with
channels like /chats/:chatId for subscriptions.
• Billing Logic: Lambda functions deduct credits per action (e.g., per message, per call
minute) from user balances, integrated with payment gateways for top-ups.
• Storage for Media: AWS S3 with signed URLs for secure file sharing, encrypted client-side.
• Presence and Notifications: Optional ElastiCache (Redis) for online status; push
notifications via Firebase or SNS for offline users.
3.4 Methodology :
A. Frontend (User Interface)
• Framework: React.js
o Component-based architecture for reusable UI (ChatWindow,
WalletDashboard, CallInterface).
o State management using React Context API or Redux Toolkit.
o Real-time updates via WebSocket (AWS API Gateway WebSocket support).
• Styling: Tailwind CSS or Material UI for responsive, modern GUI.
• WebRTC Integration:
o Use PeerJS or native WebRTC API for peer-to-peer encrypted voice calls.
o Media streams encrypted client-side before transmission.
13
• E2EE Client Logic:
o libsodium.js (JavaScript wrapper) or WebCrypto API for key generation,
encryption/decryption.
o Implement Signal Protocol-inspired double ratchet for forward secrecy.
B. Backend (Serverless Microservices)
• Compute: AWS Lambda
o Functions written in Node.js or Python.
o Triggered via API Gateway (REST & WebSocket).
o Examples:
▪ sendMessageLambda → deducts credit, logs encrypted payload.
▪ initiateCallLambda → validates balance, starts WebRTC session.
• API Layer: Amazon API Gateway
o REST endpoints for auth, wallet, user profile.
o WebSocket for real-time messaging and call signaling.
C. Data Storage
• Database: Amazon DynamoDB (NoSQL)
o Tables:
▪ Users: userID, email, publicKey, creditBalance
▪ Wallets: userID, transactionHistory, topUpLogs
▪ Messages: messageID, senderID, receiverID, encryptedPayload,
timestamp
▪ CallLogs: callID, participants, duration, cost
o Messages stored only in encrypted form – server never sees plaintext.
D. Authentication & Identity
• AWS Cognito
o User pools for sign-up, login, MFA (optional).
o JWT-based session management.
o Integration with React via Amplify Auth or AWS SDK.
14
E. Encryption & Security
• End-to-End Encryption:
o Use libsodium (preferred) or WebCrypto API.
o Key exchange via X25519 (Elliptic Curve Diffie-Hellman).
o Message encryption: AES-256-GCM or ChaCha20-Poly1305.
o Implement pre-keys and signed pre-keys (Signal Protocol pattern).
• Data in Transit: Enforced HTTPS (API Gateway) + WSS (WebSocket).
F. Billing & Monetization Logic
• Credit-Based System:
o Users’ top-up via simulated payment (or Stripe test mode in future).
o Deductions triggered on actions:
▪ Per message sent: 1 credit
▪ Per minute of voice call: 5 credits
▪ File sharing: 3 credits per file
o Lambda function deductCredit validates balance before allowing action.
o Low balance → UI warning + disable features.
15
4. System Design
Diagrams :
4.1 – System Architecture
16
ER Diagram :-
o User interacts with the React frontend.
o Frontend securely encrypts sensitive data.
o Encrypted data is sent to the Node.js backend.
o Backend authenticates requests via Cognito.
o Backend or directly Lambda performs operations on DynamoDB.
o Responses are returned to the frontend after decryption if needed.
4.2 – ER Diagram
17
DFD Level 0 :-
o Users interact through a browser to send and receive messages.
o The system uses AWS Cognito for authentication and AWS DynamoDB for data storage.
o All messages flow as encrypted data, ensuring privacy and security.
o This level highlights what the system interacts with, not how it works internally.
4.3 – DFD Level 0
18
DFD Level 1 :-
1. Frontend (React.js): Handles user interactions, encryption/decryption, and
authentication via Cognito.
2. Backend (Node.js + Express): Acts as a secure relay that forwards encrypted data
without accessing plaintext.
3. AWS Lambda: Executes message handling, data storage, and logic processing.
4. DynamoDB: Stores encrypted messages for later retrieval.
Messages move through the system as encrypted blobs, ensuring that plaintext never leaves
the user’s device.
4.4 – DFD Level 1
19
DFD Level 2 :-
• Auth Lambda: Validates authentication tokens with Cognito.
• Message Relay Lambda: Forwards encrypted messages and retrieves them
when requested.
• Billing Lambda: Manages credit deductions and updates in DynamoDB.
The diagram shows how these Lambda functions interact with each other and
with external components (Backend, Cognito, DynamoDB).
4.5 – DFD Level 2
20
Activity Diagram :-
o User Interaction (Frontend):
The process begins in the browser, where the user interacts with a React
app. Messages are encrypted locally using libsodium or WebCrypto,
ensuring plaintext never leaves the user’s device.
o Authentication:
The frontend connects to AWS Cognito for user authentication, managing
secure logins and identity verification.
o Message Transmission (Backend):
Encrypted messages are sent to a Node.js + Express backend, which acts as
a relay it never decrypts or inspects the data.
o AWS Processing:
AWS Lambda functions process the message, handle credit deductions, and
forward the encrypted data to DynamoDB for storage.
o Message Retrieval:
When the recipient requests messages, Lambda retrieves the encrypted
content from DynamoDB, sends it through Express, and delivers it to the
recipient’s browser.
o Decryption and Display:
The recipient’s React app decrypts the message locally, completing a fully
end-to-end encrypted exchange.
21
4.6 – Activity Diagram
22
Sequence Diagram :-
4.7 – Sequence Diagram
23
Overview :
Overall Flow Starts with the User: Everything kicks off from the user's browser where
they interact with a React app – think of it as the friendly front door for chatting
securely.
Encryption Happens Right at the Frontend: Before anything leaves the user's device,
the React app uses libsodium or WebCrypto to encrypt messages (and decrypt incoming
ones). This means the plain text never touches the server – true end-to-end magic.
Authentication Step: The frontend talks to AWS Cognito first to verify the user (login,
signup, etc.), ensuring only legit people get in.
Sending a Message: Once encrypted, the message gets sent from the frontend to the
backend, which is powered by Node.js with Express – it acts like a smart relay station.
Backend Relays Without Peeking: The Express backend doesn't decrypt anything; it
just forwards the encrypted blob to AWS services.
AWS Lambda Takes Over: Lambda functions handle the heavy lifting – they relay the
encrypted message further and also manage things like deducting credits for usage
(pay-as-you-go style).
Final Storage in DynamoDB: The encrypted message lands in DynamoDB, stored safely
until the recipient pulls it. Lambda can retrieve it on demand and send it back through
the chain.
Reverse for Receiving: When the other user wants the message, it's fetched from
DynamoDB (still encrypted), relayed via Lambda and Express, back to their frontend,
where it's decrypted locally.
Key Highlights: No server ever sees plain text, AWS keeps it scalable and secure, and
the whole setup supports the project's credit-based billing without compromising
privacy. It's a clean, modular loop focused on 1-to-1 secure chats.
24
5. Conclusion
The development of SecureConnect successfully meets the rising demand for secure, privacy-
focused communication in a digital landscape plagued by cyberattacks, surveillance, and data
leaks. By integrating robust end-to-end encryption with a flexible credit-based top-up model, the
project offers a practical and user-controlled alternative to traditional freemium or subscription-
based messaging platforms, catering to individuals, startups, freelancers, and part-time
collaborators with occasional secure communication needs. Hosted on a scalable AWS
infrastructure using React.js, Lambda, DynamoDB, and Cognito, the platform ensures high
usability, performance, and security without compromising privacy. This innovative approach
bridges the gap between privacy and practicality, demonstrating how secure communication can
be accessible, transparent, and affordable. The project lays a solid foundation for future
enhancements, such as group chats and media support, affirming its potential for real-world
deployment in sensitive sectors like healthcare, legal, and finance.
25
6. References
1. Marlinspike, M. (2016). *The Signal Protocol: A Foundational Document for End-to-End
Encryption*. Open Whisper Systems.
2. Amazon Web Services. (2025). *Comprehensive Documentation for Cognito, Lambda, and
DynamoDB*. AWS Official Documentation. (https://docs.aws.amazon.com/)
3. Open Whisper Systems. (2025). *GitHub Repository: Insights into Practical End-to-End
Encryption Implementations*. (https://github.com/signalapp/)
4. Libsodium. (2025). *A Modern and Easy-to-Use Cryptography Library*.
(https://doc.libsodium.org/)
5. IEEE Software Journal. (2016). *Pay-as-You-Go SaaS Pricing Models*. IEEE Xplore.
(https://ieeexplore.ieee.org/document/7427835/)
6. ACM Digital Library. (2019). *Modern Encryption and Messaging*.
(https://dl.acm.org/doi/book/10.5555/1206501)
7. Marlinspike, M. (2016). *Introduction to the Signal Protocol*. In *Meet Moxie Marlinspike, the
Anarchist Bringing Encryption to All of Us*. WIRED. (https://www.wired.com/2016/07/meet-
moxie-marlinspike-anarchist-bringing-encryption-us/)
8. Perrin, T., & Marlinspike, M. (2013). *The Signal Protocol: Double Ratchet Algorithm*. Open
Whisper Systems GitHub. (https://github.com/signalapp/libsignal-protocol-javascript)
9. AWS Documentation. (2025). *Using AWS Lambda with Amazon DynamoDB Streams*.
(https://docs.aws.amazon.com/lambda/latest/dg/with-ddb-example.html)
10. Bernstein, D. J., Lange, T., & Schwabe, P. (2011). *NaCl: Networking and Cryptography
Library*. Referenced in Libsodium Documentation.
(https://en.wikipedia.org/wiki/NaCl_(software) )
11. Perrin, T. (2018). *Noise Protocol Framework Specification*. (https://noiseprotocol.org/)
12. Katz, J., & Lindell, Y. (2014). *Introduction to Modern Cryptography (2nd Edition)*. Chapman
& Hall/CRC. (https://dl.acm.org/doi/book/10.5555/2700550)
13. Chargebee. (2025). *Pay-as-You-Go Pricing Model for SaaS Businesses*.
(https://www.chargebee.com/resources/glossaries/pay-as-you-go-pricing/)
26