jiigen666/libtorrent
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

merged DHT fix from RC_0_16

Browse Source
This commit is contained in:
Arvid Norberg
2012-11-16 22:25:39 +00:00
parent 6612d1f88a
commit f12e1c1a3f
5 changed files with 59 additions and 39 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
docs/dht_store.rst
View File

@@ -44,16 +44,23 @@ network.
The ``token`` field also has the same semantics as the standard DHT message ``get_peers``
and ``announce_peer``, when requesting an item and to write an item respectively.
The ``k`` field is the PKCS#1 encoded 2048 bit RSA public key, which the signature
can be authenticated with. When looking up a mutable item, the ``target`` field
MUST be the SHA-1 hash of this key.
The distinction between storing mutable and immutable items is the inclusion
of a public key, a sequence number and signature (``k``, ``seq`` and ``sig``).
The distinction betwewn retrieving a mutable and immutable item is the inclusion of
the public key spill-over (``k``) in the ``get`` request.
The ``v`` key is the *value* to be stored. It is allowed to be any bencoded type (list,
``get`` requests for mutable items and immutable items cannot be distinguished from
eachother. An implementation can either store mutable and immutable items in the same
hash table internally, or in separate ones and potentially do two lookups for ``get``
requests.
The ``v`` field is the *value* to be stored. It is allowed to be any bencoded type (list,
dict, string or integer). When it's being hashed (for verifying its signature or to calculate
its key), its flattened, bencoded, form is used.
Storing nodes are SHOULD reject ``put`` requests where the bencoded form of ``v`` is longer
Storing nodes SHOULD reject ``put`` requests where the bencoded form of ``v`` is longer
than 767 bytes.
immutable items
@@ -131,7 +138,8 @@ mutable items
Mutable items can be updated, without changing their DHT keys. To authenticate
that only the original publisher can update an item, it is signed by a private key
generated by the original publisher.
generated by the original publisher. The target ID mutable items are stored under
is the SHA-1 hash of the public key (as it appears in the ``put`` message).
In order to avoid a malicious node to overwrite the list head with an old
version, the sequence number ``seq`` must be monotonically increasing for each update,
@@ -152,7 +160,7 @@ Request:
"a":
{
"id": *<20 byte id of sending node (string)>*,
"k": *<RSA-2048 public key (268 bytes string)>*,
"k": *<RSA-2048 public key (PKCS#1 encoded)>*,
"seq": *<monotonically increasing sequence number (integer)>*,
"sig": *<RSA-2048 signature (256 bytes string)>*,
"token": *<write-token (string)>*,
@@ -187,8 +195,7 @@ Request:
"a":
{
"id": *<20 byte id of sending node (string)>*,
"target:" *<first 20 bytes of public key (string)>*,
"k": *<remaining 248 bytes of public key (string)>*
"target:" *<20 byte SHA-1 hash of public key (string)>*
},
"t": *<transaction-id (string)>*,
"y": "q",
@@ -230,6 +237,13 @@ value and sequence number should be done as follows:
3. hash the concatenated string with SHA-1
4. sign or verify the hash digest.
On the storage node, the signature MUST be verified before accepting the store command. The data
MUST be stored under the SHA-1 hash of the public key (as it appears in the bencoded dict).
On the subscribing nodes, the key they get back from a ``get`` request MUST be verified to hash
to the target ID the lookup was made for, as well as verifying the signature. If any of these fail,
the response SHOULD be considered invalid.
expiration
----------