Browse Source

add the ecdhe definition, this has not been reviewed yet..

main
John-Mark Gurney 2 years ago
parent
commit
188e475c86
1 changed files with 80 additions and 0 deletions
  1. +80
    -0
      PROTOCOL.md

+ 80
- 0
PROTOCOL.md View File

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



Loading…
Cancel
Save