216 build keychainprogram

[benjaminpreiss]

• Move KeychainProgram into a dedicated package, like /programs/keychain (like ClockService - https://github.com/dao-xyz/peerbit/tree/master/packages/programs/clock-service)
• Rename package to shared-keychain
• Rename class to SharedKeychain

[benjaminpreiss]

identity already exist if you do

this.identity inside open (it is a global thing on 'this')

[marcus-pousette]

implements Keychain maybe? from '@peerbit/keychain'

[marcus-pousette]

When PR #215 is merged it should in practice just be possible to just do

@field({ type: Documents<Ed25519Keypair> })
keys: Documents<Ed25519Keypair>; // or something else secret

and later just do

sharedKeychain.keys.put(keypair, { encryption : { hash: ` the hash of the secret key you want to use` } })

[marcus-pousette]

or, well it depends if you want to have a a public and private part of the document of course. Then you need the EncryptedExtendedKey type

[benjaminpreiss]

Hmmm, but isn't the problem that the encryption property on the put method encrypts the whole key? How would I then find the public key of someone else that I want to encrypt something for, if the public key is encrypted as well?

[benjaminpreiss]

___ I edited this message by mistake ___ // marcus

[benjaminpreiss]

And I have also been thinking - sometimes, a user I want to encrypt something for has not generated a keypair yet. So at that time of speaking, I want to generate a keypair for him that is only single use. And that might have to be marked as such?

[marcus-pousette]

property on the put method encrypts the whole key? How would I then find the public key of someone else that I want to encrypt something for, if the public key is encrypted as well?

Ah yee for this to work the decryption has to be performed by keys that exist in a lower level keychain. When you use the put method there PublicKeyEnvelope (in the crypto lib) will leak the publickeys of the parties that can decrypt the message, which allows you to figure out if you can decrypt a message.

I think it might be easier to reason about stuff if you would separate "encryption" utilties from this shared-keychain. So this keychain stores keys that are encrypted, but the keys for providing the encryption for storing these keys for this keychain perhaps needs to originate from a lower level keychain.

It could in practice also be possible that keys in this keychain are allso encrypted by keys that also exist in this keychain, but then you need to make sure you are loading the database in the right order kind of (which is possible in practice there is a oplog behind the scenes that allows you to link commits)

[marcus-pousette]

If you want to revoke keys I think you need a revoked flag on the keypair object, or something like that. Else you could in theory also just use the delete function of the document store and assumes keys are only valid if they exist in the keychain

[marcus-pousette]

/bench document

[github-actions]

Benchmarks

Triggered by /bench - Run: https://github.com/dao-xyz/peerbit/actions/runs/21118859127

Mode: manual (document) • Selected: document

No matching benchmark suites ran for this PR.

[marcus-pousette]

/bench document