View Issue Details

IDProjectCategoryView StatusLast Update
0003566GNUnetfile-sharing servicepublic2014-12-30 22:32
Reportercy1 Assigned To 
PrioritylowSeverityfeatureReproducibilityhave not tried
Status confirmedResolutionopen 
Product VersionGit master 
Summary0003566: changing the CHK in response to active censorship
DescriptionOften times adversaries will have the CHK of the data they want to censor. Either gotten through leaks, or simply by hashing the original content assuming it wasn't re-encoded. Encrypting the data in transit will prevent passive attacks such as image analysis, but what if the adversary does get the CHK? And really, it's reasonable to assume that they eventually will, since blocking them from seeing the CHK is itself a form of censorship.

Given the CHK of the plaintext content, adversaries can order intermediates to censor it trying to prevent its distribution, even the encrypted CHK can easily be blacklisted. Normally what people do in that situation currently is to re-encode the movie file. Which only works for movies of course. It's a very ad-hoc method though, and often poorly applied in ways that reduces the quality. A better solution would be to just encrypt the data a second time to a random key, which will definitely change the hash.

So, could GNUnet possibly support selecting an encryption key that isn't always simply the content hash? Doing so could produce multiple redundant copies of the same data, which is bad, but when only done in response to an adversary succesfully censoring the original data, there would be only one copy in the end after all. And if they find the new CHK, another can be switched to just as seamlessly. Whichever one isn't censored will be the easiest one to get, which will be the one people end up keeping in preference to the others.

I thought of this as an issue when I noticed Youtube users occasionally having a re-upload war with big media companies by slightly changing the content when it gets banned and uploading it again.
TagsNo tags attached.



2014-12-07 02:53

reporter   ~0008650

What I mean is like, when you calculate K for E(K,B), K = H(B), and the CHK is (K,Q) where Q = H(E(K,B)). It doesn't seem any part of the file retrieval would necessarily fail if K was just random not always H(B); you just lose the convergent encryption.

Christian Grothoff

2014-12-08 14:54

manager   ~0008658

Yes, this has been a feature that was proposed a long time ago already, but we just never got around to implementing it. Still, this is not about DHT but FS.


2014-12-30 22:32

reporter   ~0008741

Sorry if it was already proposed. I did search around for something like this, but couldn't find anything. If it has been proposed I'd appreciate you marking this as a duplicate of that proposal so I can find the real one.

Issue History

Date Modified Username Field Change
2014-12-07 02:41 cy1 New Issue
2014-12-07 02:41 cy1 Status new => assigned
2014-12-07 02:41 cy1 Assigned To => Bart Polot
2014-12-07 02:53 cy1 Note Added: 0008650
2014-12-08 14:54 Christian Grothoff Note Added: 0008658
2014-12-08 14:54 Christian Grothoff Priority normal => low
2014-12-08 14:54 Christian Grothoff Category DHT service => file-sharing service
2014-12-08 14:54 Christian Grothoff Assigned To Bart Polot =>
2014-12-08 14:54 Christian Grothoff Status assigned => confirmed
2014-12-30 22:32 cy1 Note Added: 0008741