3 ms·

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 o

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)

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)