I don't understand why you need to invent a new encryption method: https://github.com/jeswin/ssb-scuttlekit/blob/master/secure-key.md

SecureKey is a minor modification over private-box to suit ScuttleKit's database replication. The main difference over private-box is that SecureKey is only used for distributing keys for later use and not for communicating messages.

Sure but you can put anything inside a private-box. It doesn't have to be a post.

In addition, it defines a key identifier to help with caching, and a mechanism to handle hierarchies of trust seen in organizations and groups.

This also means it leaks metadata about who is talking to who (because they all use the same key identifier, visible to everyone). It also looks like this format reveals how many other peers you are talking to.

I think I understand the how the "key trees" work, (but not why you call them that), instead of just multipling the ephemeral key with the identity key, you also use previous keys sent.

Once the keys are sent, how are they used in messages? Is there another message format for those messages and do they still use the key id?

note, there are also some known problems with private-box, which this proposal is also vulnerable to. In particular, you could replay someone else's key message, and it would look like I knew the key, which could have surprising effects depending on the application.

I am happy to provide feedback an answer questions, cryptographic protocols is something we need to take very seriously, and there is not much prior art for group messaging to build off of. As everything I know about crypto is self-taught I am happy to support other people who are also learning, but as it is, I don't think this improves on private-box. I would rather have people to work with on private-groups than multiple incompatible private messaging formats.

The part of the proposal that I am quite interested in, though, is the sandboxing.
We need it to be easier to make and distribute ssb applications, I think sandboxing is very relavant here. Can you tell us more about how this will work? are apps loaded as websites? (i.e. from servers?) and/or from ssb blobs?

cc #ssbc-grants

@jeswin regards crypto - thanks for the clarifications, that makes a lot more sense. I'd suggest updating your secure-key document - In particular, I think it's important to make clear what properties you are aiming for. The best way to come up with the properties is to study similar systems, and to try to think of ways to attack them, then resist that attack.

For example, I have a list of claims for secret-handshake (and I came up with this list of properties by studying other key exchange protocols, and attacks on them)

It would help a lot to know also how you intend to use this in an application, because I think private-groups (i.e. next improvement over private-box) should meet your needs. I wrote a thing about the next-step towards private-groups just the other day.

I would be very happy to have more people to collaborate with on this stuff. @keks knows lots about crypto but hates javascript ;0

Also note if you are interested in crypto for organizations, see bls group multisig

I am glad to hear that only one feed uses a given key id! But I still think that leaks metadata.

Assume most messages on ssb are encrypted with SecureKey. and Alice is communicating with Bob and Carol using secret key. Eve is trying to figure out who alice is talking to. Eve can see that alice has been using two different key ids, over this time - that is already enough to reveal that Alice is only talking to two groups and not 3 or 1! Eve doesn't know who else is in the group, but she knows there are two groups that Alice is using... So using a key id means we can easily know how many groups Alice is actively participating in. It also makes corrolating messages much easier so over time Eve could get a pretty good idea who Alice is talking to: Carol posts to a group id1, and shortly after, Alice post to a group id2. If we have some model of how many messages are replies vs first messages, we can correlate that messages from Alice with id2 come usually/often after messages from Carol with id1 and then extract that they are probably talking to each other.

However, since key ids are unique to the feed, you could ratchet them forward, using id = hmac(id, key) that way each message would get a different unique id, but would only know it if you had the key (and had decrypted previous messages).
This would make the decryption more complicated (because it's stateful now) so the question becomes wether the performance improvement is worth it.

On that note, it's important to notice that a hash or symmetric encryption is really cheap. from this benchmark I learned that a single asymmetric operation is worth about 60 hashes or secretboxes. So unless alice needs to try less than 10 keys, at any one time, it might not make a difference.

I'll reply in more detail later, but it sounds that this proposal could actually be several proposals. I think if this was just focused on the web auth, it would be a strong proposal. Also, that part reminds me a lot of what @SoapDog has been doing.