Protocol
The Cryptosphere will use a UDP-based protocol. The motivation is NAT traversal via UDP hole punching (e.g. STUN/ICE). UDP-based protocols are employed by many P2P systems for this reason, such as the uTP protocol in BitTorrent. Freenet also moved from TCP to UDP to leverage this technique.
UDP also has benefits for overlay networks (citation needed!)
There are many options for securing UDP-based protocols. Transport security protocols are among the most difficult to design and the most fraught with errors, so the goal will be to leverage existing protocols/designs rather than inventing a new transport protocol. Any system employing a homebrew transport encryption protocol is, at best, ill-advised, and at worst, horribly horribly insecure.
The following options are being considered, with CurveCP being the present favored choice:
CurveCP is a UDP-based encrypted transport protocol created by Daniel J. Bernstein based on primitives from the Networking and Cryptography Library (NaCl) including the Curve25519 Diffie-Hellman algorithm and the XSalsa20 stream cipher.
CurveCP is a relatively new transport security protocol, is somewhat poorly understood (or not even known) by the greater security community, and is incomplete by admission of its own author.
- Mutual Authentication
- "Perfect" Forward Secrecy (both passive and active, i.e. CurveCP offers forward secrecy even in the case of a MitM)
- Small keys (256-bit via Curve25519 ECC)
- Provides stream-oriented semantics (ala TCP) needed for large file transfers
A quick note on the cons: all of these are due to the present state of the implementation and are NOT problems with the CuveCP protocol itself
- "Alpha-test" quality according to its author. Experimental, poorly reviewed
- Poor performance in congested scenarios (this is, again, due to the alpha-test quality of the current implementation)
- Current implementation has known security problems
Datagram TLS is the UDP equivalent of the Transport Layer Security protocol. DTLS is fairly widely deployed and used for things like the WebRTC protocol.
- Multiple production quality implementations available
- Somewhat well known and researched
- Would probably make FIPS-140 certification easier
- Does not provide forward secrecy (could with ECDH possibly?)
- Does not provide stream-oriented semantics (would require some other UDP stream protocol like LEDBAT)
"There are some beautiful networking protocols that could be made with Curve25519. CurveCP is but one." -Dan Kaminsky (from DJB@CCC 2011)
Unless you're a cryptographer by profession (and even then!), creating a new encrypted transport protocol is a terrible idea, because transport encryption needs to consider a multitude of active attacks: it's basically among the most complex and most attacked cryptosystems being engineered today. Fortunately, the cryptographic components of the CurveCP protocol (e.g. NaCl's crypto_box) are high-level and the protocol is well-described. Reimplementing the handshake on top of NaCl is not particularly difficult (Grant Rodgers did an implementation in Ruby using RbNaCl)
It should be possible to combine the CurveCP security model (i.e. cryptographic components of the protocol design, taken separately from the "Chicago" decongestion algorithm) with a datagram-based streaming transport that has a robust existing implementation. One example of this is the Low Extra Delay Background Transport (LEDBAT) protocol and the robust libutp implementation. The library provides callback APIs which can be used for handling encryption/decryption of individual packets, meaning once the handshake has completed then libutp can take over managing packet transmission/flow control while NaCl primitives are used to encrypt the session using a CurveCP-like protocol.