home
Please refer to the README.md for instructions on how to run Secure Messaging Application.
A video demo of Secure Messaging Application in action can be found here.
Please refer to the archived legacy Gitlab repo to view the project's activity history. Secure Messaging Application moved repos because of a bug that prevented us from pushing changes to the legacy repo.
See the below implementation notes for detailed technical specifications and explanations for how each requirement is implemented.
| Requirements | Result | Implementation Notes |
|---|---|---|
| SM must support 1:1 messaging |
1:1 messaging supported | Application Networking |
| Text messages as well as pictures should be supported | Integrated GUI for displaying text and image messages | Application Networking |
| Message history is kept in encrypted form (at-rest encryption) | Message history is encrypted at rest and stored locally | Message History |
| Message history (for a particular conversation) can be deleted by a user | Users can delete their local message history with a particular user | Message History |
| Message transport uses end-to-end encryption with perfect forward secrecy | Messages are end-to-end encrypted with AESGCM and a shared key derived using Diffie-Hellman, and the shared key is freshly generated for every new message to support perfect forward secrecy | Message Encryption |
| Users are authenticated (i.e., they should be guaranteed to talk to the right person) | Clients connect via TLS to the server with the server's self-signed certificate to authenticate the server, and the server authenticates clients with user account credentials (username and password) | Application Networking and Account Management |
| Message integrity must be assured | Messages are encrypted with AESGCM which provides built-in message integrity assurance | Message Encryption |
| Users can plausibly deny having sent a message | Messages are encrypted with AESGCM using a shared key which is known to both users allowing either to plausibly deny sending the message | Message Encryption |
| Users can sign up for an account and also delete their account | Users can register a new account or delete an existing account with a username and password | Account Management |
| SM must be implemented in Python | Secure Messaging Application is implemented in Python | See README.md and source code |
High level DFD:
Once the user has authenticated their account with the server, the user controls the client by selecting various options in the client GUI or inputting data. The client handles the user's commands or inputs and updates the GUI as required. Message history is handled client-side and thus does not require server interaction. Other functionality such as account management and messenging requires the client to send application messeges to the server for server-side processing.
The user can command the client to register, login, or delete an account but must input valid account credentials to do so. The client will send application messages to the server to validate their inputted credentials against the users.db database. The server responds to the client with a status code, and the client handles successful and failed codes accordingly.
Upon first successful login, the client will automatically generate a user configuration file for the user which is saved locally on disk to support message history functionality.
See Account Management for more information.
The client sends application messages to the server for account management and messenging functionality. Application messages contains control headers that tells the client or server what kind of event (i.e., account management or messenging) has been triggered and how to handle it accordingly.
See Application Networking for more information.
Client-to-client messages are automatically encrypted by each user's client before ultimately being encapsulated in outgoing application messages and sent to the server. The server forwards these application messages accordingly to the recipient client (incoming application messages from the point-of-view of the client).
See Message Encryption for more information.
Peer messages received by the client are automatically saved encrypted to message history. The user can command the client to retrieve, decrypt, and view the message history, or delete the message history altogether.
See Message History for more information.
Secure Messaging Application is a simple prototype. Further improvements can be made, and a few are enumerated below:
- More exhaustive list of common passwords to strengthen user authentication by preventing the usage of weak passwords
- Use a long-term CA-signed over a self-signed certificate that is automatically re-generated at server initialization
- Expand the networking code to work outside of a single-device context (i.e., user-configurable server hosting and client connections instead of
localhost)