DeRec Message fields 3 and 4

[jorabin]

these are SHA-384 hashes of sender and receiver public key. The public key for signature or for encryption? For encryption, presumably.

A bit of clarification would be beneficial (in the form of writing it out like the following and showing how you'd do it using Java Standard Cryptography libraries, perhaps like https://github.com/jorabin/derec-tests/blob/master/src/main/java/com/thebuildingblocks/derec/crypto/CustomKeyTrans.java)

The responder doesn't know the initiator's public key at this stage. So can't do anything with the sender hash though can verify the receiver hash using their own public encryption key..

The initiator creates a Pair Request message, signs the message with their private signature key and encrypts the message using the responder's public encryption key.

The responder decrypts the message using their private encryption key but can't verify the sender's signature yet, as they don't have a sender signature public key.

The initiator's public keys (for encryption and signature) are both present in the pair message, so the the receiver can belatedly a) assess the SHA-384 hash they just received. b) assess the signature.

The responder then replies with a Pair Reply message. They sign with their private signature key and encrypt it with the initiator's public key.

The initiator decrypts the message with their encryption private key but can only assess the signature having deserialised the pair response message.

[lbaird]

The above comments (plus a few more words) are added to the protocol description in PR number 9 in the Protocol repo. Once that PR is merged, this issue can be closed.

[jorabin]

Needs further adjustment in view of agreements relating to https://github.com/derecalliance/protobufs/pull/14