feat(whitepaper): Explicitly handle erasure of eski to achieve forward secrecy

This is a minor security fix: Before this change the specification left erasing the secret key to the implementation. The reference implementation did erase `eski` but only after receiving the responder confirmation package (EmptyData at the time) instructing the initiator to stop retransmission of the InitConf package. With this change, `eski` is erased before transmission of the InitConf package.

papers/whitepaper.md

@@ -466,6 +466,7 @@ The responder does not need to do anything special to handle RespHello retransmi
 During the implementation of go-rosenpass, Steffen Vogel found a number of problems ([issue #68](https://github.com/rosenpass/rosenpass/issues/68)) with the whitepaper. Version two of the document primarily addresses these issues:
 
 - Handle race conditions when both peers complete concurrent handshakes in switched roles. Backwards compatible. Initially addressed in [397a776](https://github.com/rosenpass/rosenpass/commit/397a776c55b1feae1e8e5aceef01cf06bf56b6ed) "fix: Race condition due to concurrent handshake"
+- Explicitly erase `eski` (forward secrecy). This is a minor security fix: Before this change the specification left erasing the secret key to the implementation. The reference implementation did erase `eski` but only after receiving the responder confirmation package (EmptyData at the time) instructing the initiator to stop retransmission of the InitConf package. With this change, `eski` is erased before transmission of the InitConf package.
 
 ## Protocol version 1 -- 2023-03-04
 

rosenpass/src/protocol.rs

@@ -1604,6 +1604,10 @@ impl CryptoServer {
         // ICI7
         peer.session()
             .insert(self, core.enter_live(self, HandshakeRole::Initiator)?)?;
+
+        // RHI8
+        hs_mut!().eski.zeroize();
+
         hs_mut!().core.erase();
         hs_mut!().next = HandshakeStateMachine::RespConf;