Encrypt and Decrypt Flags for "add" and "get" functions for CLI

Checklist

[X] My issue is specific & actionable.
[X] I am not suggesting a protocol enhancement.
[X] I have searched on the issue tracker for my issue.

Description

There is an obvious security hole here. As long as anyone has the hash of the PDF file, they can retrieve it from IPFS. So sensitive files are not well suited for IPFS in their native states. Unless we do something to these files, sharing sensitive files like health records or images is a poor fit for IPFS. So I want to add ipfs add <filename> --encrypt --pub public.pgp and ipfs get <hash> --decrypt --private private.pgp functionalities. For the passphrase or key locations, we can use config files on ~/.ipfs

etc. cmds.BoolOption(encryptOptionName, "e", "Encrypt the given File")

https://github.com/aydinnyunus/go-ipfs

Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review. In the meantime, please double-check that you have provided all the necessary information to make this process easy! Any information that can help save additional round trips is useful! We currently aim to give initial feedback within two business days. If this does not happen, feel free to leave a comment. Please keep an eye on how this issue will be labeled, as labels give an overview of priorities, assignments and additional actions requested by the maintainers:

"Priority" labels will show how urgent this is for the team.
"Status" labels will show if this is ready to be worked on, blocked, or in progress.
"Need" labels will indicate if additional input or analysis is required.

Finally, remember to use https://discuss.ipfs.io if you just need general support.

There is an obvious security hole here. As long as anyone has the hash of the PDF file, they can retrieve it from IPFS.

I don't see the "security hole" here, we don't claim to be a private file hosting platform in the first place. There are different options if you want to do that:

Use your own encryption (cat file | openssl $OPTIONS | ipfs add, write a an application that encrypt files before sending them to the API, ...).
Use PNET (a bit of a pain to use, I understand that people would want to use something else)

Things that need more information:

Why not just use an other application to do that (like writing your own, piping things in and out of openssl) ? How does adding that to go-ipfs makes this feature better ?
What encryption are you gonna use ?
- Algorithm ?
- Are you gonna salt the data ?
- Are you gonna using or make authentifying encryption (to allows checking if the key is valid or not) ?
Is using external files the only option to supply a key ?
- what about initialising the IVs from blake2(salt || password) so you could use text password instead ?
- or what about encrypting a file with a certain node public key, and then this node can seemlessly decrypt it ?
What about future proofing ?
- Are you gonna encode encryption (like metadata, parameters and maybe the key) in CIDs ?
How is the encryption gonna work ?
- IPFS doesn't store file as is, it first break them into blocks and then create manifest blocks which link all the subblocks. How do that works ?
- Do each block contain the key to the next blocks ?
  - If so how is that data gonna be added ? Can I make some kind of bundle CIDs which containt both the hash and the key ? (obviously you would only ask other peers for the hash, not the password)
- Do you reuse the same key (with different salts) for all blocks ?

Some questions are geuine questions, others or things I would do if I need to write that.

Opinion

I think this could be a nice feature ❤️, but I think you severly underestimate the work that needs to be done. 🙂

I've done an exhausted review of using other libraries and most of the cryptfs (cryfs, gocryptfs, et al.) break when an overlay is mounted (because ipfs direct is immutable, so we'd want an overlay for writes) because they're all doing things to encrypt metadata which seems to have bad interaction with overlayfs
Encryption algorithm should start with something common like aes-ecb probably, but obviously be modular and grow over time
There are a lot of reasons to support different algorithms for all the reasons we have so many today. Some are going to want their data to look as close to random data as possible for privacy and security and others are going to accept trade-offs of IV/nounce reuse and a pure symmetric process or perhaps convergent encryption in order to achieve some level of deduplication
So questions like how we generate a key, salt/IV/nounce, and algorithms - it needs to start probably with supporting it at all and a common well-accepted choice for each, but built with modular flexibility in mind
Future proofing: basically see above. Needs flexibility for differing opinions on the algorithms and methods that people with different opinions trust and also to allow easy drop in of emerging quantum-safe algs as an example
How is the encryption going to work? - I actually think this would make the most sense to implement as an alternate chunker. We already have a few alts today in addition to the size-x variations. I think something like aes-ecb-keysize-chunksize would make a lot of sense. It could start small and simple requiring raw keys and could give a few choices for key generation over time.

I think the method described above would also be quite simple to implement. We're basically inserting the encryption process at the end of chunking the data and we would need a method to decrypt the chunks when pulling them back which should be handled by the chunker being identified.

Would a commit in this direction be accepted upstream?

There is an obvious security hole here. As long as anyone has the hash of the PDF file, they can retrieve it from IPFS.

I don't see the "security hole" here, we don't claim to be a private file hosting platform in the first place.

There are different options if you want to do that:

Use your own encryption (cat file | openssl $OPTIONS | ipfs add, write a an application that encrypt files before sending them to the API, ...).

Use PNET (a bit of a pain to use, I understand that people would want to use something else)

Things that need more information:

Why not just use an other application to do that (like writing your own, piping things in and out of openssl) ?

How does adding that to go-ipfs makes this feature better ?

What encryption are you gonna use ?

Algorithm ?

Are you gonna salt the data ?

Are you gonna using or make authentifying encryption (to allows checking if the key is valid or not) ?

Is using external files the only option to supply a key ?

what about initialising the IVs from blake2(salt || password) so you could use text password instead ?

or what about encrypting a file with a certain node public key, and then this node can seemlessly decrypt it ?

What about future proofing ?

Are you gonna encode encryption (like metadata, parameters and maybe the key) in CIDs ?

How is the encryption gonna work ?

IPFS doesn't store file as is, it first break them into blocks and then create manifest blocks which link all the subblocks. How do that works ?

Do each block contain the key to the next blocks ?

If so how is that data gonna be added ? Can I make some kind of bundle CIDs which containt both the hash and the key ? (obviously you would only ask other peers for the hash, not the password)

Do you reuse the same key (with different salts) for all blocks ?

Some questions are geuine questions, others or things I would do if I need to write that.

Opinion

I think this could be a nice feature ❤️, but I think you severly underestimate the work that needs to be done. 🙂

I like the idea of using third party tools, but a lot of the fuse solutions break by not understanding ipfs underneath. Using third party libraries like openssl is exactly what I had in mind. I just think we would gain a lot with support to do that in the chunker.

ipfs / kubo