a scuttlebutt (secret-stack) plugin which adds envelope encryption capabilities
npm install ssb-private2Introduces evelope encryption to scuttlebutt.
STATUS: WIP
``js
const SecretStack = require('secret-stack')
const config = require('ssb-config')
const shs = // from ssb-caps for main network, or your alt-net key
const SSB = SecretStack({ caps: { shs } })
.use(require('ssb-db')) // << required
.use(require('ssb-private2'))
const ssb = SSB(config)
`
`js`
const content = {
type: 'profile/person',
//....
recps: {
}
}
ssb.publish(content, (err, data) => {
})
Later, any of the following will result in a happiliy readable message (for you and those who share the GroupKey):server.get(msgKey, { private: true }, cb)
- you use
- you run any db query which might have matched that message
NOTE:
- is a unique identifier which can be mapped to the for that Group. The importance of these being distinct is that a is designed to leak no information about who is in the group, and is therefore safe to reference in public contexts.
- is synonymous with the public key of a particular device (@...sha256). Said another way, the id of a feed is currently synonymous with it's (public) key.
A Secret-Stack server running the plugins ssb-db and ssb-private2
where
- groupId String - is a cloaked group id (see private-group-spec/group-id/README.md)info
- Object - contains data of form { key, scheme } where:key
- String - a 32 byte symmetric key for the group (as a base64 encoded string)scheme
- String (optional) - a description of the key management scheme this key is part ofcb
- [ Function - a callback with signature cb(err: Error, success: Boolean)
where callback cb has signature cb(err, success)
Get all the keys that a message published by authorId could have used to encrypt with.cb has signature cb(err, keys) where keys is an Array of Buffers.
This is used for suppliying trial_keys to envelope-js's unbox method.
---
Where cb has signature cb(err: Error, success: Boolean)
:warning: NOT YET IMPLEMENTED
Mint a new private group.
This generates a new key for the group, and a new groupId.
_This method calls group.add and group.addAuthors for you (adding you)_
This published entrust messages to the new messages, sending them a copy of the groupKey.
_This method calls members.add` for you._
- how does this "key store" interact with flume views?
- if we discover a new key entrust part way through indexing ... we have to trigger re-indexing of other views
- might need to reset this view too, as opening existing groups will reveal other entrusts sent to members ....
- oh god this could get recurrsive. As in ok I know Ben has given me a key so I re-index with and try this key on Ben's encrypted messages, but then I reveal from here that Ben has entrusted the key to Cherese .. ok add Cherese as a member, start again because Cherese may have said something before....
- I think this means when we entrust we need to know the root message + author.
- should the key-store sit outside flume views?
- if it does then we can manually add things from outside system...