View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003566 | GNUnet | file-sharing service | public | 2014-12-07 02:41 | 2014-12-30 22:32 |
| Reporter | cy1 | Assigned To | |||
| Priority | low | Severity | feature | Reproducibility | have not tried |
| Status | confirmed | Resolution | open | ||
| Product Version | Git master | ||||
| Summary | 0003566: changing the CHK in response to active censorship | ||||
| Description | Often 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. | ||||
| Tags | No tags attached. | ||||
|
|
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. |
|
|
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. |
|
|
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. |
| 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 |
