RFC 56 - Secure Message Delivery

Discussion topic for RFC 56.

16 Likes

Very cool and I’m still absorbing the detail and will do so for quite a while I feel. Here’s some of my intial impressions


The title

Secure Message Delivery

I feel that for an RFC about ‘message delivery’ there’s essentially no info about routes or hops (ie the ‘delivery’). I don’t really know how messages traverse the network. That info probably belongs in the unpublished “reliable message delivery” rfc; maybe the purpose of this rfc would be clearer using a title of ‘Message Delivery Security’. It’s bikeshedding for sure but I was expecting to read about ‘message delivery’ when really it’s only about ‘security’ of that.

“Secure Message Delivery” + “Reliable Message Delivery” is (to my mind) a weaker pair of descriptions than “Message Delivery Security” and “Message Delivery Reliability”… it’s just my initial impression and I can definitely get used to the current naming.


Summary

I feel the summary describes the purpose (ie why) but does not summarise the basic operation or idea of the scheme (ie what). Some plain simple description of the mechanism would be handy. As in, what happens?

eg Sections use a common aggregate keypair (comprised of subkeypairs from all elders) to identify the section to other sections. As the section membership changes so too does the aggregate keypair, which is shared and updated for all other sections. The aggregate keypair can then be used to easily verify the integrity of messages between sections and prevent malicious messaging.


We assume sections prove themselves via the use of a BLS public key.

For those who haven’t heard of this (myself included), it’s Boneh–Lynn–Shacham. The ‘Properties’ section of the wiki page is relevant - Simple Threshold Signatures, Signature Aggregation.

Does anyone know of any particularly good sources for reading more about this algorithm?


A simple enhancement would be to include section health in an SectionProofBlock, this would take the form of a 32 bit integer to represent the age of the section Elders and an 8 bit integer to represent the number of nodes in a section.

This is very cool. I like the direction it’s going.

Is it right to assume ‘bigger numbers’ means ‘more healthy’ or is it more like ‘closer to this target’ means ‘more healthy’?


struct SectionProofBlock {
 key: BLS::PublicKey,
 sig: BLS::Signature
}

Have to say I really hate the use of block. I don’t hate on many things but I hate this. It’s a link (or change, or event). Not a block. There are probably many words that can be used but block seems wrong. If the struct encapsulated a whole bunch of links then sure call it a block (well, I think snapshot would be even better than block in that case) but this data object is simply not a block in any way shape or form. In my very strong opinion.

type SectionProofChain = Vec<SectionProofBlock>
vs
type SectionProofChain = Vec<SectionProofLink>

The first one is a blockchain the second is just a chain. And… SAFE is not a blockchain!!!

8 Likes

I found this post that seems pretty good. It mentions that the drawback of BLS is that verification is burdensome.

2 Likes

is an OK start,
https://eprint.iacr.org/2018/068.pdf (shnorr)
https://www.cc.gatech.edu/~aboldyre/papers/bold.pdf (gap diffie hellman scheme)
https://eprint.iacr.org/2018/483.pdf (bls scheme for smaller blockchains, but closely related to our case)
The threshold_crypto crate we will use does in fact use the gap diffie hellman method for threshold.

That does read better IMO. Yes the reliable delivery RFC will make this much more understandable, I pushed for this to be published with the reliable one coming on its heels. We actually did a pre-rfc for reliability before the pre-rfc for section validation (this one).

We can have a lot there, so health (how many nodes, average age of elders etc.), farmed safecoin, held safecoin etc. I suspect we will see some pretty neat things there that perhaps even allows seciton recovery from any takeover etc.

:smiley: :smiley: yip that is true, I am not as opposed ot block but yea it is a bit like info that is my peeve to your block peeve. They are both bad at communicating what the thing is.

7 Likes

I don’t know if you are talking about this specific use of the term here or its generalized use by Maidsafe in data chain or PARSEC.

Initially I tried to argue for a better term because I also think it is too vague (for example see here).

But now this is OK with me because in traditional blockchain based networks the same vague term is used to refer to a precise specific object (a set of validated transactions in their case). So, this term is commonly used in the field to refer to the basic component of the ledger of the network (the datachain in our case).

3 Likes

Final Comment Period

The Secure Message Delivery RFC will remain open for the next 10 days to allow any final comments to be made.

Thank you to all who have contributed! :slightly_smiling_face:

2 Likes

Simplicity as well as efficiency is essential to launching quickly and correctly.

Absolutely love this approach and that it is explicit.

Every time the set of Elders changes, a new set of BLS keypairs will be generated, which will be shares of a new section’s BLS::PublicKey . In order to maintain trust, this new public key will be signed using the old key shares, thus forming a signature that will be a part of the new SectionProofBlock alongside the new public key.

A changing set of elders could be that one leaves. How is the new key signed when that Elder’s key share is no longer available? Not all keys required I guess? (m of n)
So, if more than n-m Elders leave, what happens? How do remaining members of the section proceed from there?

Splitting seems like a worms can of edge cases with the above in mind. Although really far out on the edge.

1 Like

Yes, Parsec consensus (>2/3)

The numbers of Elders of a section must be constant. If one Elder leaves, immediately an adult is promoted to Elder (again Parsec consensus).

2 Likes

I wasn’t talking about one only, but n-m, i.e. just enough to disable the key signing.

The problem was this:

In order to maintain trust, this new public key will be signed using the old key shares

So the group changes very rapidly, and >(n-m) Elders are out for some reason. There is not enough Elders from the old key to sign the new. Effectively the progression is halted as far as I can see. So, back to the question:

The chain of proof has been broken as far as I can tell. The section could dissolve, but that doesn’t seem satisfying with regards to their data responsibilities etc. What more can they do?

1 Like

As far as I know there is no recovery for this particular case and a restart would be required. Perhaps in the future a solution will be proposed in the event that a single section loses consensus, although, that suddenly disappear more than a third of the elders, would lead to thinking that there is a global communications problem or that the section is being attacked.

2 Likes

Right now this is the case. We are just pushing here to get an early feature complete launch. We can do things here though with the section authorities i…e the 2 neighbors (or just 1) could use their chain, create new keys and Elders for that section. so the broken sections chain is then scrubbed and the chain is the 2 neighbors (or just one of them) and so on. We are not focusing on that just yet though as I think you are noticing (nice one).

the section auth now as it is allows us to recover more than this, but that is for after all the bits are in play, so we can all see the bigger picture.

5 Likes

Secure Message Delivery is now moving in to the implementation phase.

Progress can be tracked via this project board: Secure Message Delivery (SMD) · GitHub

12 Likes