Encryption and public keys

[oelmekki]

Hi Paul _o/

Great feature, love it! :)

My first thought when reading about the default schema was that this would be perfect to distribute public keys, somewhat like a decentralized keybase.

The main interest of the dweb for me is to not have my data owned by centralized third parties ; but if it's all public, it kind of misses the point. I guess I'm not the only one to investigate the dweb for privacy reasons? That's why I started to work with dat/beaker rather than ssb (as much as I love ssb), I love how it's easy with beaker to build apps encrypting the data and just sharing the encrypted files.

Right now, I do that in beaker by storing the private (ed25519) key in localStorage and telling the user to download it as a file, then either find it again from localStorage or retrieving the file through an input[type=file]. To share their public key with their friends, they're on their own, though (meaning, they'll use centralized solutions like facebook or slack to do it). Love how unwalled.garden would make that easy!

Did you consider building encryption within unwalled.garden and beaker? Like, having beaker store our private key, maintaining a local registry of friends' public keys through the unwalled.garden files, then leveraging the visibility field to add a "protected" value, which would allow to encrypt the content for a set of given public keys.

In any case, with the custom schemas from unwalled.garden, it will make it easy to distribute public keys anyway, so thanks! :)

[pfrazee]

Hi @oelmekki !

Let me share what we have planned for privacy tools.

1. Private/Public/Selectively-shared dats. Beaker is building a filesystem architecture where every person has a "root dat drive" and a "public dat drive." The root drive is private and kept off the network. (It will eventually be synced between your devices.) The public drive is your profile. Both drives will have a Data directory and so all records will have a privacy setting which will determine the drive being used. Eventually we will introduce "selectively-shared" dats which are drives that only sync with a whitelist of peers. These will be used for private groups.
2. Key publishing. Like you suggest, we will eventually add a keys directory where you can publish your public keys. Kind of a no-brainer!
3. Identity verification. We have some rough plans for how identities will be confirmed on the dat network. To start, we'll have Unwalled Garden's social graph. However we also need tools for key rotation, in case your dat gets corrupted or keys get lost. We're thinking we'll have "user registries" which are dats that maintain (auditable) username -> pubkey mappings. Users will declare the registry that maintains their identity so that there's a place to check if the key has rotated. Those registries should also be useful for lookup/search. Obviously we can support multiple registries so that trust can be distributed.
4. At-rest encryption. I'm not sure yet how at-rest encryption will factor into Unwalled Garden, but it's a fairly natural step to use the published keys to do private sharing. I'm a little nervous about publishing encrypted files as a privacy solution because it means a private-key leak is an automatic global pwn. I think, for the UG records, we'll probably focus on the selectively-shared dats.
5. Authenticated connections. The dat wire protocol is adopting NOISE for transport-level security. We'll be able to use the published user keys to authenticate connections with target peers. Beaker will introduce a PeerSocket API so that applications can leverage this. It's also how selectively-shared dats will operate.

Let me know if you have any questions or thoughts!

EDIT: I expect the browser will get involved with managing keypairs, and provide APIs for using them without actually giving the private keys to applications.

[oelmekki]

Oh wow, ok, I see you already quite thought that through :D That sounds awesome!

Indeed, the browser managing the keys is the dream solution, I didn't even dare hoping for it too much :)

Really love the idea of being able to select peers we're connecting to - indeed, so far, if the user's private key of the app I'm playing with leaks, the user is screwed. Plus, I guess if the browser holds the secret keys, it makes it "easy" to verify those peers (rather than an IP based solution or something).

The key registries sound a bit more scary, because it has the "federation" smell around it. But yeah, it's difficult to imagine a source of trust otherwise for changing keys - plus, it's not like if all the data was federated by a few super users, just the keys. I love how ssb handled that recently, with dark crystal : you give a few friends encrypted parts of your secret, and then you can ask it back to them to recover your secret key. I guess rotation could be handled the same way : declaring a few trusted friends, if they all (with maybe a small error margin) say your public key changed, then it's considered changed.

Anyway, thanks for your time and answers!

[pfrazee]

The key registries sound a bit more scary, because it has the "federation" smell around it.

On the plus side, it's all via dats, so it's almost like a shared dataset. You'll contact a service that manages the dat to make changes, but hey.

I guess rotation could be handled the same way : declaring a few trusted friends, if they all (with maybe a small error margin) say your public key changed, then it's considered changed.

Communities could run their own identity registries and it should be very similar. Instead of contacting a service, you DM your friend.

[oelmekki]

Sounds cool indeed :) Thanks!