WolfP2PHow WolfP2P encrypts a browser-to-browser file transfer
For:Advanced users and digital professionals
Assumes familiarity with files, browsers, and common computer workflows.WolfP2P uses the standardized security built into WebRTC browsers. The sending and receiving WolfP2P browser clients establish and operate a Datagram Transport Layer Security (DTLS)-protected data channel; as connected browser peers, they stream file bytes and exchange file metadata over that channel. WolfP2P does not invent a proprietary encryption protocol or ask you to manage certificates and keys.
This provides confidentiality, integrity protection, authentication of the cryptographic channel endpoints, and negotiated session keys. It does not by itself verify the real-world identity of the person using the other browser.
How the channel is protected
The WebRTC Data Channels standard carries Stream Control Transmission Protocol (SCTP) data inside DTLS. The DTLS layer protects the complete SCTP packet, providing confidentiality, cryptographic endpoint authentication, and integrity protection while the bytes cross the network.
The WebRTC Security Architecture requires every WebRTC data channel to be secured with DTLS and defines baseline implementation requirements. The DTLS version and algorithms actually negotiated depend on the capabilities of both browsers.
The browsers perform the handshake, negotiate the supported protection, encrypt outgoing data, and decrypt it at the receiving endpoint. WolfP2P uses the resulting browser data channel but does not implement or replace its cryptography.
How DTLS compares with familiar secure channels
| Familiar use | Standard transport protections | What varies in practice | |
|---|---|---|---|
| DTLS for WebRTC data channels | WolfP2P and other browser peer connections | Encryption, integrity protection, source authentication, and negotiated session keys | Browser support determines the negotiated DTLS version and algorithms |
| TLS | HTTPS, FTPS, secure email transport, and many messaging-service connections | Encryption, integrity protection, server authentication, and negotiated session keys | Protocol version, configuration, and whether client authentication is used |
| SSH transport | SFTP and secure remote administration | Encryption, integrity protection, server authentication, and negotiated session keys | Client and server configuration, algorithms, and authentication method |
What the encryption prevents
The encrypted data channel prevents passive network intermediaries—including internet providers, local-network observers, and infrastructure between the peers—from reading the transferred file bytes or changing them without detection.
WolfP2P's coordination server cannot read the transferred file contents or file metadata either. It helps establish the connection and processes coordination data, but it does not receive the file-data channel. Read What WolfP2P's Server Sees for the complete coordination-data boundary.
What transport encryption does not guarantee
Transport encryption protects the channel, not everything at either endpoint. The sender and receiver browsers necessarily process readable bytes, so a compromised device, browser, extension, or unintended recipient could still access them. The protected channel does not independently prove the real-world identity of the person using the other browser. Share the invitation privately and confirm the recipient through a trusted channel when the files are sensitive. WolfP2P currently does not provide an out-of-band fingerprint comparison, so its coordination server remains part of the connection's trust model. DTLS integrity does not digitally sign a file, prove who created it, scan it for malware, or turn successful delivery into a backup. WolfP2P's separate local SHA-256 checks support destination reuse and recovery; read Transfer Reliability and Recovery for that model.
Read Why Avoiding an Intermediary File Copy Improves Privacy for the separate storage-exposure concern, or How No Middle Copy Works for the file path through WolfP2P.