Specification for 'How to Safely Sign a statement with a .onion key'
Attached is a document written in the specification format for one aspect of CA-signed .onion addresses - specifically a "What is a safe way to sign (or not sign) a statement using the .onion key" It presents a couple options - I'd love to get feedback from folks on which they prefer. I recognize that no consensus or decision has been reached on whether to encourage or guide CAs on issuing .onions. (Although I'm in favor[0].) Although this is obviously written skewed towards CAs, it addresses a generic problem, and could be rewritten in that form. Excerpting from the Introduction/Motivation: Several organizations, such as Facebook, (collectively, 'applicants') have expressed a desire for an end-entity SSL certificate valid for their .onion Hidden Service address signed by a Certificate Authority (CA) present in browser trust stores. The existing Facebook .onion URL was issued by Digicert under a loophole in certificate issuance requirements. The Basic Requirements [0] is a document created by the Certificate Authority/Browser Forum that governs acceptable certificate issuing policies. Adherence to its policies is required for inclusion in many browsers' trust stores. .onion counts as an 'internal hostname' as it is not a recognized TLD by IANA. November 1, 2015 sets the deadline for when all internal server certificates must be revoked and no new certificates may be issued. Resolving the requirements and preferences for issuing .onion certificates before this date is extremely desirable, as it will determine if organizations such as Facebook will invest in the time and engineering effort needed to deploy Hidden Services. The full requirements for issuing .onion certificates is TBD, although recognition of .onion by IANA as a reserved domain is likely required. During discussions about the requirements for issuing for .onion one question that has arisen is what is a safe way to assert ownership of a .onion address and format an x509 certificate with a .onion Subject Alternate Name (SAN). This document is designed to address some of those questions. -tom [0] https://lists.torproject.org/pipermail/tor-dev/2014-November/007786.html
Some hidden services have been signing various things with their HS keys. Even benefit may exists from moving from 1024 to 4k+ and add passphrased startup option while keeping 80bit for now. There may already be ticket on this area.
On 24 Nov 2014, at 18:54, Tom Ritter <tom@ritter.vg> wrote:
Attached is a document written in the specification format for one aspect of CA-signed .onion addresses - specifically a "What is a safe way to sign (or not sign) a statement using the .onion key" It presents a couple options - I'd love to get feedback from folks on which they prefer.
An alternative scheme could be to take advantage of the fact that Tor does not RSA sign the descriptor itself but a SHA-1 hash of the descriptor. So if the signature for the purpose of getting a CA to accept the request uses a different hash function then there should not be any confusion. For example, rather than using the SHA-1 hash, use the SHA-1 HMAC under a hard-coded “key”. For the attacker to abuse this signature they would need to find a document which hashes to the same thing. This sounds like (but should be checked) to have the same difficulty as performing a collision attack (2^80 best case, 2^60 using cryptanalytic attacks). A convenient result of this scheme is that changing the “key” lets the same onion key be used for other purposes, and if the key is well chosen then the chances of someone using the same approach is negligible. Best wishes, Steven
On Fri, Nov 28, 2014 at 03:22:18PM +0000, Steven Murdoch wrote:
On 24 Nov 2014, at 18:54, Tom Ritter <tom@ritter.vg> wrote:
Attached is a document written in the specification format for one aspect of CA-signed .onion addresses - specifically a "What is a safe way to sign (or not sign) a statement using the .onion key" It presents a couple options - I'd love to get feedback from folks on which they prefer.
An alternative scheme could be to take advantage of the fact that Tor does not RSA sign the descriptor itself but a SHA-1 hash of the descriptor. So if the signature for the purpose of getting a CA to accept the request uses a different hash function then there should not be any confusion.
For example, rather than using the SHA-1 hash, use the SHA-1 HMAC under a hard-coded “key”. For the attacker to abuse this signature they would need to find a document which hashes to the same thing. This sounds like (but should be checked) to have the same difficulty as performing a collision attack (2^80 best case, 2^60 using cryptanalytic attacks).
A convenient result of this scheme is that changing the “key” lets the same onion key be used for other purposes, and if the key is well chosen then the chances of someone using the same approach is negligible.
While finding M1 and M2 such that SHA-1-HMAC(k1,M1) = SHA-1-HMAC(k2,M2) should be difficult for k1 \not= k2, even when k1 and k2 are known, it is easy to find M2 (given k1 and M1) such that SHA-1-HMAC(k1,M1) = SHA-1(M2), by the construction of HMAC, right? Something like: M2 = (k1 \xor opad) || SHA-1[ (k1 \xor ipad) || M1 ] ? So I think the above is dangerous. - Ian
On Sun, Nov 30, 2014 at 1:19 PM, Ian Goldberg <iang@cs.uwaterloo.ca> wrote:
On Fri, Nov 28, 2014 at 03:22:18PM +0000, Steven Murdoch wrote:
On 24 Nov 2014, at 18:54, Tom Ritter <tom@ritter.vg> wrote:
Attached is a document written in the specification format for one aspect of CA-signed .onion addresses - specifically a "What is a safe way to sign (or not sign) a statement using the .onion key" It presents a couple options - I'd love to get feedback from folks on which they prefer.
An alternative scheme could be to take advantage of the fact that Tor does not RSA sign the descriptor itself but a SHA-1 hash of the descriptor. So if the signature for the purpose of getting a CA to accept the request uses a different hash function then there should not be any confusion.
For example, rather than using the SHA-1 hash, use the SHA-1 HMAC under a hard-coded “key”. For the attacker to abuse this signature they would need to find a document which hashes to the same thing. This sounds like (but should be checked) to have the same difficulty as performing a collision attack (2^80 best case, 2^60 using cryptanalytic attacks).
A convenient result of this scheme is that changing the “key” lets the same onion key be used for other purposes, and if the key is well chosen then the chances of someone using the same approach is negligible.
While finding M1 and M2 such that SHA-1-HMAC(k1,M1) = SHA-1-HMAC(k2,M2) should be difficult for k1 \not= k2, even when k1 and k2 are known, it is easy to find M2 (given k1 and M1) such that SHA-1-HMAC(k1,M1) = SHA-1(M2), by the construction of HMAC, right? Something like:
M2 = (k1 \xor opad) || SHA-1[ (k1 \xor ipad) || M1 ]
?
So I think the above is dangerous.
Then how about specifying something like this for the RSA-signed part (in place of the SHA1): [fixed string] 8 bytes [SHA512 signature] 32 bytes Where the fixed sting could be something like "HSNONTOR", and we can reserve other strings for later if we actually do want to support RSA signatures over SHA512. -- Nick
On Mon, Dec 01, 2014 at 09:14:03AM -0500, Nick Mathewson wrote:
Then how about specifying something like this for the RSA-signed part (in place of the SHA1): [fixed string] 8 bytes [SHA512 signature] 32 bytes
Where the fixed sting could be something like "HSNONTOR", and we can reserve other strings for later if we actually do want to support RSA signatures over SHA512.
What kind of signature padding is done by the signature using the HS key today? I would be less wary if the *plaintext* (pre-hash) started with the above fixed string, and then some sensible padding mode (e.g., OAEP(+?)) was put on top of it. - Ian
On Mon, Dec 1, 2014 at 9:30 AM, Ian Goldberg <iang@cs.uwaterloo.ca> wrote:
On Mon, Dec 01, 2014 at 09:14:03AM -0500, Nick Mathewson wrote:
Then how about specifying something like this for the RSA-signed part (in place of the SHA1): [fixed string] 8 bytes [SHA512 signature] 32 bytes
Where the fixed sting could be something like "HSNONTOR", and we can reserve other strings for later if we actually do want to support RSA signatures over SHA512.
What kind of signature padding is done by the signature using the HS key today? I would be less wary if the *plaintext* (pre-hash) started with the above fixed string, and then some sensible padding mode (e.g., OAEP(+?)) was put on top of it.
I believe Tor still uses PKCS1 padding for RSA signatures and OAEP for RSA encryption.
On Mon, Dec 01, 2014 at 09:59:57AM -0500, Nick Mathewson wrote:
On Mon, Dec 1, 2014 at 9:30 AM, Ian Goldberg <iang@cs.uwaterloo.ca> wrote:
On Mon, Dec 01, 2014 at 09:14:03AM -0500, Nick Mathewson wrote:
Then how about specifying something like this for the RSA-signed part (in place of the SHA1): [fixed string] 8 bytes [SHA512 signature] 32 bytes
Where the fixed sting could be something like "HSNONTOR", and we can reserve other strings for later if we actually do want to support RSA signatures over SHA512.
What kind of signature padding is done by the signature using the HS key today? I would be less wary if the *plaintext* (pre-hash) started with the above fixed string, and then some sensible padding mode (e.g., OAEP(+?)) was put on top of it.
I believe Tor still uses PKCS1 padding for RSA signatures and OAEP for RSA encryption.
If you can restrict the set of values that the input to the hash can start with (for the "real" usage of the key), then signing messages starting with other fixed strings should be fine. (I think Douglas Stebila's CCS paper last month talks about something similar, in the context of ssh's and TLS's reuse of signing key material across ciphersuites.) It also avoids the problem the above proposal has of making the verification nonstandard. - Ian
participants (5)
-
grarpamp -
Ian Goldberg -
Nick Mathewson -
Steven Murdoch -
Tom Ritter