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

[Nick Mathewson]

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.

-- 
Nick