BEP 44: Signature verification algorithm is invalid if the data is not a string

[jcea]

In section "Signature Verification", the data to check the signature is described as

Concatenate ("4:salt" length-of-salt ":" salt) "3:seqi" seq "e1:v" len ":" and the encoded value.

The result of that is only valid if the "encoded value" is actually a string, since "1:vLEN:DATA" is valid only if data is a string.

For example, what if DATA is a dictionary?. The resulting bencoding build by hand as suggested in the BEP would be invalid.

Checking my implementation in the mainline DHT, the algorithm actually implemented (at least by UT) seems to be:

("4:salt" length-of-salt ":" salt) "3:seqi" seq "e1:v" and the encoded value

Notice the lack of the "len" value.

If the encoded value was a string, the encoding will start with "LEN:", exactly as described by the standard. But the suggested change allows to encode more sophisticated structures, like dictionaries (as tested in the wild).

[jcea]

Moreover, the verification described and the test vectors don't agree. For instance, if data is "Hello World!", the test vectors are described as:

3:seqi1e1:v12:Hello World!

But according to the verification algorithm, the required (but wrong) data would be:

3:seqi1e1:v15:12:Hello World!

[the8472]

Yeah, the operation could be better described as building a bencoded dictionary with a raw (non-encoded) value for the v key and then removing the d prefix and e suffix from the dictionary.
At least that's how I have implemented the encoding side

[jcea]

I think that more test vectors should be added, specifically more complex datatypes like dictionaries, lists, etc.

I am publishing complex mutable structures to current mainline DHT and current explanation in the BEP is not correct for complex datatypes, neither follows current implementations in the wild.

[jcea]

For example, I am correctly publishing this to the mainline DHT, both on libttorrent clients and UT:

{'kAFKA': 'Hello World!', 'v': 'En un lugar de La Mancha'}

The signed data must be:

3:seqi2e1:vd5:kAFKA12:Hello World!1:v24:En un lugar de La Manchae

Note that this works in practice BUT it is not the prescriptive algorithm described in the BEP and the BEP algorithm, as describes, simply can't encode such a data structure.

May I suggest that that section in the BEP must be redone and more complex test vectors should be provided?