torspec isn't very clear about the encodings used for `onion-key` and `signing-key`
Currently, in dir-spec.txt
, it is specified that:
"signing-key" NL a public key in PEM format
[Exactly once]
The OR's long-term identity key. It MUST be 1024 bits.
and
"onion-key" NL a public key in PEM format
[Exactly once]
This key is used to encrypt CREATE cells for this OR. The key MUST be
accepted for at least 1 week after any new key is published in a
subsequent descriptor. It MUST be 1024 bits.
However, according to this commit added to Stem in legacy/trac#5810 (closed), verifying signatures created with the signing-key
isn't so easy. With that code, Stem is able to verify descriptor signatures created by Tor, yet not those created by Leekspin, which clearly means the spec is unclear on this matter (and Leekspin is Doing It Wrong).
My current understanding after looking at crypto_pk_public_checksig()
in Tor, the OpenSSL source, and Stem's signature verification code above is that the signing-key
and onion-key
are formatted as follows:
- OpenSSL PEM-encoded export of public halves of keys.
- The PEM-encoded keys are stripped of their
----BEGIN...
and-----END...
headers. - The keys are then PKCS!#1 padded.
- Next, the PKCS!#1-padded, PEM-encoded raw keys are encoded as an ASN.1 DER sequence.
- That ASN.1 DER sequence is then base64 encoded.
- Finally, the
-----BEGIN...
and-----END...
headers are stuck back on the keys, and they are shoved into the descriptor.
Questions:
-
Is the above understanding of the order of encodings correct?
-
Which version of PCKS!#1? Any version? Anything newer than v1.5? Only v2.0?
-
I understand the use of PKCS!#1 to protect against padding attacks, but doesn't Bleichenbacher's attack still work against PKCS!#1 v1.0?
-
Why aren't we using the PKCS!#1 probabilistic signature schemes (RSASSA-PSS/EMSA-PSS) used in PKCS!#1 v2.0?
-
For the signatures, the descriptor document "through the newline on the
router-signature
line" is PKCS!#1-padded, then digested. Does this include the newline character? -
Also, the spec is unclear as to whether
- the ''descriptor document'' is PKCS!#1-padded, then digested, then signed, or
- the descriptor document is digested, then signed, and the ''signature'' is PKCS!#1-padded. {{{ "router-signature" NL Signature NL
[At end, exactly once]
The "SIGNATURE" object contains a signature of the PKCS1-padded hash of the entire router descriptor, taken from the beginning of the "router" line, through the newline after the "router-signature" line. The router descriptor is invalid unless the signature is performed with the router's identity key. }}}
-
Is it any specific type of ASN.1 DER sequence?
-
Why are we using ASN.1? Does it protect against something? It just seems to send parsers to early graves. Why can't we just do the base64 encoding after PKCS!#1?
-
Why? Oh why? Cthulhu fhtagn... Why? The insanity...