2.0 KiB
Protocol
The responder will be the node under control (irrigation controler), and the initiator will be the server.
The responder will always respond with one and only one packet. That is, all timeout mechanisms will be handled by the initiator. If the initiator does not receive a response to it’s query, it will resend the request until it does. It is required that the responder be able to detect this, and resend the last response.
both sides: meta-AD(‘com.funkthat.lora.irrigation..v0.0.1’) key()
The following exchange is required by protocols that are not PFS safe, that is shared and ecdh (defined below). This is to prevent replay attacks and ensure that both sides have integrated random data into the protocol, AND that the connection reset was requested by the initiator. This is described in the second paragraph of § C.2 in the strobe paper.
initiator: send_enc(<16 bytes random data> + ‘reqreset’) # nonce injection send_mac(8)
respondant: send_enc(<16 bytes random data>) # nonce injection send_mac(8)
initiator: send_enc(‘confirm’) send_mac(8)
respondant: 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”.
The new key/session does not become active till this point.
In order to handle a reset and prevent a replay attack, the existing session, if any is maintained till the completion of a reset request. Only after that, does the old conenction key get removed. This does mean that after a reset request, it is required that both sides attempt to decode each packet w/ both keys.
Where type is to be: shared - shared secret: key = common set of bytes, should be min 16 bytes. ecdh - Results of an ECDH exchange, key = K || K_A || K_B ecdhe - Results of an ECDHE exchange, key = TBD
Note: look at: https://monocypher.org/manual/advanced/elligator when doing ECDHE