You want to encrypt communications between two peers without using SSL and the overhead that it incurs. Because it is normally a bad idea to encrypt without integrity checking (to avoid attacks such as man-in-the-middle, capture replay, and bit-flipping in stream ciphers), you also want to employ some kind of integrity checking so you’ll be able to determine whether the data has been tampered with in transit.
We also assume here that you’d like to stay away from a full-fledged PKI, instead using a more traditional model of user accounts managed on a per-machine basis.
Use an authenticating key exchange mechanism from Chapter 8, and use the resulting session key with a solution for authenticated encryption, while performing proper key and nonce management.
In this recipe, we provide an infrastructure for the simple secure channel, for use once authentication and key exchange is performed.
Given the tools we’ve discussed in previous recipes for authentication, key exchange, and the creation of secure channels, producing an end-to-end solution isn’t drastically difficult. Nonetheless, there are some potential “gotchas” that we still need to address.
In protocols such as SSL/TLS, connection establishment is a bit more complex than simply authenticating and exchanging a key. In particular, such protocols tend to negotiate which version of the protocol is to be used, and perhaps negotiate which cryptographic ...