On Sat, Oct 28, 2017 at 05:30:51PM +0300, George Kadianakis wrote:
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).
No problem! I'm glad you found my post helpful.
# 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.
I think it should be possible to fix this in the implementation without breaking anything.
# 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.
I agree with all of your proposed solutions (spec vs implementation) except for here, where I would be much more comfortable with an implementation change. I realize it would be a breaking change, however, and will understand if you decide to update the spec instead.
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).
At the moment I don't have the time to submit patches, sorry. If you find the time yourself then I'd be pleased to review/test your patches to confirm that they solve the inconsistencies I found.
Also, let us know if your independent implementation is a public thing we should know about. Seems interesting :)
I'm not implementing the full protocol, but I certainly will do when it's finished and open-sourced :)