minimal coconut

In figuring our the minimal scenarios we want to cover I want to reason about whats non-negotiable and what's nice to have (and that we could perhaps design and build for later).

I'm gonna give the excellently described scenarios here shorter names so I can talk more easily

1. swim - as in your laptop went for a swim (nee loss of device / private key)
2. theft - a bad actor has access to your private key (nee stolen device)
3. inheritance - I am totally gone, it's up to those I've left things to (nee coconut death for realz)

proposal: solve for theft

Here's a breakdown of why I think that's the case.

If we are missing our laptop, then the safe thing to do is assume the theft case (and that your identity is comprimised).

There are 2 ways you could recover your crystals if theft has happened:

• a) recover your ssb key, then request your shards
• b) ask for your shards to be forwarded to a new identity

Option (a) is not a useful option because even if you recover your scuttlebutt identity, requesting your shards back is dangerous (if you don't fork your feed in doing it, then you'll be giving your crystals to a bad actor). (crystal is synonomous with the fixed crystal made up of all the shards, i.e. some backed up secret)

So, I think we need to focus exclusively on shard fwd'ing. (and not at all one recovering a scuttlebutt identity for our purposes)

I think we can leave the inheritence case, because I feel the solution is going to be fairly similar to the theft case (fwding shards) ... and I think we can extend to that nicely. In contrast the swim solution (resurect the identity) could be extended to solve inheritence, but would give your inheritor access to everything private you've said (this is something awkward pointed out in the Crypto Inheritence guide which I think we should just avoid)

cc @peg @kieran (dan liked already)

@peg my understanding is that @mix is proposing we focus on retreival of a specific crystal, such as a BTC wallet or other important crystal.

He is also proposing that we focus on the theft situation - where we have to abandon the old identity.

I also agree that this is a Path through the reeds which can give us focus right now :)

tags: #darkcrystal #mmt #coconutdeath

I've not thought much about the interface yet @peg.
I think I'm suggesting with the swim case a person can recover there crystals just fine with fwd'ing. If one of those happens to be an ssb secret then they can mess around with that, but we're not going to touch that because it's a less secure option, and also requires more messing around

My feeling is swim and theft are both close enough in behaviour that we should focus on them. I agree that inheritance is beyond scope at the moment. @peg is correct in that the forward capacity allows for all three cases. I made the case for the different pathways in my interface posts yesterday.

%XwpDpMc...

%YPkZMHo...

I think the UI dictates how the cases are handled, since the forward mesage types can be used in all 3 scenarios. I can see your point @mix as to why to focus on theft but I also think that the swim case can be dealt with in pretty much the same manner, except we can do extra things at the end (like switch identity, which yes may be a big nice-to-have rather than a needed).

If one of those happens to be an ssb secret then they can mess around with that, but we're not going to touch that because it's a less secure option, and also requires more messing around

@mix I'm not sure I get the reasoning, why is it a less secure option?

ask for your shards to be forwarded to a new identity

The thought just occurred to me. When we forward a shard to an identity, there is still nothing stopping them sending the shards to the original identity. It might be useful to lock off in the UI any shards that have been sent that also have a corresponding forward message. Actually here we have another difference between swim and theft, because if we recover in swim, the old identity is still secured and they might not want to have those shards locked off. Whereas in theft you most certainly no longer trust the old identity, so you want to stop people from being able to send the shard back to the old identity.

@jasongreen

Does focusing on the theft scenario narrow to some degree the whole focus of dark-crystal from generalized secret sharing to the more specific function of sharing ssb identity secrets? This whole question of deprecating an identity applies to ssb secrets, but not to other secrets you might use dark-crystal to shard out.

It does to a degree. I think in order to deal with theft properly, we either think about a trust declaration system or we forward all shards (I think @dan this is what you were saying here?).

With a trust declaration approach, Alice says to @bob that @alice is no longer Alice, Alice is in fact @newalice. @bob verifies with Alice out-of-band that Alice and @newalice are actually the same person, then @bob declares to others that @alice is not Alice, Alice is actually @newalice. The other shard custodians do the same, creating a consensus within Alice's trusted circle that @alice is in fact a thief, meaning those custodians will no longer send back shards to @alice (and the UI can disable this completely). This is particularly relevant in the case of say cryptocurrency private keys. For example, @newalice has recovered her SSB identity from @bob + 2 other custodians. But hasn't recovered the shards for other secrets. @newalice might want to reevaluate, get all those shards sent back at once, move funds out of all wallets into new addresses (i.e. generate new keys) and create a new dark crystal for each. Or @newalice can declare to her trusted peers just not to send @alice any shards. Both are an approach. The Forward All is the safer option IMO. Perhaps thats what we should think about now. Perhaps later we can think about a trust declaration system.

@Eb4890 more thoughts on trust declaration ^^

SCOPE CREEP ALERT. Stopping my brain in its tracks.

I think the MVP is to fwd all shards.
I do want to make tools which make that safer and easier to not mess up ..

@mix I'm not sure I get the reasoning, why is it a less secure option?

@kieran I guess there are security pitfalls in all directions. I think the sending things back to an original identity in the event it's lost is less secure because you don't necessarily know if it's been comprimised (now or at some time in the future).

@Eb4890's ssb-trust looks interesting. It seems like it's more a permissioning system which is a little different to tombstone but perhaps it could be used to name the people you trust to declare tombstones on you if you're not present to do it yourself (or your new identity is still being verified). Could also be used to say who has authority to declare a valid reincarnation (a message type which declares a successor account?!)

I'd like to name a 4th path

0. happy <<<<
1. swim
2. theft
3. inheritence

It's the one we already built - where you have your device, and you're you and just backing up and recovering.

Ok wow I wrote out the paths I can think about.
I've grouped by meta-scenario and then by actors and mini-scenarios within that. I notice that marking accounts (in the theft meta-scenario) will likely introduce new paths we want for the 'happy' path

0. happy path

Protagonist

have secret
  └─> shards secret 
      └─> ... recovers secret (v1 done)

Custodian

receive a shard
  ├─> gets gets request to return shard
  │   └─> returns shard (v1 done)
  └─> returns shard

1. swim

see (2) for now

2. theft

Protagonist

laptop goes missing
  ├─> asks friends to "tombstone" old account (optional)
  └─> makes a new account
      ├─> attests new account is "reincarnation" of original
      └─> requests all shards fwdd
          └─> recovers secrets 
              └─> updates secrets, creates new shards (happy path again)

Attester

protagonist contacts you out of band about stolen laptop
  ├─> you mark their account as "stolen"
  └─> you define a "reincarnation" (pointing from read account to the reborn)

you see supicious activity from the protaginists account
  └─> you mark their account as "suspicious: stolen"

someone tries to trick you into thinking the Protaginist account has been stolen
  ├─> you mark the account as "still valid"
  └─> you mark the trickster as "suspicious: phisher"

Custodian

(include: all the Attester paths)

you see protaginist's account has been marked "stolen" (you care cos you hold shards)
  └─> have to make counter attestation before able to return shards (?)

receives a request to fwd all of Protagonist's shards
  └─> you check the two identities, communicate with the Protagonist, and make an attestation
      ├─> fwds shards
      └─> don't fwd shards

you know a the Protagonist account is gone, and know new account
  ├─> fwds shards 
  ├─> attest a "reincarnation"
  │   └─> fwds shards
  └─> attest a "reincarnation" **privately**
      └─> fwds shards

3. inheritence

not doing yet

Clarifications :

• not all of these paths are must have, they're all the ones I can imagine given some particular assumptions about building a very simple solution
• Attestor is meant to mean just any person who "attests" / asserts something is true.
  • e.g. I could attest that @dead_dan1 is dead, and the last thing they said was %WKPufE4...
  • e.g. I could attest that @dan hassan is the "reincarnation" of @deprecated_dan1
  • we can do fancy things later with this but having any simple structured data around this will enable a lot already (like warnings).