[tor-dev] Specification for 'How to Safely Sign a statement with a .onion key'

Nick Mathewson nickm at freehaven.net
Mon Dec 1 14:14:03 UTC 2014

On Sun, Nov 30, 2014 at 1:19 PM, Ian Goldberg <iang at 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 at 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.


More information about the tor-dev mailing list