inkylatenoth
2017-10-28 09:28:30 UTC
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.
# 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.
## 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.
* 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.
# 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.
## 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].
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.
# 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.
## 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.
* 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.
# 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.
## 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].