I have posted this before. I am exploring the possibility of creating an access control mechanism on IPFS. I discovered his post while cruising the IPFS forum and learned about Cryptree.
I thought the Cryptree mechanism would provide flexible access control, but I found a problem.
Problem
Data cannot be deleted.
This is a feature of IPFS, which makes the data legitimate. I understand that this is the beauty of distributed ledgers. However, this feature makes data re-encryption impossible.
For example, the following problems arise when trying to implement Cryptree. “I have encrypted and stored file A on IPFS using key ‘a’. I share key ‘a’ with person X to grant them access. Next, I deny access to X and perform Re-Encryption on file A to make the original key ‘a’ unusable. As a result, file A is encrypted with a new key ‘a’', but the original file encrypted with ‘a’ remains on IPFS. Consequently, X is still able to access file A.”
In other words, the inability to delete data means that re-encryption could not be performed. I looked at several of the projects listed in his post above, and it seems to me that this problem remains. I have several ideas to solve this problem:
Create a distributed key management system
What re-encryption is doing is invalidating the key.
"1:n (n>1), all the keys held by ‘n’ are identical.
Re-Encryption is equivalent to invalidating the keys held by ‘n’ and granting access with a new key."
Decentralized key-state system could solve the problem.
Change the method of generating CIDs (yes, this is just my imagination)
I think deleting data means making it unsearchable and unidentifiable. I understand that it is impossible to actually make the data on the node disappear from the world. However, I think the impossibility of finding it means that it does not exist in this world.
Changing the CID algorithm means that a new mechanism must be created.
The security aspects and compatibility with IPFS must be designed very carefully.
If you have any other good solutions or criticisms or opinions of my opinion, please let me know.
Twitter: @yu_da_1
You can delete files from IPFS, you have to remove it from all nodes that host it. It’s similar to http, you can trivially remove the file from your own servers / IPFS nodes, but if I host a copy on my server then you can’t easily do it, because it’s my server and you don’t have access to it (so you need to send a me a message explaining your reasons, …).
IMO this isn’t a en IPFS issue at all.
If I take this text:
I have encrypted and stored file A on IPFS using key ‘a’. I share key ‘a’ with person X to grant them access. Next, I deny access to X and perform Re-Encryption on file A to make the original key ‘a’ unusable. As a result, file A is encrypted with a new key ‘a’', but the original file encrypted with ‘a’ remains on IPFS. Consequently, X is still able to access file A.
And slightly change the steps to:
I have encrypted and stored file A on my FTP server using key ‘a’. I share key ‘a’ with person X to grant them access. X connects to my FTP server download and a copy of the encrypted file. Next, I deny access to X and perform Re-Encryption on file A to make the original key ‘a’ unusable. As a result, file A is encrypted with a new key ‘a’', but the original file encrypted with ‘a’ remains on X’s hard drive. Consequently, X is still able to access file A.
It’s just as broken even tho no IPFS at all is involved.
This is the beauty of information, you can’t change A once someone else got it, you can only stop sharing A and share an other file instead.
When you say:
Next, I deny access to X and perform Re-Encryption on file A to make the original key ‘a’ unusable.
This is not what you are doing, what you are doing is create a new file A’ encrypted with a different key and now you share A’ and not A.
Thank you for your reply. Your explanation helped me to understand and sort out my lack of understanding.
As a result, file A is encrypted with a new key ‘a’', but the original file encrypted with ‘a’ remains on X’s hard drive. Consequently, X is still able to access file A.
I feel our purposes and perspectives are different. I believe what you are saying is that it’s impossible to prove that the person who denied access has deleted the shared data. My intention was to make the data non-re-downloadable. This is a form of access denial.
This is the beauty of information
Yes, I agree. The lack of a “right to be forgotten” has both beautiful and problematic aspects.
The access denial I am talking about is making re-access (re-download) impossible, as I mentioned above.
I envision a system that allows individuals to have sovereignty over their data. I’m also considering the “right to be forgotten,” but I think that enforcing this right through code is still difficult, and legal restrictions appear to be the most promising solution.
Yes. Authorization from the original creator is required to retrieve encrypted blocks. This means blocks can only be on nodes with authorization, and it is only pinned on a user’s home server and any mirrors they authorize.
You can do ipfs repo gc after each removal and the old encrypted file will be removed from your node. (assuming you unpined it)
As pointed out in
Kubo isn’t optimised for garbage collection.
IMO reencryption doesn’t solve data sovereignty, something like FHE or Zk- Proofs would be better.
But if you are fine with data sovereignty as long as whoever you share keys with follow your rules reencryption would work, both on HTTP or IPFS.
(My view on this subject is pretty extreme, your proposal is still better than nothing because it still covers many (but not all) cases where the other peer is malicious.)
I am interested in this and this approach by mangofarms may work for you.
It uses blockchain tokens to provide access to content stored on ipfs. The IPFS content remains immutable as it is simply content. If you do not want public content it should always be encrypted on IPFS to make it unique content.
The unlocking and accessing is the fun part and that is where mangofarms idea and Ravencoin can help to manage access to the encrypted content.
