3 ms·

> I personally wouldn't keep my private photos on a public network, but everyone is different. IPFS needs transparent encryption yesterday. I tried to start a

> I personally wouldn't keep my private photos on a public network, but everyone is different. IPFS needs transparent encryption yesterday. I tried to start a discussion and even made a rough design but they don't seem interested. They have added some basic protection where a node won't serve content to another node without knowing the CID but this isn't the same level of security as E2EE. I think the encryption key should be transmitted with the CID but separable. So that you can pin data with just the raw CID but share data easily with CID+key.

diggan 3y ago
You could already add E2EE encryption yourself, just encrypt the content before you hash it and share the hash? Still, I wouldn't want anything I want to be private to be on a public network, be it IPFS, S3 or the internet at large. Who knows when the encryption will be broken? Simply too little benefits compared to the massive drawback in case the encryption doesn't hold in the future.
- ianopolous 3y ago
  You can do that and also require auth to retrieve the cipher text blocks: https://peergos.org/posts/bats https://peergos.org/posts/bats
- kevincox 3y ago
  Yes, but having it be disjointed from the protocol adds friction. You can't just browse the files using native tools and gateways. I think it would be great to be built-in. In fact I would argue that all data should be encrypted. But by default it could be encrypted with its own hash or similar so that it can still be deduplicated but has strong protection from people who don't already know the content (or hash) and can be pinned on untrusted nodes. This would resemble the Google Docs "public link" sharing. The only downside would be slight CPU overhead and longer keys.
ianburrell 3y ago
I'm surprised that nobody talks about content-addressed encryption with IPFS. It would be the perfect fit for IPFS. Content-addressed encryption uses the hash of the content as the encryption key. Which means don't need to transmit an extra key. And that anybody who has the original hash can access the encrypted version.
- kevincox 3y ago
  Yeah, I think content-addressed encryption is a good default. It means that anything you add is only accessible to those you share it with. I do think it is important to also support custom-key encryption. That way you can share publicly-known content without others knowing.
  - diggan 3y ago
    > Yeah, I think content-addressed encryption is a good default. It means that anything you add is only accessible to those you share it with. My first thought about that is a problem around how hashes gets passed around. When you add something to IPFS, it "provides" the resulting hash to the DHT (the submission article goes more into this), so other nodes know how to get it. If you then use the same hash for encrypting the content, it's basically as worth as using no key, as other nodes already know the hash because your node told them about it. So, lets not provide the hash when you add it then? But then the whole content-discovery part falls apart, how are nodes supposed to find the content if no one knows who has what hash? In the end, it sounds like a simple idea, but I'm not sure it'd provide value on a public network like IPFS.
    - kevincox 3y ago
      You use different hashes for discovery and encryption. One method is use HASH(0 || content) for discovery and HASH(1 || content) for encryption. You could also use HASH(content) for encryption and HASH(HASH(content)) for discovery. (Talk to a real cryptographer to ensure that this is both theoretically sound and robust against likely algorithm vulnerabilities) As long as you can't go from the discovery key to the encryption key you should be fine. IIRC this is already done. I think they do something like HASH(CID) for publishing on the network, but before the data is sent to the node they have to prove that they know CID. This provides protocol-level protection this content-based encryption. (Although it has downsides such as not being able to store encrypted data on untrusted nodes)

diggan 3y ago

You could already add E2EE encryption yourself, just encrypt the content before you hash it and share the hash? Still, I wouldn't want anything I want to be private to be on a public network, be it IPFS, S3 or the internet at large. Who knows when the encryption will be broken? Simply too little benefits compared to the massive drawback in case the encryption doesn't hold in the future.

ianopolous 3y ago
You can do that and also require auth to retrieve the cipher text blocks: https://peergos.org/posts/bats https://peergos.org/posts/bats
kevincox 3y ago
Yes, but having it be disjointed from the protocol adds friction. You can't just browse the files using native tools and gateways. I think it would be great to be built-in. In fact I would argue that all data should be encrypted. But by default it could be encrypted with its own hash or similar so that it can still be deduplicated but has strong protection from people who don't already know the content (or hash) and can be pinned on untrusted nodes. This would resemble the Google Docs "public link" sharing. The only downside would be slight CPU overhead and longer keys.

ianburrell 3y ago

I'm surprised that nobody talks about content-addressed encryption with IPFS. It would be the perfect fit for IPFS. Content-addressed encryption uses the hash of the content as the encryption key. Which means don't need to transmit an extra key. And that anybody who has the original hash can access the encrypted version.

kevincox 3y ago
Yeah, I think content-addressed encryption is a good default. It means that anything you add is only accessible to those you share it with. I do think it is important to also support custom-key encryption. That way you can share publicly-known content without others knowing.
- diggan 3y ago
  > Yeah, I think content-addressed encryption is a good default. It means that anything you add is only accessible to those you share it with. My first thought about that is a problem around how hashes gets passed around. When you add something to IPFS, it "provides" the resulting hash to the DHT (the submission article goes more into this), so other nodes know how to get it. If you then use the same hash for encrypting the content, it's basically as worth as using no key, as other nodes already know the hash because your node told them about it. So, lets not provide the hash when you add it then? But then the whole content-discovery part falls apart, how are nodes supposed to find the content if no one knows who has what hash? In the end, it sounds like a simple idea, but I'm not sure it'd provide value on a public network like IPFS.
  - kevincox 3y ago
    You use different hashes for discovery and encryption. One method is use HASH(0 || content) for discovery and HASH(1 || content) for encryption. You could also use HASH(content) for encryption and HASH(HASH(content)) for discovery. (Talk to a real cryptographer to ensure that this is both theoretically sound and robust against likely algorithm vulnerabilities) As long as you can't go from the discovery key to the encryption key you should be fine. IIRC this is already done. I think they do something like HASH(CID) for publishing on the network, but before the data is sent to the node they have to prove that they know CID. This provides protocol-level protection this content-based encryption. (Although it has downsides such as not being able to store encrypted data on untrusted nodes)