mirror of
https://github.com/simplex-chat/simplexmq.git
synced 2026-06-07 17:32:12 +00:00
docs: fix minor issues in protocols
This commit is contained in:
Evgeny @ SimpleX Chat
+10
-10
@@ -94,22 +94,22 @@ The procedure of establishing a duplex connection is explained on the example of
|
||||
4. Bob uses agent `joinConnection` api function with the connection link as a parameter to agent B to accept the connection.
|
||||
5. Agent B creates Bob's SMP reply queue with SMP router `NEW` command.
|
||||
6. Agent B confirms the connection: sends an "SMP confirmation" with SMP router `SEND` command to the SMP queue specified in the connection link - SMP confirmation is an unauthenticated message with an ephemeral key that will be used to authenticate Bob's commands to the queue, as described in SMP protocol, and Bob's info (profile, public key for E2E encryption, and the connection link to this 2nd queue to Agent A - this connection link SHOULD use "simplex" URI scheme). This message is encrypted using key passed in the connection link (or with the derived shared secret, in which case public key for key derivation should be sent in clear text).
|
||||
6. Alice confirms and continues the connection:
|
||||
7. Alice confirms and continues the connection:
|
||||
- Agent A receives the SMP confirmation containing Bob's key, reply queue and info as SMP router `MSG`.
|
||||
- Agent A notifies Alice sending `CONF` notification with Bob's info.
|
||||
- Alice allows connection to continue with agent `allowConnection` api function.
|
||||
- Agent A secures the queue with SMP router `KEY` command.
|
||||
- Agent A sends SMP confirmation with ephemeral sender key, ephemeral public encryption key and profile (but without reply queue).
|
||||
7. Agent B confirms the connection:
|
||||
8. Agent B confirms the connection:
|
||||
- receives the confirmation.
|
||||
- sends the notification `INFO` with Alice's information to Bob.
|
||||
- secures SMP queue that it sent to Alice in the first confirmation with SMP `KEY` command .
|
||||
- sends `HELLO` message via SMP `SEND` command. This confirms that the reply queue is secured and also validates that Agent A secured the first SMP queue
|
||||
8. Agent A notifies Alice.
|
||||
9. Agent A notifies Alice.
|
||||
- receives `HELLO` message from Agent B.
|
||||
- sends `HELLO` message to Agent B via SMP `SEND` command.
|
||||
- sends `CON` notification to Alice, confirming that the connection is established.
|
||||
9. Agent B notifies Bob.
|
||||
10. Agent B notifies Bob.
|
||||
- Once Agent B receives `HELLO` from Agent A, it sends to Bob `CON` notification as well.
|
||||
|
||||
At this point the duplex connection between Alice and Bob is established, they can use `SEND` command to send messages. The diagram also shows how the connection status changes for both parties, where the first part is the status of the SMP queue to receive messages, and the second part - the status of the queue to send messages.
|
||||
@@ -119,7 +119,7 @@ The most communication happens between the agents and routers, from the point of
|
||||
1. Alice requests a new connection with `createConnection` agent API function and receives the connection link.
|
||||
2. Alice passes connection link out-of-band to Bob.
|
||||
3. Bob accepts the connection with `joinConnection` agent API function with the connection link to his agent.
|
||||
4. Alice accepts the connection with `ACPT` agent API function.
|
||||
4. Alice accepts the connection with `allowConnection` agent API function.
|
||||
5. Both parties receive `CON` notification once duplex connection is established.
|
||||
|
||||
Clients SHOULD support establishing duplex connection asynchronously (when parties are intermittently offline) by persisting intermediate states and resuming SMP queue subscriptions.
|
||||
@@ -382,9 +382,9 @@ Connection links are generated by SMP agent in response to `createConnection` ap
|
||||
```
|
||||
connectionLink = connectionScheme "/" connLinkType "#/?v=" versionRange "&smp=" smpQueues ["&e2e=" e2eEncryption] ["&data=" clientData]
|
||||
connLinkType = %s"invitation" / %s"contact"
|
||||
connectionScheme = (%s"https://" clientAppServer) | %s"simplex:"
|
||||
connectionScheme = (%s"https://" clientAppServer) / %s"simplex:"
|
||||
clientAppServer = hostname [ ":" port ]
|
||||
; client app router, e.g. simplex.chat
|
||||
; client app server, e.g. simplex.chat
|
||||
versionRange = 1*DIGIT / 1*DIGIT "-" 1*DIGIT ; agent version range
|
||||
e2eEncryption = <e2e encryption parameters for double ratchet>
|
||||
smpQueues = smpQueue *(";" smpQueue) ; SMP queues for the connection (semicolon-separated)
|
||||
@@ -479,14 +479,14 @@ linkEntityId = shortString
|
||||
userData = invitationLinkData / contactLinkData
|
||||
invitationLinkData = %s"I" agentVersionRange userLinkData
|
||||
contactLinkData = %s"C" agentVersionRange userContactData
|
||||
userLinkData = *OCTET ; opaque application data (e.g., user profile)
|
||||
userLinkData = shortString / (%xFF largeString) ; opaque application data (e.g., user profile)
|
||||
userContactData = direct ownersList relaysList userLinkData
|
||||
direct = %s"T" / %s"F" ; whether direct connection via connReq is allowed
|
||||
ownersList = length *ownerAuth
|
||||
ownerAuth = shortString ; length-prefixed encoding of (ownerId ownerKey authOwnerSig)
|
||||
ownerId = shortString ; application-specific owner ID (e.g., MemberId)
|
||||
ownerKey = length x509encoded ; Ed25519 public key
|
||||
authOwnerSig = 64*64 OCTET ; Ed25519 signature of (ownerId || ownerKey) by previous owner
|
||||
authOwnerSig = length 64*64 OCTET ; Ed25519 signature of (ownerId || ownerKey) by previous owner
|
||||
relaysList = length *connShortLink ; alternative relay short links
|
||||
largeString = 2*2 OCTET *OCTET ; Word16 length prefix
|
||||
length = 1*1 OCTET
|
||||
@@ -537,7 +537,7 @@ The list of some of the API functions and events below is supported by the refer
|
||||
|
||||
The list of APIs below is not exhaustive and provided for information only. Please consult the source code for more information.
|
||||
|
||||
#### Create conection
|
||||
#### Create connection
|
||||
|
||||
`createConnection` api is used to create a connection - it returns the connection link that should be sent out-of-band to another protocol user (the joining party). It should be used by the client of the agent that initiates creating a duplex connection (the initiating party).
|
||||
|
||||
|
||||
+3
-5
@@ -71,11 +71,10 @@ def RatchetInitAlicePQ2HE(state, SK, bob_dh_public_key, shared_hka, shared_nhkb,
|
||||
// below added for post-quantum KEM
|
||||
state.PQRs = GENERATE_PQKEM()
|
||||
state.PQRr = bob_pq_kem_encapsulation_key
|
||||
state.PQRss = random // shared secret for KEM
|
||||
state.PQRct = PQKEM-ENC(state.PQRr, state.PQRss) // encapsulated additional shared secret
|
||||
state.PQRct, state.PQRss = PQKEM-ENC(state.PQRr) // encapsulate: generates shared secret and ciphertext
|
||||
// above added for KEM
|
||||
// the next line augments DH key agreement with PQ shared secret
|
||||
state.RK, state.CKs, state.NHKs = KDF_RK_HE(SK, DH(state.DHRs, state.DHRr) || state.PQRss)
|
||||
state.RK, state.CKs, state.NHKs = KDF_RK_HE(SK, DH(state.DHRs, state.DHRr) || state.PQRss)
|
||||
state.CKr = None
|
||||
state.Ns = 0
|
||||
state.Nr = 0
|
||||
@@ -176,8 +175,7 @@ def DHRatchetPQ2HE(state, header):
|
||||
state.DHRs = GENERATE_DH()
|
||||
// below is added for KEM
|
||||
state.PQRs = GENERATE_PQKEM() // generate new PQ key pair
|
||||
state.PQRss = random // shared secret for KEM
|
||||
state.PQRct = PQKEM-ENC(state.PQRr, state.PQRss) // encapsulated additional shared secret KEM #1
|
||||
state.PQRct, state.PQRss = PQKEM-ENC(state.PQRr) // encapsulate: generates shared secret and ciphertext KEM #1
|
||||
// above is added for KEM
|
||||
// use new shared secret with sending ratchet
|
||||
state.RK, state.CKs, state.NHKs = KDF_RK_HE(state.RK, DH(state.DHRs, state.DHRr) || state.PQRss)
|
||||
|
||||
@@ -118,9 +118,10 @@ The command syntax:
|
||||
newTokenCmd = %s"TNEW" SP newToken
|
||||
newToken = %s"T" deviceToken authPubKey clientDhPubKey
|
||||
deviceToken = pushProvider tokenString
|
||||
pushProvider = apnsDev / apnsProd / apnsNull
|
||||
pushProvider = apnsDev / apnsProd / apnsTest / apnsNull
|
||||
apnsDev = "AD" ; APNS token for development environment
|
||||
apnsProd = "AP" ; APNS token for production environment
|
||||
apnsTest = "AT" ; APNS token for test environment (mock server)
|
||||
apnsNull = "AN" ; token that does not trigger any notification delivery - used for router testing
|
||||
tokenString = shortString
|
||||
authPubKey = length x509encoded ; Ed25519 key used to verify clients commands
|
||||
@@ -226,10 +227,10 @@ The interval for periodic notifications is set in minutes, with the minimum of 2
|
||||
This command makes notification router subscribe to message notifications from SMP router and to deliver them to push provider:
|
||||
|
||||
```abnf
|
||||
newSubCmd = %s"SNEW" newSub
|
||||
newSub = %s "S" tokenId smpRouter notifierId notifierKey
|
||||
newSubCmd = %s"SNEW" SP newSub
|
||||
newSub = %s"S" tokenId smpRouter notifierId notifierKey
|
||||
tokenId = shortString ; returned in response to `TNEW` command
|
||||
smpRouter = smpRouter = hosts port fingerprint
|
||||
smpRouter = hosts port fingerprint
|
||||
hosts = length 1*host
|
||||
host = shortString
|
||||
port = shortString
|
||||
@@ -259,7 +260,7 @@ subStatusResp = %s"SUB" SP subStatus
|
||||
subStatus = %s"NEW" / %s"PENDING" / ; e.g., after SMP router disconnect/timeout while ntf router is retrying to connect
|
||||
%s"ACTIVE" / %s"INACTIVE" / %s"END" / ; if another router subscribed to notifications
|
||||
%s"AUTH" / %s"DELETED" / %s"SERVICE" / subErrStatus
|
||||
subErrStatus = %s"ERR" SP shortString
|
||||
subErrStatus = %s"ERR" SP *OCTET
|
||||
```
|
||||
|
||||
### Delete notification subscription
|
||||
|
||||
@@ -254,7 +254,7 @@ To create and start using a simplex queue Alice and Bob follow these steps:
|
||||
|
||||
3. Anybody can send the message to the queue with ID `SID` before it is secured (e.g. if communication is compromised), so it's a "race" to secure the queue. Optionally, in the client application, Alice may identify Bob using the information provided, but it is out of scope of SMP protocol.
|
||||
|
||||
5. Alice secures the queue `RID` with `"KEY"` command so only Bob can send messages to it (see [Secure queue command](#secure-queue-command)):
|
||||
5. Alice secures the queue `RID` with `"KEY"` command so only Bob can send messages to it (see [Secure queue by recipient](#secure-queue-by-recipient)):
|
||||
|
||||
1. She sends the `KEY` command with `RID` signed with "private" key `RK` to update the queue to only accept requests authorized by "private" key `SK` provided by Bob. This command contains unique "public" key `SK` previously generated by Bob.
|
||||
|
||||
@@ -581,7 +581,7 @@ Sending any of the commands in this section (other than `create`, that is sent w
|
||||
|
||||
This command is sent by the recipient to the SMP router to create a new queue.
|
||||
|
||||
Routers SHOULD support basic auth with this command, to allow only router owners and trusted users to create queues on the destiation routers.
|
||||
Routers SHOULD support basic auth with this command, to allow only router owners and trusted users to create queues on the destination routers.
|
||||
|
||||
The syntax is:
|
||||
|
||||
@@ -670,7 +670,7 @@ The count and idsHash allow the router to detect subscription drift. The router
|
||||
|
||||
#### Secure queue by recipient
|
||||
|
||||
This command is only used until v8 of SMP protocol. V9 uses [SKEY](#secure-queue-by-sender).
|
||||
This command was used before v9 of SMP protocol. V9+ uses [SKEY](#secure-queue-by-sender). KEY is still supported for backwards compatibility.
|
||||
|
||||
This command is sent by the recipient to the router to add sender's key to the queue:
|
||||
|
||||
@@ -859,11 +859,11 @@ The format of queue information is implementation specific, and is not part of t
|
||||
|
||||
### Sender commands
|
||||
|
||||
Currently SMP defines only one command that can be used by senders - `send` message. This command must be used with sender's ID, if recipient's ID is used the router must respond with `"ERR AUTH"` response (see [Error responses](#error-responses)).
|
||||
SMP defines two commands that can be used by senders - `sndSecure` and `send` message. These commands must be used with sender's ID, if recipient's ID is used the router must respond with `"ERR AUTH"` response (see [Error responses](#error-responses)).
|
||||
|
||||
#### Secure queue by sender
|
||||
|
||||
This command is used from v8 of SMP protocol. V8 and earlier uses [KEY](#secure-queue-by-recipient).
|
||||
This command is used from v9 of SMP protocol. V8 and earlier uses [KEY](#secure-queue-by-recipient).
|
||||
|
||||
This command is sent by the sender to the router to add sender's key to the queue:
|
||||
|
||||
@@ -1056,16 +1056,16 @@ Sequence diagram for sending the message and `SKEY` commands via SMP proxy:
|
||||
|
||||
2. The client encrypts the transmission (`SKEY` or `SEND`) to the destination router using the shared secret computed from per-command random key and router's session key and sends it to proxying router in `PFWD` command.
|
||||
|
||||
3. Proxy additionally encrypts the body to prevent correlation by ciphertext (in case TLS is compromised) and forwards it to proxy in `RFWD` command.
|
||||
3. Proxy additionally encrypts the body to prevent correlation by ciphertext (in case TLS is compromised) and forwards it to the destination router in `RFWD` command.
|
||||
|
||||
4. Proxy receives the double-encrypted response from the destination router, removes one encryption layer and forwards it to the client.
|
||||
|
||||
The diagram below shows the encryption layers for `PFWD`/`RFWD` commands and `RRES`/`PRES` responses:
|
||||
|
||||
- s2r - encryption between client and SMP relay, with relay key returned in relay handshake, with MITM by proxy mitigated by verifying the certificate fingerprint included in the relay address. This encryption prevents proxy router from observing commands and responses - proxy does not know how many different queues a connected client sends messages and commands to.
|
||||
- s2r - encryption between client and SMP router, with router key returned in router handshake, with MITM by proxy mitigated by verifying the certificate fingerprint included in the router address. This encryption prevents proxy router from observing commands and responses - proxy does not know how many different queues a connected client sends messages and commands to.
|
||||
- e2e - end-to-end encryption per SMP queue, with additional client encryption inside it.
|
||||
- p2r - additional encryption between proxy and SMP relay with the shared secret agreed in the handshake, to mitigate traffic correlation inside TLS.
|
||||
- r2c - additional encryption between SMP relay and client to prevent traffic correlation inside TLS.
|
||||
- p2r - additional encryption between proxy and SMP router with the shared secret agreed in the handshake, to mitigate traffic correlation inside TLS.
|
||||
- r2c - additional encryption between SMP router and client to prevent traffic correlation inside TLS.
|
||||
|
||||
```
|
||||
----------------- ----------------- -- TLS -- ----------------- -----------------
|
||||
@@ -1083,7 +1083,7 @@ SMP proxy is not another type of the router, it is a role that any SMP router ca
|
||||
|
||||
#### Request proxied session
|
||||
|
||||
The sender uses this command to request the session with the destination proxy.
|
||||
The sender uses this command to request the session with the destination router.
|
||||
|
||||
Routers SHOULD support basic auth with this command, to allow only router owners and trusted users to proxy commands to the destination routers.
|
||||
|
||||
@@ -1140,7 +1140,7 @@ proxyResponse = %s"PRES" SP <encrypted padded(forwardedResponse, 16226)>
|
||||
|
||||
Having received `PFWD` command from the client, the router should additionally encrypt it (without padding, as the received transmission is already encrypted by the client and padded to a fixed size) together with the correlation ID, sender command key, and protocol version, and forward it to the destination router as `RFWD` command:
|
||||
|
||||
Transmission forwarded to relay uses empty entity ID and its unique random correlation ID is used as a nonce to encrypt forwarded transmission. Correlation ID increased by 1 is used by the destination router as a nonce to encrypt responses.
|
||||
Transmission forwarded to destination router uses empty entity ID and its unique random correlation ID is used as a nonce to encrypt forwarded transmission. Correlation ID increased by 1 is used by the destination router as a nonce to encrypt responses.
|
||||
|
||||
```abnf
|
||||
relayCommand = %s"RFWD" SP <encrypted(forwardedTransmission)>
|
||||
@@ -1380,7 +1380,7 @@ deleted = %s"DELD"
|
||||
- crypto error (`CRYPTO`) - cryptographic operation failed.
|
||||
- message queue quota exceeded error (`QUOTA`) - too many messages were sent to the message queue. Further messages can only be sent after the recipient retrieves the messages.
|
||||
- store error (`STORE`) - router storage error with error message.
|
||||
- relay public key expired (`EXPIRED`) - relay public key has expired.
|
||||
- router public key expired (`EXPIRED`) - router public key has expired.
|
||||
- no message (`NO_MSG`) - no message available or message ID mismatch.
|
||||
- sent message is too large (> maxMessageLength) to be delivered (`LARGE_MSG`).
|
||||
- internal router error (`INTERNAL`).
|
||||
@@ -1429,7 +1429,7 @@ Both the recipient and the sender can use TCP or some other, possibly higher lev
|
||||
|
||||
The transport protocol should provide the following:
|
||||
|
||||
- server authentication (by matching router certificate hash with `routerIdentity`),
|
||||
- router authentication (by matching router certificate hash with `routerIdentity`),
|
||||
- forward secrecy (by encrypting the traffic using ephemeral keys agreed during transport handshake),
|
||||
- integrity (preventing data modification by the attacker without detection),
|
||||
- unique channel binding (`sessionIdentifier`) to include in the signed part of SMP transmissions.
|
||||
|
||||
+5
-7
@@ -135,7 +135,7 @@ The sending client combines addresses of all packets and other information into
|
||||
- list of packet descriptions; information for each packet:
|
||||
- private Ed25519 key to sign commands for file transfer router.
|
||||
- packet address (router host and packet ID).
|
||||
- packet sha512 digest.
|
||||
- packet sha256 digest.
|
||||
|
||||
To reduce the size of file description, packets are grouped by the router host.
|
||||
|
||||
@@ -176,14 +176,14 @@ It includes these fields:
|
||||
- `digest` - SHA512 hash of encrypted file, base64url encoded string.
|
||||
- `key` - symmetric encryption key to decrypt the file, base64url encoded string.
|
||||
- `nonce` - nonce to decrypt the file, base64url encoded string.
|
||||
- `packetSize` - default packet size, see `fileSize` syntax below.
|
||||
- `chunkSize` - default packet size, see `fileSize` syntax below.
|
||||
- `replicas` - the array of data packet replicas descriptions.
|
||||
- `redirect` - optional property for redirect information indicating that the file is itself a description to another file, allowing to use file description as a short URI.
|
||||
|
||||
Each replica description is an object with 2 fields:
|
||||
|
||||
- `packets` - and array of packet replica descriptions stored on one router.
|
||||
- `router` - [router address](#xftp-router-uri) where the packets can be downloaded from.
|
||||
- `chunks` - an array of packet replica descriptions stored on one server.
|
||||
- `server` - [router address](#xftp-router-uri) where the packets can be downloaded from.
|
||||
|
||||
Each router replica description is a string with this syntax:
|
||||
|
||||
@@ -234,7 +234,7 @@ File description URI syntax:
|
||||
|
||||
```abnf
|
||||
fileDescriptionURI = serviceScheme "/file" "#/?desc=" description [ "&data=" userData ]
|
||||
serviceScheme = (%s"https://" clientAppServer) | %s"simplex:"
|
||||
serviceScheme = (%s"https://" clientAppServer) / %s"simplex:"
|
||||
clientAppServer = hostname [ ":" port ]
|
||||
; client app server, e.g. simplex.chat
|
||||
description = <URI-escaped YAML file description>
|
||||
@@ -415,8 +415,6 @@ ping = %s"PING"
|
||||
|
||||
This command is always sent unsigned.
|
||||
|
||||
data FileResponse = ... | FRPong | ...
|
||||
|
||||
```abnf
|
||||
pong = %s"PONG"
|
||||
```
|
||||
|
||||
+10
-16
@@ -10,7 +10,7 @@ Version 1, 2024-06-22
|
||||
- [Session invitation](#session-invitation)
|
||||
- [Establishing TLS connection](#establishing-tls-connection)
|
||||
- [Session verification and protocol negotiation](#session-verification-and-protocol-negotiation)
|
||||
- [Controller/host session operation](#сontrollerhost-session-operation)
|
||||
- [Controller/host session operation](#controllerhost-session-operation)
|
||||
- [Key agreement for announcement packet and for session](#key-agreement-for-announcement-packet-and-for-session)
|
||||
- [Threat model](#threat-model)
|
||||
|
||||
@@ -104,12 +104,11 @@ Multicast session announcement is a binary encoded packet with this syntax:
|
||||
```abnf
|
||||
sessionAddressPacket = dhPubKey nonce encrypted(unpaddedSize sessionAddress packetPad)
|
||||
dhPubKey = length x509encoded ; same as announced
|
||||
nonce = length *OCTET
|
||||
nonce = 24*24 OCTET ; NaCl 192-bit nonce, no length prefix
|
||||
sessionAddress = largeLength sessionAddressUri ; as above
|
||||
length = 1*1 OCTET ; for binary data up to 255 bytes
|
||||
largeLength = 2*2 OCTET ; for binary data up to 65535 bytes
|
||||
packetPad = <pad packet size to 1450 bytes> ; possibly, we may need to move KEM agreement one step later,
|
||||
; with encapsulation key in HELLO block and KEM ciphertext in reply to HELLO.
|
||||
packetPad = <pad invitation content to 900 bytes before encryption>
|
||||
```
|
||||
|
||||
### Establishing TLS connection
|
||||
@@ -157,10 +156,7 @@ The controller decrypts (including the first session) and validates the received
|
||||
{
|
||||
"definitions": {
|
||||
"version": {
|
||||
"type": "string",
|
||||
"metadata": {
|
||||
"format": "[0-9]+"
|
||||
}
|
||||
"type": "uint16"
|
||||
},
|
||||
"base64url": {
|
||||
"type": "string",
|
||||
@@ -172,9 +168,7 @@ The controller decrypts (including the first session) and validates the received
|
||||
"properties": {
|
||||
"v": {"ref": "version"},
|
||||
"ca": {"ref": "base64url"},
|
||||
"kem": {"ref": "base64url"}
|
||||
},
|
||||
"optionalProperties": {
|
||||
"kem": {"ref": "base64url"},
|
||||
"app": {"properties": {}, "additionalProperties": true}
|
||||
},
|
||||
"additionalProperties": true
|
||||
@@ -206,7 +200,7 @@ JTD schema for the encrypted part of controller HELLO block `ctrlHelloJSON`:
|
||||
}
|
||||
```
|
||||
|
||||
Controller `hello` block and all subsequent protocol messages are encrypted with the chain keys derived from the hybrid key (see key exchange below) - that is why conntroller hello block does not include nonce. That provides forward secrecy within the XRCP session. Receiving this `hello` block allows host to compute the same hybrid keys and to derive the same chain keys.
|
||||
Controller `hello` block and all subsequent protocol messages are encrypted with the chain keys derived from the hybrid key (see key exchange below) - that is why controller hello block does not include nonce. That provides forward secrecy within the XRCP session. Receiving this `hello` block allows host to compute the same hybrid keys and to derive the same chain keys.
|
||||
|
||||
Once the controller replies HELLO to the valid host HELLO block, it should stop accepting new TCP connections.
|
||||
|
||||
@@ -261,7 +255,7 @@ kemCiphertext(1) = enc(kemSecret(1), kemEncKey(1))
|
||||
kemSecret(1) = dec(kemCiphertext(1), kemDecKey(1))
|
||||
|
||||
// multicast announcement for session n
|
||||
announcementSecret(n) = sha256(dhSecret(n'))
|
||||
announcementSecret(n) = dhSecret(n')
|
||||
dhSecret(n') = dh(hostHelloDhKey(n - 1), controllerDhKey(n))
|
||||
|
||||
// session n
|
||||
@@ -277,11 +271,11 @@ If controller fails to store the new host DH key after receiving HELLO block, th
|
||||
|
||||
To decrypt a multicast announcement, the host should try to decrypt it using the keys of all known (paired) remote controllers.
|
||||
|
||||
Once kemSecret is agreed for the session, it is used to derive two chain keys, to receive and to send messages:
|
||||
Once sessionSecret is agreed for the session, it is used to derive two chain keys, to receive and to send messages:
|
||||
|
||||
```
|
||||
host: sndKey, rcvKey = HKDF(kemSecret, "SimpleXSbChainInit", 64)
|
||||
controller: rcvKey, sndKey = HKDF(kemSecret, "SimpleXSbChainInit", 64)
|
||||
controller: sndKey, rcvKey = HKDF(sessionSecret, "SimpleXSbChainInit", 64)
|
||||
host: rcvKey, sndKey = HKDF(sessionSecret, "SimpleXSbChainInit", 64)
|
||||
```
|
||||
|
||||
where HKDF is based on SHA512, with empty salt.
|
||||
|
||||
@@ -613,7 +613,7 @@ data NewQueueReq = NewQueueReq
|
||||
data SubscriptionMode = SMSubscribe | SMOnlyCreate
|
||||
deriving (Eq, Show)
|
||||
|
||||
-- SenderId must be computed client-side as `sha3-256(corr_id)`, `corr_id` - a random transmission ID.
|
||||
-- SenderId must be computed client-side as the first 24 bytes of `sha3-384(corr_id)`, `corr_id` - a random transmission ID.
|
||||
-- The server must verify and reject it if it does not match (and in case of collision).
|
||||
-- This allows to include SenderId in FixedDataBytes in full connection request,
|
||||
-- and at the same time prevents the possibility of checking whether a queue with a known ID exists.
|
||||
|
||||
Reference in New Issue
Block a user