Add blip-0031, a protocol for mutual message exchange #31
Conversation
This adds a new crate, `mutual-message-exchange` which allows two parties to maintain a list of keys with which they want to exchange messages and exchange one message at the cost of an extra half-round-trip. This is anticipated for use in BOLT12, where extra data can be included in a BOLT12 `Invoice` which allows a mutually-trusting sender to include a message in the onion, while any non-mutually-trusting entities will not learn anything about the recipient (subject to the use of blinded paths). A full write-up of this protocol is available as [bLIP 31](lightning/blips#31).
| * [`u16`:`handshake_count`] | ||
| * [`48*handshake_count*byte`:`per_peer_handshake`] | ||
| * [`u16`:`repeated_data_len`] | ||
| * [`repeated_data_len*byte`:`repeated_data`] |
There was a problem hiding this comment.
Do you have an example on what state you'd store here? Does this generally need to be encrypted/authenticated by the initiator to themselves (even though at the bLIP level we don't want to constrain higher-level protocols)?
There was a problem hiding this comment.
In the LDK implementation we store (encrypted+authenticated) a random nonce from which we derive other per-message secrets (notably the initiator_n). This makes the sending side stateless, which is nice. Indeed we don't want to constraint the protocol itself to that.
|
|
||
| The message-sender: | ||
| * MUST ignore any bytes which are included after the end of `repeated_data`. | ||
| * SHOULD walk each `per_peer_handshake` and check whether it is decryptable using each `s_i` it |
There was a problem hiding this comment.
The message sender needs the initiator_n for that, right? How is it transmitted?
There was a problem hiding this comment.
No, maybe it wasn't clear, the per_peer_handshake is an encrypted copy of the initiator_n, using the ECDH as a key.
There was a problem hiding this comment.
Updated the "what is AEAD" bit in the spec.
| * MUST set `handshake_index` to the index of the `per_peer_handshake` they were able to decrypt | ||
| within the init bytes. | ||
| * MUST set `encrypted_nonce` to | ||
| `AEAD(messenger_n, H(s_i || initiator_n), PROTO_SALT ^ MASK_A, PROTO_AAD)` |
There was a problem hiding this comment.
Why do we need MASK_A and MASK_B?
There was a problem hiding this comment.
We dont, there's a handful of things here I don't think we need, but I prefer to have rather than try to concretely prove we dont need :)
There was a problem hiding this comment.
But can you share the reasoning behind why you added this in the first place? I'm curious as I don't obviously see it.
There was a problem hiding this comment.
Oh, just on principle I like the idea of every line of code which instantiates a given cipher to have a different salt. We're not reusing keys so its not actually required, but just on principle the point of a salt is to pass "what I'm doing with the output" in to the cipher, and that should be on a per-line-of-code basis.
This adds a new crate, `mutual-message-exchange` which allows two parties to maintain a list of keys with which they want to exchange messages and exchange one message at the cost of an extra half-round-trip. This is anticipated for use in BOLT12, where extra data can be included in a BOLT12 `Invoice` which allows a mutually-trusting sender to include a message in the onion, while any non-mutually-trusting entities will not learn anything about the recipient (subject to the use of blinded paths). A full write-up of this protocol is available as [bLIP 31](lightning/blips#31).
|
I'll need to spend some time implementing this to get used to it in more details, but concept ACK |
| * [`repeated_data_len*byte`:`repeated_data`] | ||
|
|
||
| The initiator: | ||
| * MUST set `handshake_count` to a number greater than its trusted peer set count, using round |
There was a problem hiding this comment.
Can u please explain how setting round value here help with not revealing the total count? or is it "random"?
There was a problem hiding this comment.
A "round value" specifically doesn't help, but what we want is if one node trusts 20 peers and another 19, both should send the same number of slots so that it looks the same.
| * [`48*byte`:`encrypted_nonce`] | ||
| * [`u16`:`repeated_data_len`] | ||
| * [`repeated_data_len*byte`:`repeated_data`] | ||
| * [`u16`:`message_length`] |
There was a problem hiding this comment.
May I ask why in the protocol level we save the length of a variable as well?
There was a problem hiding this comment.
It allows us to append arbitrary stuff at the end of the message later. Means the reader knows where to stop reading and where the next field starts.
This adds a new crate, `mutual-message-exchange` which allows two parties to maintain a list of keys with which they want to exchange messages and exchange one message at the cost of an extra half-round-trip. This is anticipated for use in BOLT12, where extra data can be included in a BOLT12 `Invoice` which allows a mutually-trusting sender to include a message in the onion, while any non-mutually-trusting entities will not learn anything about the recipient (subject to the use of blinded paths). A full write-up of this protocol is available as [bLIP 31](lightning/blips#31).
No description provided.