One of the current unfortunate properties of hidden services is that
the identity of the hidden service is its public key (or the
equivalent hash, in the current setup), and this key must always be
available for signing on an online host (usually the HS itself, though
potentially on a bastion host)
On Sat, Dec 28, 2013 at 6:46 AM, Gregory Maxwell wrote:
> One of the current unfortunate properties of hidden services is that
> the identity of the hidden service is its public key (or the
> This is pretty bad for prudent key management— the key is very high
> value because its difficult to chan
On Sat, Dec 28, 2013 at 1:15 PM, grarpamp wrote:
> On Sat, Dec 28, 2013 at 6:46 AM, Gregory Maxwell wrote:
>> One of the current unfortunate properties of hidden services is that
>> the identity of the hidden service is its public key (or the
>
>> This is pretty bad for prudent key management— th
On 12/28/2013 06:46 AM, Gregory Maxwell wrote:
> One of the current unfortunate properties of hidden services is that
> the identity of the hidden service is its public key (or the
> equivalent hash, in the current setup), and this key must always be
> available for signing on an online host (usual
On Sat, Dec 28, 2013 at 4:15 PM, grarpamp wrote:
> On Sat, Dec 28, 2013 at 6:46 AM, Gregory Maxwell wrote:
>> One of the current unfortunate properties of hidden services is that
>> the identity of the hidden service is its public key (or the
>
>> This is pretty bad for prudent key management— th
Qingping Hou writes:
> On 12/28/2013 06:46 AM, Gregory Maxwell wrote:
>> One of the current unfortunate properties of hidden services is that
>> the identity of the hidden service is its public key (or the
>> equivalent hash, in the current setup), and this key must always be
>> available for sig
