-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rosenpass Protocol Version 2 #136
Conversation
…condition handling
papers/whitepaper.md
Outdated
|
||
# Version history | ||
|
||
## Version 2 -- XXXX-XX-XX |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm. These version numbers do not align with the git tags of this repository. Maybe we should include the git hashes of the whitepaper versions alongside?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Its a protocol version, not a source code version
…d 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.
Fix a typo "key chaining extract" -> "chaining key extract"; "key chaining init" -> "chaining key init"
Issue: #68 (#68 (comment)) pk, shk, ct -> pk, ct, shk
@@ -228,6 +228,10 @@ Implementations must account for this possibility by aborting any ongoing initia | |||
|
|||
In practice these delays cause participants to take turns acting as initiator and acting as responder since the ten seconds difference is usually enough for the handshake with switched roles to complete before the old initiator's rekey timer goes to zero. | |||
|
|||
## Endianess |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: It is spelled "Endianness"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Besides this, is this section even required. As far as I can tell, the protocol does not transmit any integers, but only single-byte integers or binary data.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feel free to use your push rights for spell correction, but do notify me please so I do not accidentally overwrite your commit.
Besides this, is this section even required. As far as I can tell, the protocol does not transmit any integers, but only single-byte integers or binary data.
There is the biscuit counter…
ebe3928
to
1cf5feb
Compare
TODOs (Karolin):
DescribeRemove Payload transmissionas a possible protocol extensionct
andpk
inencaps_and_mix
? Does CCA2 security imply that the shared key must be tied to ciphertext and public key?Blockers:
Todo Marei (please do not work on those yet):
Todo Mullana (please do not work on these yet):
Add a
abort_initiator_handshake()
call as ICR8 in the protocol steps graphicFigure 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
withsctr
in IHR5Figure 4: Add a step RHI8 to erase the ephemeral secret keys
Figure 4: Add a box with a table indicating when security properties are reached:
/cc @stv0g
Fixes: #68