| @@ -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 | initiate a new key negotiation unless it wants it's previous session | ||||
| to be removed. | 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 | ### shared | ||||
| Both sides initalize: | 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. | 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 | Command Phase | ||||
| ------------- | ------------- | ||||