Group based sharing and privacy

[Jay R Bolton]

First answer here is pretty good: https://security.stackexchange.com/questions/91704/which-strategy-to-encrypt-data-accessed-by-multiple-users

Summary of group encryption with asymmetric keys:

• Generate a new key pair for the group and keep both keys private. One key is a write key and one is a read key (the write key is the "public key" and the read key is the "private key"---however, both are kept private)
• Grant read access to a user by taking the group's read key and encrypting it using the user's own public key, then sending the encrypted version to them so they can store it
• Grant write access to a user by taking the group's write key and also encrypting using a user's public key.
  Revoke access by creating a new group key pair and re-sending all the user-encrypted keys.

[Tim Sweña (Swast)]

Does this issue address peer discovery at all? Encryption for group reading is a great first step, but another extra layer would be to hook group membership at the peer discovery layer. I would only want to peer the dat to people confirmed to be in the group, even though I know people outside the group shouldn't be able to read it.

I guess this is covered by Dat already with the discovery key, but the trouble with that a discovery key feels like there is less incentive for peers to keep secret than their private keys, so verifying peers by their private keys seems to be a good extra layer of security.

[Jay R Bolton]

@tswast - thanks for your comment.

I would only want to peer the dat to people confirmed to be in the group, even though I know people outside the group shouldn't be able to read it.

I'm not understanding this line -- can you give more detail about what you mean?

I made a post on scuttlebutt about many details of group privacy that may be useful to copy here -- ie. different encryption setups for group admins, covering how additional members can get added and removed (I'll have to pull the post off my other laptop at home later).

I don't yet know much about peer discovery mechanisms, but scuttlebutt has a lot going on in there using the gossip protocol.

[Tim Sweña (Swast)]

I would only want to peer the dat to people confirmed to be in the group, even though I know people outside the group shouldn't be able to read it.

As I understand it, currently peers have no notion of identity in dat. Someone discovers a peer who claims to be hosting a dat associated with a discovery key via one of several mechanisms and then makes a connection directly to that peer. It might make sense to have some notion of peer identity besides IP/port at this layer to better know if a peer is to be trusted or not, but the use case I'm thinking of doesn't necessarily need that layer of identity.

Next, the requester connects to a peer. It's at this layer where I think some notion of peer identity would make sense. Currently, you can connect to a peer and prove that you have the public key for a dat. Once you've proven that, the peer starts sending you data. Since public keys could potentially get leaked (especially since they are part of "dat URLs"), I think a bonus layer of encryption where the peer requesting data has to prove they are in the group of allowed readers. This could potentially integrate with the same encryption described here.

If we call the Dat archive's public key the "group key" as described here, it means we could create a different URL scheme like datwot://abcdefg... where instead of having the public key for the dat, it's the encrypted group key so that if that URL leaks no one else can read using it.

[Tim Sweña (Swast)]

If we call the Dat archive's public key the "group key" as described here, it means we could create a different URL scheme like datwot://abcdefg... where instead of having the public key for the dat, it's the encrypted group key so that if that URI leaks no one else can read using it.

One problem with doing it this way means that the datwot:// URI would change every time that you wanted to revoke access to someone. That's intended behavior, but if implemented so that the "group key" is the "public key" for the Dat archive, it means we'd need some way to migrate from the old Dat to the new Dat.

I guess if the data was completely re-encrypted but used the same Dat public key, the amount of work would be the same and probably less secure (because revoked users would get updates when there are changes to the dat even though they can't decrypt it any more), so maybe that is actually what we want. Basically, we have a new Dat every time we want to revoke access.