|
|
@@ -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 |
|
|
|
------------- |
|
|
|
|
|
|
|