[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[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:
Keywords: torspec, leekspin, stem, bridgedb, | Actual Points:
tor-descriptors | Points:
Parent ID: |
-------------------------------------------------+-------------------------
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?
* 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 [https://en.wikipedia.org/wiki/Adaptive_chosen-
ciphertext_attack#Practical_attacks 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
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.
{{{
"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...''
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/13042>
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