diff --git a/papers/whitepaper.md b/papers/whitepaper.md
index f7025a3..b61aefc 100644
--- a/papers/whitepaper.md
+++ b/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
 
diff --git a/rosenpass/src/protocol.rs b/rosenpass/src/protocol.rs
index 44cf57d..f56ba59 100644
--- a/rosenpass/src/protocol.rs
+++ b/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;