Dev Diary 02.11.2018

tags: #dark-crystal #mmt #coconutdeath #devdiary

First week resuming MMT and Dark Crystal related discussions and brainstorming, very excited to be moving on this again.

So my core focus over the last day, aside from dealing with a bit of administration for getting us moving as a group again. @peg and I took a deep dive into what 'Coconut Death' means, what the different scenarios are and how Dark Crystal can assist with the recovery of keys in the event of loss, theft or untimely demise. Here's some feedback from our shared notes.

Coconut Death

What is Coconut Death?

Backlinks:
%IFRnSTl... %yWguHqH... %yAdCqJq... %FxK4GdA...

Coconut Death has become analagous to a speculative future whereby one or more of the MMT crowd get catatrophically hit on the head by a coconut falling from a tree thereby rendering them inert / incapacitated and unable to participate in signing group wallet transactions. We supposed that in the event of a multisignature wallet requiring 4/5 signatures to validate a transaction,with two signatories incapacitated by the dreaded coconut death, the rest of the team would be unable to easily sign a transaction move funds out of the now 'unstable' wallet. This is one of the reasons Dark Crystal emerged as a concept. If each team member shards their wallet seed and sends it to the other members of the group, it opens up the possibility for one of the two coconut dead members' seed to be recovered (in effect transforming the multisig into a 3/5), thus freeing up the locked funds in the wallet to the rest of the team.

In the context of an SSB identity, #coconutdeath can be analagous to:

1. Losing your Private Key, Backup or Device (the coconut lands on your laptop, shattering the motherboard and rendering your SSB identity inaccessible)
2. Having your device stolen (after having been hit over the head with a coconut by some sinister character)
3. Complete incapacitation or death (a coconut plummets from space and lands directly on you creating a crater the size of a small tropical island)

Simulations

@peg and I conducted a roleplay experiment simulating the experience joining SSB as entirely new Scuttlebutt users, sharding our SSB identity using Dark Crystal, losing our computer, and reassembling.

Scenario 1 - Loss of Private Key / Loss of Device

1. Person 1 (Identity A) loses their key and can no longer access SSB
2. Person 2 (Identity B) has a shard for Identity A sent by Person 1 via Dark Crystal
3. Person 2's shard message indicates it is in fact a shard of A's identity (as opposed to a different shard for a different key...)
4. Person 1 tells Person 2 that they've lost Identity A via a different communication protocol
5. Person 1 generates Identity C, a throwaway identity, and gets connected to Identity B via a pub (or an invite code?).
6. Person 2 receives assurance that the new identity received, Identity C, is infact Person 1 a.k.a Identity A.
7. Person 2 opens Dark Crystal and chooses to Forward Shard, selects the shard in question and is shown a form whereby they can select from a set of identites or input an identity string to forward the shard to.
8. Person 2 submits Identity C to the form.
9. Dark Crystal creates a new record, either invite-reply or a new message type dark-crystal/forward and sends the shard of Identity A to Identity C
10. Person 1 acting as Identity C receives a message from Person 2 (Identity B) that contains their shard.

Thoughts:

Point 5:

• When Person 1 generates their 'recovery' identity, Identity C, whats the minimum possible they can do to get connected to Identity B?
• Is it possible to do something similar to manyverse whereby an individual generates an invite code and shares it with Person 2 out-of-band. This exists in manyverse but I don't know if this is possible due to static home IPs, etc. @andrestaltz can you perhaps shed some light on this?
• The other option is to join the same pub as Identity C.

Scenario 2 - Stolen Device

We didn't go to deep into this yet, suffice to say that I think its a similar scenario to 1, but we different action needs to be taken in terms of the interface to ensure the custodians behave correctly.

Scenario 3 - Coconut Death 4 Realz

• How do the shard holders know who each-other are?
• They all know about a root message id. Each shard holder can do a shout out of SHA2(root).
• Another shard holder can look around and assume that anyone who also shouts out a matching SHA2(root) has another piece of the puzzle, because they knew the root. Are there missing assumptions here? Can this be cheated? Sure someone can just copy that SHA hash and paste it into a message, thus fooling anyone else who is looking for that string.
• Any other ideas?

Summary
Much of my thoughts around this today are really UX related.

The Dark Crystal interface really needs to separate user-flows and its narrative based on the differing scenarios / recovery strategies. For example, suppose rather than the simple case where peg's laptop gets smashed up by a falling cococnut, instead a giant walking cococnut robbed peg of his laptop (sorry peg!) and his identity with it. Supposing also that Peg has backed up both his Bitcoin private key and his SSB private key using that identity. When he comes to want to recover, the options to 'Return a Shard' and 'Forward a Shard' should not be in the same view. They could be easily mixed up and could result in a dramatic failure - rather than forwarding the old private key to the new SSB identity, peg's custodian sends the shard of the bitcoin private key back to the Coconut Robber. If a quorum of other shard holders makes the same mistake, then the bitcoin private key is revealed to the Robber.

The Dark Crystal interface doesn't at the moment allow a person to return a shard unless requested. But if the coconut robber has requested the bitcoin key shard back, it could easily be confused for forwarding the SSB key shard to a different identity. The interface really has to get a proper handle on this.

There's nothing about the interface at the moment that indicates precisely which shard the custodian should return. There needs to be somekind of metadata to indicate whether the identity is their SSB private key at the very least (which in effect acts as a master key to regain access to the other secret shards).

Conclusion

A scenario-based user-path as the interface is the better path. For example:

Dark Crystal app loads up and asks what what course of action you want to take.

1. Create a New Dark Crystal, Shard your secret and share it with some friends
2. A friend's lost their key? Send a secret shard back to its original owner
3. A friend's lost their SSB identity or had their laptop stolen? Forward a secret shard to another identity

With pictures animating the process and text explanation we can ensure that people know exactly what they're doing and which is the correct option / scenario to choose. Lets treat this as an opportunity to teach people about how it works and narrate that through imagery. We can do the same on initial sync when scuttling after having joined a pub. Much like how Ubuntu or Windows shows pictures when you're installing the OS. Dark Crystal can show a series of images explaining the different scenarios. Much like how MyEtherWallet warns about security and how to use the wallet when you land on their homepage.

Observations for Development

• Encrypt the gossip.json file with your ssb private key before sharding. Attach as a blob to the dark-crystal/shard message. Forward the gossip.json file when shard is returned to new identity. Once all shards are received, decrypt the gossip.json, inject into the incoming new .ssb folder with the new / old secret file, and switch identities. Wait for resync.
• We might want a new record (or could perhaps use invite-reply messages) called dark-crystal/forward that looks something like this:

{ 
  key: "%...",
  value: {
    content: {
      type: "dark-crystal/forward",
      root: "%...",
      shard: "*=.box", // encrypt the shard sent back using the destination identity's public key (much like the same pattern we've already used)
      gossip: "&...", // blobId of gossip.json file
    }
  }
}

• Write a flumeview-reduce that listens for dark-crystal/forward messages. When one arrives, query for other dark-crystal/forward messages that have arrived, and using them attempt to reveal the secret. If the secret reveals successfully (we've essentially calculated the quorum), append to the reducer a record that contains a list of the IDs of the dark-crystal/forward messages, and the quorum required to reassemble. In the front-end, we have have a pull-stream setup which will check this reducer and allow the secret to be revealed if the relevant information is available to reveal. This could also expose a set of actions to perform:
  1. Delete current identity and rebuild original identity
  2. Backup current identity and rebuild original identity

I hope this makes some sense, its a cut and paste job with some linking paragraphs from the last 2 days notes

In unrelated news... it turns out there's an Irish Porter called 'Death By Coconut'. I think the #mmt team should celebrate on the delivery of resolving the coconut death scenario this with a 4-pack each.

This is an excellent write up. Will come back with thoughts. From first pass I am in broad agreement.

Aside

Check this out!

Coconut: Threshold Issuance Selective Disclosure Credentials with Applications to Distributed Ledgers

darkcrystal.pw advisors George, Lola and @Dave Hrycyszyn are all part of that team! chainspace

@SHIBA COMPUTER this is the current focus of Dark Crystal which I was speaking with you about.

Thinking through the Community and Peer Experience of collaborative account recovery is very much in the field of.... what's the opposite of 'Weaponised Desgin'? Consentful Design?

what's the opposite of 'Weaponised Desgin'? Consentful Design?

'Design'

ooooh, that's a nice idea. yeah I really like that @kieran @peg (shouting the hash of the root)

so many good ideas here... what a fun space to be playing with.
I reckon it would be good to discuss these plans with some security crypto sorcerers too to just quick check we're not doing anything stupid before we start casting spells

yeah maybe we can experiment with a version which has the other custodians included and see how that feels....

i love this thread :)

i'd say we follow our past patterns and design the happy path first.

i'd say our next targets should be to emulate the patterns outlined in Cryptoasset Inheritance Planning: A Simple Guide for Owners. Doing so will give us a widely applicable and useful base :)

Within ssb i'd say @keks , @arj and @cryptix have been super insightful so far WRT to crypto sense checking.

We're also skipping a beat or step in gaining initial consent - that additional step also opens pause for weaving in the human protocol of what's to be done in different scenarios and what exactly is it that people are agreeing to when they do.

Again, I feel this is exactly the consentful design which @SHIBA COMPUTER recently advocated for in their talk at #radnet .

Lastly - this is super exciting!

I like your proposal @peg of a simple version of fwd'ing to start with. Here are the parts I read that I think could be trello cards :

• new schema : dark-crystal/forward + tests
• scuttle methods : forward.async.build (or maybe response.async.buildForward) and forward.async.publish (this pattern of seperating building and publishing is something I did in gatherings that I really liked, would like to check if it suits here.
• patchbay-dark-crystal : coherent design which helps user understand different 'parts'
  • sharing my things
  • supporting my friends
  • requesting my shards from another account ... OR being an executor for a dead friends estate and finding other custodians.
  • only when we've done this design work can we create cards for what the patchbay work really is

I'd prefer to loop back to the initial consent, because my experience has been that my friends are fine receiving shards? When it comes time to check that more thoroughly, I think we should prototype initial consent by doing it manually with a private message. e.g. Dan decides to shard something, and composes an PM to 5 people on ssb, with a fake checkbox:

• I understand and consent
• No thanks
  Then he does a normal sharding (or not) based on that, and then we interview the recipients to see how they felt about it (keeping in mind there might be an additional step to poke them to see the message if it doesn't fall in their default private messages readed)

@peg the initial consent thing is definately something we shouldnt overlook. Just a shame that it will introduce and second round of waiting to hear back from people - and make using it not feel as quick and easy as it does now. (thats not to say its not important...)

At the very least we should be putting a warning/reminder in the interim saying - make sure you get consent from the shard holders before giving them a responsibility they have not asked for.

Warnings on Dark Crystal

So I started putting our more concrete ideas as cards on trello, and this got me thinking what exactly we will need to do. and its made me a bit concerned with our model.

Thanks for digging in @peg :)

Without knowing what the quorum is, our test for having enough forwarded shards returned to recover the secret relies on identifying the secret somehow. This means we will be able to recover SSB keys, since we can look for a string ending in .ed25519 or a parsable bit of JSON containing one.

With you so far. I think.

I'd say in the first case we're going for the most simple. Alice has backed up her ssb key with a group of people and she can remember who those people were for that secret and she can also remember the quorum.

But, just to be safe she rings all of the people involved in the coven and chats with them and gets them to send all shards which she has ever sent them.

Luckily we have computers to help us, so there will be alot of combinations of shards, but not anything which a computer will find too taxing with the number of people involved and the number of shards involved.

Is that the scenario you are thinking of peg?

But we will only be able to recover secrets which we can identify somehow. If someone wants to recover a secret other than their SSB key, they would either have to tell dark crystal what they think the quorum was, or sift through failed attempts at recombining. If the quorum was 5, they would need to check 4 potential secrets. Which wouldn't be so bad, but it would make the interface a bit ugly and confusing.

Hmmm. Couldn't we absorb some of the mess behind the interface as we attempt recombines till something works.

And again - I'd suggest in the happy path we leave some of this complexity to the human as a first step.

I think it's ok for us to assume that people will remember the shape and appearance of the secret that they have dumped into the crystal.

You might say - well that's no problem, recover your SSB key and then use your old identity to recover your other secrets. But what if (a) you didn't backup your SSB key. or (b) your SSB identity was compromised and you definitely do not want to use it to recover your secrets.

I think in this first case we are designing for (a). It is good to look ahead though to make sure we don't paint ourselves into a corner.

This does open to another common suite of thangs - which is that Alice will now have two identities. What should we do about that in the Happy Path sense?

I know that some other implementations of shamirs secret sharing get around this problem by appending the secret with it's hash or a checksum before sharding. In fact you could use anything, a few bytes of zeros, or the word 'scuttlebutt' UTF-8 encoded.

hash or checksum is good.

I know that this will make the shards even bigger and we are already struggling to fit them into an SSB message. and I know this would be a breaking change and mean bumping the schema version number. But i have the feeling we will thank ourselves later for doing this sooner rather than later.

agreed it is better to make breaking changes sooner rather than later. i'd also say this is an excellent opportunity to try out the version pattern, which has not been tested yet. and good to do it when the stakes are lower. I'd even go so far as to advocate for this as we want to surface these types of issues sooner rather than later.

I'm willing to say - ok, lets not worry about this now, and go for MVP for SSB identity recovery. But i think this is really something we'll want to address before the next major 'release'. Unless anyone can think of an easier way around this problem?

I think what you have written makes sense.

@dan hassan was there any mention of this in the SLIP39 specs? At first glance it does not look like there is, but i've not had a deep dive.

I've not had a deep dive yet.

ps. this is about identifying the original secret not about verifying individual shards. Which is another problem...

I can't recall the exact solution to this, but I had thought that we solve this for "free" as a side effect of ssb append logs... I could be wrong though.

@peg @dan-hassan any encrypted format ought to have a mac (message authentication code) such that you can know unequivocally whether the decryption was successful or not. Depending on some structure of the plaintext to know that the decryption is successful is not really good enough - then the layers are bleeding together, really we want the security properties to be verifyable without considering what type of secret you are splitting.

What I'd probably recommend is encrypting the actual secret using libsodium's secretbox method and a random key, and then splitting key (a 32 byte random number) using SSS.

How do you identify the split secret? like, you say here is a shard of X, please return your shard of X. What is the format of X?

I would be happy to review the way you are assembling the cryptographic stuff, if you can direct me to the sections of code where that is handled.

@peg please don't use sha1 - sha1 is no longer considered secure. Now, the problem with sha1 may or may not cause a problem in dark-crystal, that may or may not get even worse. Better just not to use it, then we don't need to spend mental effort wondering if we are vulnerable to sha1's problems.

I'll have a look around, and see what I come up with (will put that in another thread though)

cc: #dev-diaries

Seeing as we're drawing i'd like to pop the OG's that @alanna drew here :) Just for fun :)

Use case: I have a secret I want to back up by sharing shards with my friends (eg. SSB ID)

Use case: we are a group who all have secrets to back up with each other (eg. multi-sig crypto wallet)

I have a feeling there's a way to further simplify these processes and combine them in a way where one is a special case of the other, but I haven't got there yet.

back-cypher-link: %n44ycT+...

we've come a ways y'all!

@peg just use sha256 - since that is provided by the crypto library we use (libsodium) so it doesn't add any new code, and then just truncate the hash to say 16 bytes. That's plenty for this - libsodium's macs on secretbox are also only 16 bytes.

%I/fhmRe...

@kieran "The Dark Crystal interface doesn't at the moment allow a person to return a shard unless requested. But if the coconut robber has requested the bitcoin key shard back, it could easily be confused for forwarding the SSB key shard to a different identity. The interface really has to get a proper handle on this."

This is interesting. This is another consent/warning/power tools thing we need to think about in the flows. When you see that a friend has requested their shard back we should have a confirmation box which says "Have you checked with your friend on another protocol that it is really them requesting the shard and that their computer hasn't been stolen. Check with your friend!"

%I/fhmRe...

@kieran "There's nothing about the interface at the moment that indicates precisely which shard the custodian should return. There needs to be somekind of metadata to indicate whether the identity is their SSB private key at the very least (which in effect acts as a master key to regain access to the other secret shards)."

I have proposed here an alternate strategy where we return ALL shards of a person. This way we don't need to attach metadata :) We can trust that human brains remember their relationships.

e.g.

I can't remember who I selected, but I can go and look at the old id, see who I was friends with and then make a guess about who it was that I elected for this important job.

If we are making Dark Crystal internally do lots of guessing with all the different incoming shards from the potential shard holders then it is cheap for people to just guess at all the likely candidates.

I am not sure in terms of Security on the Humyn Layer if this is a TERRIBLE IDEA or not. It means a robber could in the click of a button request ALL SHARDS from ALL SHARDHOLDERS. If people don't follow the advice and check in with their friends when they are requesting - could this lead to chaos?

TL;DR We have to think about how the interfaces we build and the assumptions and capabilities we bake into the interfaces will be abused (because they will be if they can be). We should always be interrogating things so that we can find the path with least potential for harm.

things people getting a shard need to know:

• whether they have successfully recombined (use MAC)
• which shards are to be collected for which secret
  • this could get kinda out of hand ...
  • we should do some simple combinations numbers on this to see how bad it gets
• knowing which algorithm to use?!
  • which module - secrets.grempe / secrets.js ... ?
  • we could brute force it with all the different libs we use over time ):

"combinations" and "permutations" are ways of calculating how many different ways there are of doing a thing.
e.g. for pick 4 shards out of 15 and try to combine them (whether the order doesn't matter) the calculations is :

n! / ( k! * (n - k)! ) = 15! / ( 4! * 11! ) = 1356

anyway, we don't need to do this because all the shards have a root attached to them, so as long as that's in the forward message (which the schemas you made say it is) then we don't need to guess which shards go with which.... so it's just a matter of using all the shards you have then checking some MAC to see if you had a quorum

@peg i suggest we bump the schema version number every time we change the way shards are built, so that we know how to treat them regardless of whether we have the 'ritual' message.

Agreed. Since we've now got a versioning system for the schemas, lets use it.

agree - I came to the same conclusion !
I think we should also deprecate the tools property as well in the ritual schema because that will make it 100% clear that version is the way to determine the tool

@peg yes but very minor niggle: I'd avoid things like slice(-16) (which I can only presume measures from the end backwards) and instead do slice(0, 16) because it's more explicit. explicit is better than implicit. of course, we know that sha256 returns 32 bytes, so this is the same... actually does that return the first or last 16 bytes?