From 0f7e4071c2b6a6a9470cd33d822c90eb52f29d58 Mon Sep 17 00:00:00 2001 From: akwizgran Date: Fri, 12 Nov 2021 17:10:11 +0000 Subject: [PATCH] Update Transport Key Agreement Client --- Transport-Key-Agreement-Client.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Transport-Key-Agreement-Client.md b/Transport-Key-Agreement-Client.md index 60285d3..a2167cb 100644 --- a/Transport-Key-Agreement-Client.md +++ b/Transport-Key-Agreement-Client.md @@ -7,8 +7,6 @@ A key agreement session may be started between two peers, X and Y, in the follow 1. Neither of the peers supported the transport when they added each other as contacts. In this case, each peer will send a key message when it adds support for the transport. If a peer receives a key message for a transport it doesn't support, it will defer handling the message until it supports the transport. The session will complete when both peers support the transport. 2. X did not support the transport when the peers added each other as contacts, but Y did. In this case, when X later adds support for the transport, X will start a key agreement session. Although Y already has keys for the transport, it will complete the session in order to establish a new set of keys that X also possesses. -The `ACTIVATED` state lets us know that we already completed a session, so that we don't create a new session if we receive another key message from the contact. Otherwise a malicious contact could cause us to create an unlimited number of key sets and run out of memory. - ### Identifier The client's identifier is `org.briarproject.bramble.transport.agreement`. The major version is 0. @@ -45,6 +43,8 @@ The protocol uses two message types. [key-agreement-client.odg](uploads/8212325f0d636a72b6195242453f5619/key-agreement-client.odg) +The `ACTIVATED` state lets us know that we already completed a session, so that we don't create a new session if we receive another key message from the contact. Otherwise a malicious contact could cause us to create an unlimited number of key sets and run out of memory. + ### Key management For each session, each peer generates an ephemeral X25519 key pair. The public key is sent in the peer's key message and the private key is stored until the peer receives the other peer's key message. Each peer then uses its own private key and the other peer's public key to derive the [root key](https://code.briarproject.org/briar/briar-spec/blob/master/protocols/BTP.md#2-key-management-protocol) for a set of rotation mode transport keys.