inkylatenoth <inkylaten...@protonmail.com> writes: > Whilst implementing v3 hidden services myself I found some > inconsistencies between the specs and the current implementation. I > wanted to share these in case someone from the Tor organization wants to > update the specs and/or the implementation. >
Hello inkylatenoth! That's a great post and thanks for catching all these issues and innacuracies! We are definitely interested in consistency and fixing the spec (and implementation if needed). > # rend-spec-v3.txt > > ## 2.4 > > * after decrypting the `superencrypted' object from a descriptor, the > resulting document does not end with the NL character. This means that > it does not strictly conform to the document meta-format described in > section 1.2 of dir-spec.txt. > Hmm... This might be worth fixing on the implementation if possible (and if it won't break things). Otherwise, let's patch the spec. > ## A.2 > > * the blinded key param is defined as H(BLIND_STRING | A | s | B | N). > In practice I found that I had to add a null byte after BLIND_STRING > in order to reach the same value as the C implementation: > > param = H(BLIND_STRING | INT_1(\x00) | A | s | B | N) > > In all other cases where a string constant is used like this (e.g. > computing the nonce N above), I found that the trailing null byte is > not required. > Ouch. This might be an artifact of the way strings are implemented in C. I guess a spec patch might be the right thing to do here, otherwise too much stuff will break. > * when clamping the blinding factor, the second bitwise operation is > `param[31] &= 127' in the spec but `param[31] &= 63' in the C > implementation. These are equivalent in practice when followed by the > third operation (`param[31] |= 64'), but it might be nice to use a > consistent representation for the benefit of human readers. > Hmm... Yeah there are various ways to do the clamping for ed25519 keys. I think we should edit the spec to reflect the clamping we do on the code. > # 220-ecc-ids-keys.txt > > # 2.1 > > * 'The signature is formed by signing the first N-64 bytes of the > certificate prefixed with the string "Tor node signing key certificate > v1".' I found this to be false; the signatures only validate without > the string prefix. > Ouch... I think we should edit the spec and consider if there are any security risks here. > ## A.1 > > * I realized that the certificate types here are outdated. The > signing-key extension is listed as type [04], when in rend-spec-v3.txt > and the C implementation it is type [08]. Let's fix the spec here too... --- Inkylatenoth, let me know if you are interested in drafting a spec/code patch for the issues you found!!! If you are not interested, I can try to do them myself at some point in the next weeks (been pretty busy with stuff lately). Also, let us know if your independent implementation is a public thing we should know about. Seems interesting :) Thanks again! _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
