Rosenpass Protocol Version 2

[koraa]

TODOs (Karolin):

• Use Sha3/KMAC as the hash function (by @koraa )
• Add a version string and a protocol id
• Add version info and protocol version to each package
• Provide a package with versioning information Introduce an extra packet that provides versioning information #109 (by @koraa)
• Describe Remove Payload transmission as a possible protocol extension
• Describe how to roll a protocol extension that handles payload data
• Introduce a dedicated mechanism for the final confirmation package, other than EmptyData.
• Simplify replay handling by mandating a hash-based reply mechanism (no need to detect biscuit replay and trigger retransmission there)
• Highlight relation to WireGuard whitepaper
• Is it even necessary to mix in ct and pk in encaps_and_mix? Does CCA2 security imply that the shared key must be tied to ciphertext and public key?
• The MAC should not prevent identity hiding (Symbolic verification should cover identity hiding #21)
• The biscuit additional data should not prevent identity hiding (Symbolic verification should cover identity hiding #21)

---

Blockers:

• Use NIST PQC Round 4 implementation of Classic McEliece #91
• Actully add the zeroize feature RustCrypto/hashes#511

---

Todo Marei (please do not work on those yet):

• Make sure the "References" section appears in the toc
• "Version history" chapter should not get its own number
• Move Fig1 to front page, page 2 shared between TOC and Fig 2?
• The list in "Cryptographic building blocks" might need some work to look decent. Maybe the acronym on the left, name of the scheme right and flushed right ref to the spec, Version of the scheme, description?

---

Todo Mullana (please do not work on these yet):

• Add a abort_initiator_handshake() call as ICR8 in the protocol steps graphic

• Figure 2: Add a note to the bottom saying "All numeric values are in little-endian format"

• Figure 3: Add short codes from Fig 4; IHI1/IHR1 etc

• Figure 3: Add a note pointing people to fig 4 for details about security levels achieved and for the code to use this tree

• Figure 3: Introduce a special symbol for the mix, then value sequence and maybe a "zoomed in" explanation.

• Figure 4: Get rid of semicolons

• Figure 4: ct1 with sctr in IHR5

• Figure 4: Add a step RHI8 to erase the ephemeral secret keys

  Initiator line	Initiator code	Responder Line	Responder code	Comment
  RHI8	erase(eski)	RHR8		Erase the ephemeral secret key to achieve forward secrecy. Implementations may defer execution of RHR8 until completion of the handshake (after ICI7) before transmission of InitConf.

• Figure 4: Add a box with a table indicating when security properties are reached:

  Property	Reached after	Comment
  Secrecy	IHI5/IHR5	Based on sskr/spkr (the responder's static key pair)
  Responder authentication	RHI7	Responder authentication is reached after the initiator processes the complete RespHello message. The crucial step is proving that the responder was able to decapsulate the secret encrypted with their static public key (IHR5). This confirmation is produced by the responder in RHR7 and checked in RHI7.
  Initiator authentication	ICR5	This works similar to responder authentication. In RHI5 the initiator decapsulates a secret with their static secret key; they provide a confirmation in ICI4, this confirmation is checked in ICI5. Final confirmation is achieved after biscuit replay detection in ICI5.
  Forward secrecy	RHI8	The initiator generates a fresh ephemeral keypair before the handhshake; the responder encapsulates a random secret in RHR4 and the initiator decapsulates it in RHI4. Forward secrecy is achieved after the ephemeral secret key is securely erased in RHR8.

/cc @stv0g

Fixes: #68