This repository has been archived by the owner on Nov 6, 2020. It is now read-only.
SecretStore: use random key to encrypt channel + session-level nonce #6470
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
svyatonik
added
A0-pleasereview 🤓
svyatonik
force-pushed
the
secretstore_session_key
branch
from
cb3af5e to
1639785
Compare
NikVolf
reviewed
Sep 6, 2017
| @@ -317,6 +342,21 @@ impl ClusterSessions { | |||
| } | |||
| Ok(encrypted_data) | |||
| } | |||
|
|
|||
| /// Check or generate new session nonce. | |||
| fn check_session_nonce(&self, master: &NodeId, session_nonce: Option<u64>) -> Result<u64, Error> { | |||
There was a problem hiding this comment.
it's already in a session-ish mod, could be named just check_nonce
NikVolf
reviewed
Sep 6, 2017
| @@ -59,6 +59,8 @@ struct SessionCore { | |||
| pub key_share: DocumentKeyShare, | |||
| /// Cluster which allows this node to send messages to other nodes in the cluster. | |||
| pub cluster: Arc<Cluster>, | |||
| /// Session-level nonce. | |||
| pub session_nonce: u64, | |||
There was a problem hiding this comment.
could be named just nonce, since it's inside a SessionCore struct
NikVolf
reviewed
Sep 6, 2017
| pub cluster: Arc<Cluster>, | ||
| /// Session nonce. | ||
| pub session_nonce: u64, |
NikVolf
reviewed
Sep 6, 2017
| @@ -71,6 +73,8 @@ pub struct SessionParams { | |||
| pub key_storage: Arc<KeyStorage>, | |||
| /// Cluster | |||
| pub cluster: Arc<Cluster>, | |||
| /// Session nonce. | |||
| pub session_nonce: u64, | |||
NikVolf
reviewed
Sep 6, 2017
| @@ -252,6 +265,14 @@ impl SessionImpl { | |||
|
|
|||
| Ok(()) | |||
| } | |||
|
|
|||
| /// Check session nonce. | |||
| fn check_session_nonce(&self, message_session_nonce: u64) -> Result<(), Error> { | |||
There was a problem hiding this comment.
it's SessionImpl, makes sense to call method just check_nonce
|
Small grumble about avoiding long naming, logic looks ok, but would like another look from @keorn maybe |
NikVolf
added
A5-grumble 🔥
svyatonik
added
A0-pleasereview 🤓
keorn
approved these changes
Sep 13, 2017
NikVolf
added
A8-looksgood 🦄
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Given: SecretStore = set of KeyServers. Third-party KeyServer can't just 'enter' this set - it must be added to the set, using some administrative protocol. To ensure that we're connecting to servers from this set only, every KeyServer has its own KeyPair. By signing some_data with this KeyPair, KS can prove that it is the one that we're trying to connect.
Previously: during handshake, KS1 && KS2 a new Channel.KeyPair was computed from KS1.KeyPair && KS2.KeyPair. This Channel.KeyPair was used to encrypt the channel between these two key servers. So even after restart key was the same => it was possible to successfully replay previously captured messages.
This PR outline:
session_counter: usize, which is used as session-level nonce. When session is created on master node,session_counteris increased, and passed along with every session message. Every message for the same session must contain this number, or else session will fail. When node receives next session initialization message, it checks if its nonce is larger than previous nonce, received from the same node: if so, session is created, else creation fails (this implies that this KeyServer could be master for at mostusize::MAXsessions between consequent KeyServer restarts, which I suppose is enough).So, in assumption that trying to replay same-session messages could only lead to session failure (this is out of scope of this PR, but mostly true), there's no way to successfully use messages from previous sessions.