Colin Percival's spiped utility uses a pre-shared key and Diffie-Hellman with ephemeral keys to provide forward secrecy. The protocol is summarized in the project's README under the section "Encrypted Protocol".
What is the purpose of the nonces (nonce_C and nonce_S)? How are they useful when x_C and x_S are already chosen at random?
Without the nonces, one could violate explicit authentication
by replaying the group_element || MAC_tag messages.
Without the initial exchange of nonces, an attacker could replay a recorded handshake. Although an attacker can't use this to replay actual packets, an attacker could possibly execute a denial of service attack if the process protected by spiped is not expecting a large number of connections.
The attack (assuming a modified spiped protocol that MACs the public keys directly with the long-term key):
y_C || h_C, where y_C is the client's ephemeral public key and h_C = HMAC(K, y_C) (K is the pre-shared key).y_C || h_C. The server sees a valid MAC, and presumably opens a connection to the protected process.Thanks to Ricky Demer for the discussion on his answer.
group_element || MAC_tagto the party that message $\hspace{.26 in}$ was sent to before, even though that "party will end up computing a different shared secret every time." $\hspace{.15 in}$ – May 07 '15 at 03:06group_elementas valid, and computes a newy_SC(a new shared secret). The receiver then derives the new AES and HMAC keys. How does the attacker now produce a packet with a valid HMAC tag? The attacker can't simply replay packets because the HMAC key has changed, AFAICT. – Tim McLean May 07 '15 at 03:14