View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003605 | GNUnet | file-sharing service | public | 2015-01-03 23:34 | 2015-01-15 21:50 |
| Reporter | cy1 | Assigned To | Christian Grothoff | ||
| Priority | normal | Severity | feature | Reproducibility | have not tried |
| Status | closed | Resolution | no change required | ||
| Product Version | Git master | ||||
| Summary | 0003605: Signed KBlocks | ||||
| Description | To prevent from getting bogus data spammed by forces of evil and marketing, you can search for SSK@pseudonym/keyword instead of KSK@keyword using some pseudonym you know of to cut out the spammers. But if there are two pseudonyms both publishing valid data for a specific keyword, you cannot get both their results in a single search. Additionally you cannot discover new pseudonyms publishing to a particular keyword, so you can only use some insecure out of band method for learning pseudonyms. On the assumption you're already being flooded, then that insecure method is going to be a prime target for spammers. The equivalent of putting your email address on a website so that people learn how to email you. Furthermore, once you have search results, you cannot filter out those who have inserted bogus results. The simplest solution I can see to these problems would be allowing for KBlocks to have a signature. They would still be encrypted with the keypair derived from the keyword, not the pseudonym, but could simply contain a signature of the CHKs and metadata they contain. Just specifying an option to gnunet-publish to sign with a pseudonym, something like that. Then KSK search results could include the pseudonym who published that search keyword. If their are two pseudonyms publishing valid search results, then searching for KSK@keyword and choosing results signed by those pseudonyms would allow you to get the results of both of them with a single search. You can discover new pseudonyms this way, as when you search for KSK@keyword you might find signatures within the results. And if you identify a bogus search result, it'd be simple to filter out the pseudonym that published that result, even for the search you've already completed. Of course spammers could generate a new pseudonym for every keyword they publish, but at least that would be harder then them being able to post metric tons of body wash ads under KSK@mp3, and even if they did, then people searching could limit results to those who have produced good results before the flood, cutting off spammers before they even get started. But without signed KBlocks nobody can limit their results at all, and have to just hope that they can pick keywords that are confusing enough that spammers won't guess them, but not confusing enough that valid publishers will think to use those keywords. And that's sort of a catch-22 situation there. A hack solution would be publishing only the contents of your pseudonym under a KSK keyword, and then publishing the actual file under the corresponding SSK@pseudonym/keyword. Then people could ignore all KSK results that weren't pseudonyms, and then issue a barrage of searches for each and every pseudonym they trust when they want to find files under a particular keyword. I really don't want to have to do that though, if KBlocks can be at all modified to contain a signature of their contents. This is from reading the original ecrs.pdf document, so if there are already signed KBlocks I apologize for my ignorance. I sure don't see how to get the pseudonym for a keyword in gnunet-search, that was published with gnunet-publish -P ... -k keyword. | ||||
| Tags | No tags attached. | ||||
|
|
Dangit, I might have misfiled this. I have got to stop having these crazy ideas. Is there a libextractor category? Or is that a different bug tracker entirely? Making these signatures an actual metadata field for libextractor might be the best way to do it, but it makes me uneasy since it tangles up the interfaces so much. libextractor would have to be aware of the identity service and couldn't just, uh, extract metadata from the file. Normally gnunet-publish just feeds the file to libextractor, and takes from it the metadata that results, but an identity signature would have nothing to do with the file contents, so there'd have to be a way to pass a file and a signature to libextractor, or else to add metadata fields libextractor is unaware of, after adding the metadata it returns, which is currently not allowed and forced into the 'unknown' metadata field. Or maybe libextractor should have a 'signature' metadata field, that it doesn't do anything with at all, only existing so a file publisher doesn't block its use outside of the extraction process? |
|
|
You write: "But if there are two pseudonyms both publishing valid data for a specific keyword, you cannot get both their results in a single search." -- eh, why not? We're not Freenet, we CAN have many results under a keyword. (overall, you're using a bit much Freenet-specific terms that don't apply 1:1 on GNUnet). |
|
|
As for LE, that is the same bug tracker, you just select a different project in the top right corner. |
|
|
"Additionally you cannot discover new pseudonyms publishing to a particular keyword" -- that's also kind of false. You can discover new pseudonyms by searching for a particular keyword, and similarly you can advertise your pseudonym under a keyword. GNUnet calls those blocks 'UBlocks', and actually shows a 'pseudonym-mask' when a keyword has such a result in gnunet-gtk. |
|
|
"so you can only use some insecure out of band method for learning pseudonyms." is also misleading, as I'd not consider GNS to be insecure our out-of-band. So given that your analysis seems to be based on a lack of understanding of how things are designed to work, I don't quite see a need to follow your proposed solution. However, there clearly might be a need to improve our documentation. Maybe you can play with gnunet-publish / gnunet-search / gnunet-gtk and propose improvements to clarify the docs? |
|
|
Thanks Christian Grothoff. I swear I understand SKS/KSKs one day, and confuse them terribly the next. You're right that we don't need signatures embedded in KBlocks. We just need a way to search, which groups all SBlocks that decrypt according to a certain keyword. I had forgotten that SBlocks aren't actually encrypted with the public key of the signer, but still only with the search phrase. Even if they were encrypted with the key, you could just look up the key by the (unencrypted) signature, and add that to your decryption. So, it is possible to find all SBlocks that match a particular search phrase, of all identity keys. It just hasn't been written yet. Not sure if it might be unscalable either, but if KSKs decrypt the same way then it shouldn't be any more algorithmically complex. The only thing signed KBlocks would do is enable someone to verify a search result, without any intermediaries being able to mitigate floods from them, or allow them through during floods. So, it's a pretty stupid idea in reflection. I don't entirely understand GNS, but I suppose it is a possible way to discover identity keys. Its primary purpose however, seems to be discovering non-GNUnet network addresses along the lines of the outmoded DNS. I didn't really have much use for that, as I don't have any way to verify the authority of a GNS authority any more than I do a root DNS authority, but maybe I'm just misunderstanding its purpose like you said. |
|
|
It'd be nice if a bug reporter could close their own bugs grumbles |
|
|
GNS is more than just a DNS replacement, it is about identity management (and namespaces are one type of identity) about naming (and if you can name a namespace, you can then access it), and about key management. But I know that it is difficult for people to wrap their heads around GNS because it does so much. Anyway, closing the bug. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-01-03 23:34 | cy1 | New Issue | |
| 2015-01-06 20:00 | cy1 | Note Added: 0008753 | |
| 2015-01-10 19:06 | Christian Grothoff | Note Added: 0008770 | |
| 2015-01-10 19:06 | Christian Grothoff | Note Added: 0008771 | |
| 2015-01-10 19:08 | Christian Grothoff | Note Added: 0008772 | |
| 2015-01-10 19:11 | Christian Grothoff | Note Added: 0008773 | |
| 2015-01-15 21:19 | cy1 | Note Added: 0008791 | |
| 2015-01-15 21:21 | cy1 | Note Added: 0008792 | |
| 2015-01-15 21:49 | Christian Grothoff | Note Added: 0008793 | |
| 2015-01-15 21:50 | Christian Grothoff | Status | new => closed |
| 2015-01-15 21:50 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2015-01-15 21:50 | Christian Grothoff | Resolution | open => no change required |
