[braindump] Transparent file encryption/decryption

[markg85]

Hi,

I wanted to add this to #448 but it seemed like only one piece of the puzzle for that braindump. Therefore a new one for just transparent file encryption/decryption.

The goal is to have at least transparent file decryption (encryption is desired too). Programs using IPFS should not need to worry about encryption keys in arguments for commands. That would potentially alow attack vectors as the key would be part of the command. Hence my initial idea (posted as a comment in #448) is a bit bad in this regard but i'm just adding it below for completeness sake.

Idea 1 (not the best one)

Implement it in IPFS commands. So that you get something like, for example, a ipfs add <file> --encryption-key <aes key>. Likewise for getting a file. A benefit here is that you can also call this construct with the web API making the encryption fully transparent for API users (they only need the AES key, the IPFS client does the encryption/decryption)

Idea 2

New ipfs command: ipfs add-denc-jwt <cid> <json file>

denc stands for decryption-encryption.

Regarding the jwt in there. I'd just go for a standard format for describing files with encryption and decryption keys. JWT seems like a nice standard so i'd probably use that, but it can be something else too.

The command allows one to specify a <cid> and a JWT file used on that CID. The files added via this command are only locally known to the local IPFS node. The JWT file is on the user's pc and never leaves it.

How this is added is up for debate. It could just be <cid>-jwt.json files or it could be an internal SQLite database maintaining a mapping between CID files and JWT files. It would be my preference to just have files and stat them for existence.

Transparent decryption

Once a JWT file is added, the internal IPFS commands should take that JWT into account when a given CID is fetched.
So say for example this CID is encrypted: QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T [1] and a JWT is provided for that file too. Then a command like ipfs cat QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T should check if QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T-jwt.json exists and apply whatever decryption it describes. The result of ipfs cat QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T in this case should be the decrypted content.

If there is no QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T-jwt.json then the content is still shown as is. Thus just the encrypted useless content.

Again note that the jwt file is never added to the IPFS network and isn't used in any communication that lieave the pc. Not bitswap either. The file should only be used on commands that are going to present the data to the user. So like ipfs cat and a couple others.

Transparent encryption

For encryption there are a couple possible ways i can imagine for it to work out.

1. Add an extra argument to ipfs add that takes in a jwt.json file. Something like: ipfs add <my super secret file> --denc-jwt <jwt file>. This would not add the jwt file to the local IPFS data, the user still has to do that manually with ipfs add-denc-jwt <cid> <json file>
2. Alternatively there could be a seperate independent application that does the encryption step. For example call it ipfs-encrypt which would then be called like: ipfs-encrypt <my file to encrypt> --denc-jwt <jwt file> | ipfs add In this hypothetical command it would first encrypt a file and then add that encrypted file to ipfs using the vanilla ipfs add command.

I'm happy to receive any feedback you folks have!

P.S. I'd be very much open to do a call with interested parties to make up a design for this.
CC @Stebalien @aschmahmann

[1] It's big buck bunny and not encrypted, but just for the example of it.

[bmann]

Hey @markg85 -- at @fission-suite our CTO @expede created an encrypted file system on top of IPFS called WNFS. Moving parts of it more directly into the protocol and/or make some primitives that people could do different kinds of encryption schemes would be great.

We're hosting an invite only overview next week if you can make it, with some internal PL people mostly https://lu.ma/3m3qqmex

And, we presented at an IPFS / IPLD security and encryption workshop back in January https://talk.fission.codes/t/ipfs-ipld-security-encryption-workshop/1319

There is also a related discussion happening, that we are involved in, at the Decentralized Identity Foundation.

[markg85]

Hi @bmann

Thank you very much! It does sound very appealing to join!

Is that a meeting where you'd like to discuss the potential of alignining encryption from fission/WNFS with a potential to contribute them to IPFS native?
Or is it a meeting to explain how it works for potential inspiration of how to apply it to IPFS?

If it's the latter then I'd definitely like to join! :)

If it's the former then it would be super awesome if some people from protocol labs could join that have deep internal knowledge about IPFS and about the direction it should take. I'm fine joining but it wouldn't make much sense if the people from Protocol Labs who have opinions about this can't attend. Are there more invites available for them by any chance?

I'm guessing @Stebalien would want to attend? But here my knowledge of the IPFS team and who would like to know is a bit sparse. Perhaps @autonome can chime in to ping the people who would be super interested in this to join?

[bmann]

@markg85 the meeting I linked is an overview of UCANs / WNFS, which covers encryption on IPFS that is likely useful background for you. Right now it is all PL people attending, but feel free to join if you can make it.

UCANs is a special type of JWT that encodes DIDs and permissions that you might want to look at more closely.

Also, in general, encoding individual files and/or keeping metadata in the clear leaks metadata, which is why we're not particularly interested in doing encryption at the individual file level and wouldn't recommend it for core inclusion because of that.

We've had some discussions about WNFS in IPFS and as I mentioned that workshop back in January. I don't know on the IPFS/PL side who "owns" that, but we'll loop you in if there is another meeting.