View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002179 | GNUnet | GNS | public | 2012-02-25 13:28 | 2012-02-28 11:05 |
| Reporter | schanzen | Assigned To | schanzen | ||
| Priority | high | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | fixed | ||
| Product Version | Git master | ||||
| Target Version | 0.9.2 | Fixed in Version | 0.9.2 | ||
| Summary | 0002179: GNS needs a dht block plugin | ||||
| Description | For the dht lookup GNS needs a block plugin that can verify the block and the signatures against the records contained within. We need either 2 Different block types for zone transfers (has > 1 signature, 1 for every name the authority has) and single name records (1 signature, contains records with same name) or A single block layout that can handle both. | ||||
| Tags | No tags attached. | ||||
|
|
Is it enough to check signatures in the block plugin? Say a block provides: key = H(name) xor H(pubkey of zone) pubkey of zone record data signature over record data with pubkey Now anybody could inject records if we only check the signature against the record data with the provided pubkey. So we have to check pubkey of zone against H(pubkey of zone). But is this "enough"? If a GNS node that never head of this hash gets a block like this it will simply cache. no problem. But if a node that already knows a zone with H(pubkey of zone) gets a block like this won't it have to check if the key in the namestore is the same as the one provided (hash collision)? Even worse the resolver itself (not block plugin) needs to check this as well to be safe no? I guess GNUNET_NAMESTORE_record_put could do the sanity checks for the pubkey. The whole problem boils down to hash collisions I think. Suggestion: make GNUNET_NAMESTORE_record_put check for hash collisions. And the GNS resolver will handle it in the continuation closure? On the other hand the block plugin needs an answer in a timely manner (not async) but I haven't started looking into that in detail yet. I think the block plugin will: 0. Do some sanity check w/ key maybe (check pkey and H(pkey)) 1. Check the signature of the record data with the provided pubkey using GNUNET_NAMESTORE_verify_signature 2. If valid cache the record data with GNUNET_NAMESTORE_record_put. If the namestore already has an entry with a different pubkey it will tell us in the closure and we will not cache. BUT: we already decided if this block is ok or not at this point in time! |
|
|
Resolver might not have to check because the local DHT's block plugin should check first, and that's within our trust domain. But, checking wouldn't hurt (except for performance) just to double-check against bugs. Checking for hash collisions is not required, as we have 512-bit hashes. |
|
|
Added plugin to svn head |
|
|
-- |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2012-02-25 13:28 | schanzen | New Issue | |
| 2012-02-25 13:28 | schanzen | Status | new => assigned |
| 2012-02-25 13:28 | schanzen | Assigned To | => schanzen |
| 2012-02-26 12:21 | schanzen | Note Added: 0005519 | |
| 2012-02-26 12:43 | schanzen | Note Edited: 0005519 | |
| 2012-02-26 12:50 | schanzen | Note Edited: 0005519 | |
| 2012-02-26 13:11 | Christian Grothoff | Note Added: 0005520 | |
| 2012-02-26 21:50 | Christian Grothoff | Severity | major => feature |
| 2012-02-26 21:52 | Christian Grothoff | Relationship added | duplicate of 0002164 |
| 2012-02-28 10:06 | schanzen | Note Added: 0005529 | |
| 2012-02-28 10:06 | schanzen | Note Added: 0005530 | |
| 2012-02-28 10:06 | schanzen | Status | assigned => resolved |
| 2012-02-28 10:06 | schanzen | Fixed in Version | => Git master |
| 2012-02-28 10:06 | schanzen | Resolution | open => fixed |
| 2012-02-28 11:02 | Christian Grothoff | Product Version | => Git master |
| 2012-02-28 11:02 | Christian Grothoff | Fixed in Version | Git master => 0.9.2 |
| 2012-02-28 11:02 | Christian Grothoff | Target Version | => 0.9.2 |
| 2012-02-28 11:05 | Christian Grothoff | Status | resolved => closed |
