P2P Group Chat: Features, Security, and FAQ

How It Works and The Workflow

This script manages the functionality of a P2P group chat, focusing on client-side encryption and server-based communication for specific features. The general workflow is as follows:

1. Initialization and Username Setup: When a user first visits the page, the script checks for an existing user ID in a cookie. If none is found, the user is prompted to enter a name. A unique user ID is created and stored in a cookie.
2. Creating or Joining a Group:
   • Creating a Group: A user creates a new password. The script uses this password and a randomly generated group ID as a "salt" to create an encryption key. The group ID and admin ID are sent to the server to create the new group.
   • Joining a Group: A user enters an existing group ID. The script then prompts for the group password. This password and the group ID are used to create the encryption key. If the key is successfully created, the script notifies the server that the user wants to join the group.
3. Encrypted Communication: All sent messages are encrypted using the key created earlier. The messages are sent to the server in an encrypted form, along with an "IV" (initialization vector) which is unique for each message. The server stores these encrypted messages.
4. Long Polling: After joining, the script uses a long polling technique to communicate with the server. The script sends a request to the server and waits for a response. The server will hold this request until there is an update (e.g., a new message or a new user joins) before sending a response. This technique is much more efficient than constant polling and reduces latency.
5. Updates and Decryption: When the server responds, the script receives an updated user list and encrypted chat messages. These messages are then decrypted on the client side using the same encryption key. The successfully decrypted messages are displayed in the chat interface.

Benefits and Advantages

• End-to-End Encryption (E2EE): This is the main security feature. The encryption key is never sent to or stored on the server. The key only exists on the client side, generated from the group password known to all group members. This ensures that even the server administrator cannot read the content of the messages.
• Data Protection: Because messages are encrypted, the chat content is protected from interception, eavesdropping, or unauthorized access by third parties.
• User Privacy: The randomly generated user ID (`NAME_random123`) helps maintain privacy by obscuring the user's true identity from server spies, although the user's first name is visible to other group members.
• Admin Control: The group creator automatically becomes the administrator and has the ability to delete the group, which provides important control over its existence and privacy.
• Network Efficiency: The use of long polling instead of constant polling reduces the load on the server and resource consumption on the client side, as the client does not need to repeatedly request updates.
• Clear Codebase: The comments and refactoring in the code show an effort to make it easy to understand and maintain, with a clear separation between cryptographic, utility, and API communication functions.

Security Level

The security level in this script is very high, mainly due to the use of client-side encryption The security fully depends on the strength and secrecy of the group password If the password is leaked, anyone can join and decrypt past and future messages.

• The Server Doesn't Know the Message Content: The server only acts as a "bridge" or "intermediary." It receives and transmits encrypted messages, user lists, and other group information. It never sees, stores, or has access to the actual encryption key or message content.
• Strong Encryption Method: The script uses `AES-GCM` with a 256-bit key, which is a robust industry standard for symmetric encryption. The use of `PBKDF2` to transform the password into a cryptographic key is also a best practice, as it makes brute-force attacks more difficult.
• Potential Vulnerabilities: The main potential vulnerabilities lie in:
  • Weak Password: Users choosing an easy-to-guess password.
  • Client-Side Tampering: While the server doesn't store the key, a malicious client that modifies the script could send or receive unencrypted messages, although messages sent by other users remain secure because they use the same key.
  • Man-in-the-Middle Attack: If the connection to the server is not secure (not using HTTPS), an attacker could intercept the transmitted data, although the message data itself remains encrypted and unreadable. However, this script uses `https://p2psecret.com` which indicates that the connection is secure.

Frequently Asked Questions