| @@ -33,6 +33,11 @@ states. This is safe as it is assumed that the initiator will not | |||
| initiate a new key negotiation unless it wants it's previous session | |||
| to be removed. | |||
| The notation below has an implicite recv on the other side of each | |||
| message. It is left off for conciseness, but must be done and verified, | |||
| in the case of static data, like `reqreset`, before any of their | |||
| respective operations are done. | |||
| ### shared | |||
| Both sides initalize: | |||
| @@ -88,6 +93,81 @@ initiator to send any commands it needs to be "passed back". | |||
| At this point, the new key/session becomes active. | |||
| ### ecdhe | |||
| This is the ECDHE key exchange. This does an ephemeral key exchange | |||
| w/ a known static key. It follows a protocol similar to the KK | |||
| [handshake pattern](https://noiseprotocol.org/noise.html#interactive-handshake-patterns-fundamental) | |||
| of Noise. For reference, it is: | |||
| ``` | |||
| KK: | |||
| -> s | |||
| <- s | |||
| ... | |||
| -> e, es, ss | |||
| <- e, ee, se | |||
| ``` | |||
| It requires that both sides know the public key of the other side (and | |||
| obviously their own). | |||
| Both start out: | |||
| ``` | |||
| meta-AD('com.funkthat.lora.irrigation.ecdhe.v0.0.1') | |||
| key(<initiator pub key> || <responder pub key>) | |||
| ``` | |||
| This is done to both bind the session to this specific public key pair, | |||
| but to also hide the negotiation request. | |||
| The terminology used is the same as used in [Noise's Overview of | |||
| handshake state machine](https://noiseprotocol.org/noise.html#overview-of-handshake-state-machine). | |||
| Note: MixHash calls are unnecessary, as they are inherent in the | |||
| send_enc operations. | |||
| The initiator generates an ephemeral key, e. | |||
| initiator: | |||
| ``` | |||
| send_enc(e + 'reqreset') # ephemeral | |||
| send_mac(8) | |||
| key(DH(e, rs) + DH(s, rs)) | |||
| ``` | |||
| The respondent generates an ephemeral key, e. | |||
| respondent: | |||
| ``` | |||
| key(DH(s, re) + DH(s, rs)) | |||
| send_enc(e) # ephermal | |||
| send_mac(8) | |||
| key(DH(e, re) + DH(e, rs)) | |||
| ``` | |||
| initiator: | |||
| ``` | |||
| key(DH(e, re) + DH(s, re)) | |||
| send_enc('confirm') | |||
| send_mac(8) | |||
| ``` | |||
| respondent: | |||
| ``` | |||
| send_enc('confirmed') | |||
| send_mac(8) | |||
| ``` | |||
| It seems odd to respond to the confirm message, BUT, as using strobe | |||
| requires explicit hand off (similar to a token), in order for the | |||
| initiator to send any commands it needs to be "passed back". | |||
| It is easy to see that there are correct matching key operations on | |||
| each side, and as the key operation ratchets the state, a separate | |||
| ratchet operation is not needed as in the shared key state. | |||
| At this point, the new key/session becomes active. | |||
| Command Phase | |||
| ------------- | |||