support multiple keys

[dominictarr]

I've been thinking about how to add multiple identities to one "identity wallet" (if you will)

Currently, we store a json object:

{
  "curve": "ed25519",
  "public": ...,
  "private": ...,
}

etc. I'm thinking, for backwards compatilibty, we can add an array of other keys to that.

{
  curve: 'ed25519',
  ...
  additional: [
    { curve: 'ed25519', ... }, ...
  ]
}

so there is a default or main key and then other keys, so anything which depends on ssb-key will still work, and use the main key, but we can also use the alternative keys too.

[dominictarr]

/cc @emilbayes

[dominictarr]

then, in patchbay, you just have dropdowns to select which id you are currently using...

[emilbayes]

I'd rather just see each file containing a single key, and then have a wallet of keys being something external to this module. It could be as simple as several files in the .ssb folder.

The reason I stated using ssb-keys for something unrelated to ssb was that it's easy crypto for JSON :)

[dominictarr]

hmm, I think having multiple files is less user friendly. it means that now you have to back up secret1, secret2, or the whole secrets directory? keeping everything in one file also means we can encrypt/decrypt it all at once too.

I'm not proposing a very big change, probably just a method to add another secret to a file.

[emilbayes]

I'm not sure who would use this? Is it so you can have backup keys or is it so you can have several pseudonyms at the same time?

In terms of data modelling I think it's a bit awkward to have the other keys inside the first, even though it makes sense in terms of back compat. The "right" way would be to have an array of keys to choose from, and then mark one of them primary (maybe outside the key itself too, like in patchbay settings), right? Derived keys would, however, be the right fit to have tied to the originating key.

I'm imagining my pov is a bit too pure and not very pragmatic? I'm wondering which users you have in mind? Is this people managing the keys (I guess it is) or programmers interacting with the api?

I don't know if my opinion bears any weight, I just like that the API is simple, even though I think it maybe is a bit awkward that the key CRUD operations go with the operations that interact with the keys, but again I guess that feeling stems from a purity pov :)

[dominictarr]

Yeah, for mutliple pseudonyms. I get the purity thing, which is why this is the actual crypto (like private-box) is not implemented in this repo. This is just a bundle of things, and a encoding/decoding format.

An array does sound reasonable, but the other side of that argument is that makes using this more complicated on day one, when you don't care about multiple ids yet. Since people are already using ssb, we don't want to break that, so we'd still have to make it understand the old format.

I'd be happy to refactor so that you can use key loading or util methods as separate requires (require('ssb-keys/util') and require('ssb-keys/load') or something) that is a step towards purity.

[emilbayes]

I still think isolating the keys is a good idea. For my use case one key might be to chat with friends and family on patchwork, and another might be the key used for signing politically sensitive documents. If the user is advanced enough to recognise the purpose of multiple key pairs, I think they're tech savvy enough to know how to backup several files. I imagine users who back up their ssb stuff now probably take backup of the complete .ssb folder even though not strictly necessary?

[ahdinosaur]

i agree the proposed api is a bit awkward, i'd prefer multiple files for each secret, since my intuition on security-sensitive systems says there's many reasons why you might want to backup and restore keys separately.

what about a single secret file for one default identity, or a directory of secrets for many identities? to set the default between many you symlink secret -> secrets/my-default-key.

but to be honest i'm happy with my one key, soooo hm. /cc @mmckegg ?

[dominictarr]

many reasons why you might want to backup and restore keys separately. @ahdinosaur that is a pretty good point.

But also, this has to work on other things too, such as local storage on the browser. In that case, it's either in one object or with prefixed keys...

[ahdinosaur]

well since files in a directory have filenames, a directory of per-file secrets is analogous to an object with per-value secrets. the filenames or object keys could be either user-defined (professional-cat, shady-duck, etc depending on the persona behind the secret) or could be secret identifiers (pubkeys, pubkey hashes, etc). in the first option, whether a secret is the default one could be in the name, or maybe it's in the secret json description, or idk.

[emilbayes]

I think whether the key is primary is not something inherent to the key, but the application using the key

[chejazi]

One idea is to adopt the hierarchical deterministic key model used in Bitcoin

In such a setup, there's one "master key" from which all other keys are derived, so you would store 1 private key and then the additional: [] section would contain metadata on which derived keys are in use.

In order to maintain backwards compatibility, it seems like each curve would require its own file.

EDIT: HD wallets are probably overkill, but deterministic key gen from a single seed might work.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[dominictarr]

closing, supported by: https://github.com/ssbc/ssb-identities