Encryption and private swarms with IPFS

Using IPFS for user apps with user data typically requires encryption. Since IPFS does not natively provide encryption, this is something that developers need to find a solution for.

Encryption of user data is a broad topic, and with user-owned data, this is even more challenging as it typically requires some form of key management.

Tools, libraries and services offering encryption over IPFS

In the last couple of months, I came across several tools and approaches to this problem, so I’m trying to curate a list of tools, libraries, and services that address this.

Libraries and tooling built on top of IPFS/IPLD

Usability

WNFS is the only one I’ve tried thanks to some help I got from the Fission team.

The nice thing about WNFS is that it works in browsers, and Fission’s work on WalletAuth means that the keys are derived from the user’s blockchain wallet ,e.g. via metamask.

As far as I know, WNFS is agnostic to where you derive the root key from and they also have an example that uses the WebCrypto API to safely generate and store keys in the browser. In this case, when using multiple devices, each device has its own key and access is delegated with UCANs.

APIs and services offering encryption

Unlike the projects above, the following are hosted services that handle encryption for you. I haven’t actually tried any of these, but they seem suitable for trusted setups where you want to ensure data isn’t public by default, but are willing to delegate trust to the service to manage encryption (in a somewhat similar way to how you use Google Drive and Dropbox):

  • Chainsafe files an encrypted user storage/sharing app built on top of IPFS
  • Lighthouse storage a hosted IPFS service with encryption. They manage the keys for you. They have an SDK which means you can use this programmatically in apps.

Private IPFS Swarms

Another thing that’s worth flagging is private IPFS swarms.

Private IPFS swarms do not encrypt any of the data, instead they limit network participation and communication to nodes that share an encryption key.

from the config docs:

It allows ipfs to only connect to other peers who have a shared secret key.

Some more details about private IPFS swarms from a GitHub comment:

Basically, everyone on the network uses the same symmetric key to encrypt all traffic (on top of the other encryption we do). This means you can’t join without this symmetric key.
Forward secrecy: connections are already encrypted and secured with a Diffie-Hellman handshake before they’re re-encrypted with this shared secret. So yes, it does have forward secrecy.
However, if you leak the secret key, anyone with access to the secret key can now join the network unless you rotate the secret key first.


Any services, tools, or libraries I missed? Let me know by replying! I’d love to know

2 Likes

Another user app that I forgot to mention is https://fileverse.io/

WNFS seems really nice, thanks for sharing this is a great topic. Have you found any information out there on how to use dag-jose with kubo ? Saw this, haven’t found yet an example of how it’s done with IPLD.

The link to the ceramic.network blog post on dag-jose doesn’t open here (other links work), copying the URL manually works though, thanks.

1 Like

Just came across this guide and example repo. It delegates encryption to GPG.

1 Like

I haven’t yet, but I’m sure someone from the Ceramic team could maybe chime in.

Hi Daniel, the frameworks look very interesting, thanks for researching. Do you perhaps also know whether these frameworks allow to change the encryption?

We are looking for some ways to host private data on IPFS, and the ownership over the data can be changed. We are thinking of changing the encryption once the data changes from owner, thereby making it able for the new owner to access the data, while the old owner should be unable to access the data.

Looking forwards to your thoughts.

My company is working on a solution that posts a “key file” to IPFS, which is a binary blob of asymmetrically encrypted keys that allow one to many / many to many encryption without payload replication. Each file is encrypted with a symmetric key, and that key is then asymmetrically encrypted using a few different schemes that allow one or many users to decrypt the symmetric key. Rekeying is as easy as reencrypting the file with a new key, then regenerating the key file based on the new rule sets / keys.

1 Like

Very interesting. Do you have a link where I can find more information about it? You can also send me a PM if you prefer that.

Some of the libraries we are developing are at:

Anything with “key” in the repo name. Unfortunately they are un[der]documented, but sometime in the near future we will be pulling it all together.

1 Like

Dropping this here following a conversation for further investigation:

  • Privy
  • Medusa
  • Arcana