The Modern Web as a Secure Cryptographic Runtime
In the early days of the web, conducting military-grade cryptographic operations inside a browser required clunky Java applets, ActiveX controls, or proprietary browser toolbars. Today, modern web standards have elevated the browser into a high-performance, hardened cryptographic runtime.
SnapTransfer combines W3C WebRTC specifications and the Web Cryptography API to enforce continuous end-to-end confidentiality for every byte shared across our network.
The Cryptographic Handshake Step-by-Step
Here is the exact cryptographic sequence executed when two peers connect:
- Signaling & Ephemeral SDP: Peer A creates an SDP offer containing transport candidates and a cryptographic fingerprint of Peer A's self-generated DTLS certificate.
- DTLS Mutual Authentication: When Peer B answers, both peers establish a DTLS session. During the handshake, they verify that the remote certificate matches the fingerprint communicated out-of-band via signaling.
- Key Agreement: The peers derive symmetric encryption keys using Elliptic-Curve Diffie-Hellman Ephemeral (ECDHE). These keys exist solely in transient memory; neither the signaling server nor any middlebox can observe the agreed master secret.
- Encrypted SCTP Encapsulation: All subsequent file chunks transmitted through the RTCDataChannel are encrypted with authenticated AES-GCM, verifying integrity and preventing replay attacks.
Integrity Verification and Tamper Resistance
Because AES-GCM is an Authenticated Encryption with Associated Data (AEAD) scheme, each chunk arrives with an authentication tag. If any byte is altered in transit—whether due to packet corruption or intentional man-in-the-middle tampering—the cipher block fails authentication and is discarded immediately.
This guarantees that the receiver gets an exact, tamper-proof replica of the sender's original file.