[tor-dev] Hidden Service Scaling

[Christopher Baines]

On 06/05/14 20:13, Nicholas Hopper wrote:
> On Sat, May 3, 2014 at 5:58 AM, Christopher Baines <cbaines8 at gmail.com> wrote:
>> On 03/05/14 11:21, George Kadianakis wrote:
>>>> On 08/10/13 06:52, Christopher Baines wrote:
>>>> In short, I modified tor such that:
>>>>  - The services public key is used in the connection to introduction
>>>> points (a return to the state as of the v0 descriptor)
>>>
>>> Ah, this means that now IPs know which HSes they are serving (even if
>>> they don't have the HS descriptor). Why was this change necessary?
>>
>> If the "service key"'s (randomly generated keys per introduction point)
>> are used, then this would complicate/cause problems with the multiple
>> instances connecting to one introduction point. Only one key would be
>> listed in the descriptor, which would only allow one instance to get the
>> traffic.
>>
>> Using the same key is good. Using the services key, is not great. One
>> possible improvement might be to generate a key for an introduction
>> point based off the identity of the introduction point, plus some other
>> stuff to make it secure.
> 
> Would it make sense to solve this problem using a similar approach to
> the key blinding described in proposal 224?  For example, if the
> public key is g^x and the introduction point has identity (e.g.
> fingerprint) y, then the IP blinding factor would be
> 
> t_{IP} = Hash(y | g^x)
> 
> and the IP-specific public key would be
> 
> P_{IP} = g^{x*t_{IP}}
> 
> This way the IP doesn't learn what HS it's serving if it doesn't know
> the descriptor, but any HS server that knows the secret key (x) can
> compute the IP secret key x*t.

Yes, from the non-mathematical explanation, that seems to fit the
requirements fine.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20140506/4b283014/attachment.sig>