undefined | Better HN

0 pointskevincox2y ago0 comments

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

0 comments

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

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

ianopolous2y ago

You can do that and also require auth to retrieve the cipher text blocks: https://peergos.org/posts/bats

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

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

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

1 more reply

j / k navigate · click thread line to collapse

0 comments

diggan2y ago

You could already add E2EE encryption yourself, just encrypt the content before you hash it and share the hash?

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

ianopolous2y ago

You can do that and also require auth to retrieve the cipher text blocks: https://peergos.org/posts/bats

ianburrell2y ago

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

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

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.

1 more reply

j / k navigate · click thread line to collapse