The advantage of using digital communication over analog is that it's much easier to implement decent security measures.  Security deals with the following properties of the information:

• secrecy or confidentiality
• authentication
• non-repudiation
• integrity control

We won't reinvent the warm water here.  We'll see what TLS1.3 and SSH have to offer us. 

Key exchange

TLS leaves many options here, some of which are interesting to us: PSK and ECDHE and a combination of the two.  In pre-shared key (PSK) mode, a pre-shared secret is established prior to key-exchange.  This can be done using an out-of-band secure channel : serial cable, NFC, ...  The problem with this approach is that it doesn't scale well.  The pre-shared secret should be unique for each combination of two devices.  If you have 20 devices, you'll end up generating and distributing 20!/(2!*18!) = 190 unique pre-shared secrets.

ECDHE (Elliptic Curve Diffie Hellman with Ephemeral keys) is easier to manage.  Each device in the group could be uploaded with a list of "certificates".  This list could be store on an SD-card in the device.  The list would be the same for all devices in the pool and it doesn't even need to be secret.  WiFi could be used to upload the list to the devices.

Message 1 : Client to server

TLS1.3 as well as SSH start with the client that creates an ephemeral key pair.  It then sends a random number (to prevent replay-attacks) and the ephemeral public key to the server. 

The ephemeral key pair is only used for key exchange.  Its lifetime is very short. 

SSH

In SSH this actually takes two different messages.

• Random number = cookie, 16bytes long
• Ephemeral public key = e (in SSH_MSG_KEXDH_INIT message)

TLS1.3

ClientHello message

• Random : client_nonce = 32bytes
• Extension : key_share : client's ephemeral public key

Message 2 : Server to Client

The server creates an ephemeral key pair  as well.  For both protocols, the server's first message contains about the same arguments as the client's first message.  The server then adds additional data.

SSH

• Random number = cookie, 16bytes long
• Ephemeral public key = f (in SSH_MSG_KEXDH_REPLY message)

Additional data:

• the server's static public key K_S
• signature: signing the hash of all known key exchange data up to now and signing it with K_S.

TLS1.3

ServerHello message:

1. Random : server_nonce = 32 bytes
2. Extension: key_share : server's ephemeral public key

Additional data: EncryptedExtension, encrypted with keys derived from handshake secret.

• Certificate
• CertificateVerify : provides authentication.
  
• Finished : provides key confirmation and binds the authenticated party to the used key.

Mutual authentication

As shown above, the key exchange only provides server authentication.  The server has no way of telling who the client really is.  Implementation of mutual authentication in TLS1.3, simply requires an extra message, with the client sending similar EncryptedExtension data.

Mutual authentication in SSH requires the SSH authentication protocol (RFC4252), which is a different message flow.  In short, the client sends its public key and attaches a signature to prove possession of the private key.

Implementation

As the Arduino tool chain for ESP32 already includes libsodium, we'll use that.  Monocypher can't be used with ESP32 because of linker conflicts with the libsodium library.