[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #13042 [Tor]: torspec isn't very clear about the encodings used for `onion-key` and `signing-key`
#13042: torspec isn't very clear about the encodings used for `onion-key` and
`signing-key`
-------------------------+-------------------------------------------------
Reporter: isis | Owner:
Type: defect | Status: new
Priority: normal | Milestone:
Component: Tor | Version:
Resolution: | Keywords: torspec, leekspin, stem, bridgedb,
Actual Points: | tor-descriptors
Points: | Parent ID:
-------------------------+-------------------------------------------------
Comment (by nickm):
Replying to [ticket:13042 isis]:
> 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
[https://gitweb.torproject.org/stem.git/commitdiff/e0095fbe54759c45cbf6d1b120d2b17b47a0ec21
this commit] added to Stem in #5810, 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
[https://gitweb.torproject.org/user/isis/leekspin.git/blob/HEAD:/leekspin/generator.py#l89
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:
>
> 1. OpenSSL PEM-encoded export of public halves of keys.
> 2. The PEM-encoded keys are stripped of their `----BEGIN...` and
`-----END...` headers.
> 3. The keys are then PKCS!#1 padded.
> 4. Next, the PKCS!#1-padded, PEM-encoded raw keys are encoded as an
ASN.1 DER sequence.
> 5. That ASN.1 DER sequence is then base64 encoded.
> 6. 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?
That sounds pretty weird. It's just whatever PEM_write_bio_RSAPublicKey
does. That's documented in the "pem" manpage for openssl. (in the
openssl distro as doc/crypto/pem.pod). That seems to be implemented in
terms of a bunch of macros in crypto/pem/pem.h, which then use
i2d_RSAPublicKey. Those are just doing asn.1 encoding/decoding, as
implemented in crypto/rsa/rsa_ameth.h
No, it's not exactly pretty, but asn.1 never is.
> * Which version of PCKS!#1? Any version? Anything newer than v1.5?
Only v2.0?
Do they encode RSA public keys differently?
> * I understand the use of PKCS!#1 to protect against padding attacks,
but doesn't [https://en.wikipedia.org/wiki/Adaptive_chosen-
ciphertext_attack#Practical_attacks Bleichenbacher's attack] still work
against PKCS!#1 v1.0?
That's not relevant for key encoding, surely?
Also, it's not relevant for signatures; only encryption.
> * Why aren't we using the PKCS!#1 probabilistic signature schemes
(RSASSA-PSS/EMSA-PSS) used in PKCS!#1 v2.0?
PSS wasn't widely available enough when we started making server
descriptors. The reason we don't change is that we don't use RSA to sign
anything secret and then reveal the signature without the secret.
> * 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?
Yes.
> * Also, the spec is unclear as to whether
> 1. the ''descriptor document'' is PKCS!#1-padded, then digested,
then signed,
> or
> 2. the descriptor document is digested, then signed, and the
''signature'' is PKCS!#1-padded.
Digest, then pad, then sign. (Padding a signature does no good and
protects against nothing.)
> {{{
> "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?
I think you might be confusing encoding and padding? We don't use ASN.1
in generating signatures; we're only using it for key encoding.
Similarly, we don't use PKCS1 padding for encoding keys; we only use it
the signatures here.
The reason "why" is "that's how openssl likes to encode public keys."
> * ''Why? Oh why? Cthulhu fhtagn... Why? The insanity...''
You write a protocol, maintain it for a decade, and this kind of thing
seems bound to happen...
Or to be more constructive ...This is the perfect opportunity for you to
review proposals 220 and 228, since they are about to add new signature
types, and look for ambiguities. (224 too if you're feeling brave) ;)
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/13042#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs