undefined | Better HN

0 pointsdiggan2y ago0 comments

> 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.

0 comments

kevincox2y 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)

j / k navigate · click thread line to collapse