How P2P Chat Works on P2PSecret.com

How It Works and the Process Flow

This script implements a WebRTC-based P2P chat, a technology that allows two browsers to communicate directly without a central server for the chat data itself. The process is divided into several main stages:

1. Connection Initiation (Signaling)

• Host (Creator): The host starts the session by creating a unique ID (fileId) and sends a "create" request to the signaling server. The script then creates RTCPeerConnection and DataChannel objects for chat data. The host generates a WebRTC "offer"—a description of the desired session—and uploads it to the signaling server.
• Guest (Receiver): The guest joins by entering the shared ID. The script sends a "fetch" request to the signaling server to retrieve the "offer." Upon getting the offer, the guest creates a WebRTC "answer" in response and sends it back to the signaling server.
• Signaling Server: The role of this server is very limited. It acts only as an intermediary for the exchange of the "offer" and "answer." Once the "answer" is sent, the server deletes the data to ensure no further signaling information is accessible, allowing a pure P2P connection to form. The server never stores or processes the actual chat data.

2. P2P Connection Establishment

After the "offer" and "answer" exchange is complete, both browsers have the necessary information to establish a direct connection. This process uses ICE (Interactive Connectivity Establishment) to find the best path between the peers, often with the help of STUN/TURN servers to bypass firewalls. Once the path is found, the DataChannel opens and the chat interface appears.

3. Communication and Additional Features

• End-to-End Encryption (E2E): This is the core security feature. Every text message, file, and even ping/pong metadata is encrypted using a key derived from a secret password entered by the user (keySecret). The script uses the robust AES-GCM algorithm from the Web Crypto API. Because of this encryption, even if a third party were to monitor the signaling data, they would be unable to read the contents of the communication.
• File Transfer: For files, the script breaks them into 16KB chunks. Each chunk is sent one by one with a confirmation mechanism (chunkAck). This ensures that large files can be transferred reliably.
• Keep-Alive and Reconnect Mechanism: The script sends an encrypted ping/pong message every 5 seconds to ensure the connection stays active. If the connection is lost, the script will automatically attempt to reconnect using the ID and key stored temporarily, making the session more stable.
• Session Storage: The connection ID is stored in localStorage for persistence, allowing users to return to the same session even after closing the browser. The encrypted session key, however, is stored in sessionStorage, which is cleared when the tab is closed, providing a balance between convenience and security.

Benefits and Advantages

• High Privacy and Security: Communication is P2P and fully E2E encrypted. Chat data never passes through a server, and the message content cannot be read by any third party.
• No Data on Server: The server is only used for initiation and does not store any chat data. This significantly reduces the risk of server-side data breaches.
• Encrypted File Transfer: This feature ensures that shared files have the same level of privacy as text messages.
• Stable Connection: The ping/pong and automatic reconnect mechanisms keep the connection alive and allow it to recover from minor interruptions.
• User Convenience: The auto-connect option and temporary session storage allow users to easily resume conversations without re-entering the password repeatedly.

Security Level

The security level of this script is very good for private communication.

Strong Encryption: The use of AES-GCM 256-bit is an industry-standard that is extremely difficult to break.

Secure Key Derivation: Using PBKDF2 with 100,000 iterations makes a brute-force attack on the password highly impractical.

Secure Key Handling: The key (keySecret) is not stored in plaintext but is encrypted before being saved in sessionStorage, providing an extra layer of protection.

Password Mismatch Warning: The script provides a warning if the passwords do not match, preventing users from sending data that cannot be properly encrypted or decrypted.

Frequently Asked Questions