On 11/24/2016 2:24 AM, Jesse V wrote:
> On 11/23/2016 07:04 PM, Yawning Angel wrote:
>> Our fix: "Add another command, that does essentially the same thing,
>> because people picked the wrong options, then later deal with the
>> fallout from people getting used to the temporary command, and crying
On 11/23/2016 07:04 PM, Yawning Angel wrote:
> Our fix: "Add another command, that does essentially the same thing,
> because people picked the wrong options, then later deal with the
> fallout from people getting used to the temporary command, and crying
> when it's deprecated."
>
> I say "they s
On Thu, 24 Nov 2016 11:13:06 +1100
teor wrote:
> > On 24 Nov. 2016, at 11:04, Yawning Angel
> > wrote:
> >
> > On Thu, 24 Nov 2016 01:43:15 +0200
> > s7r wrote:
> >> I agree that this would be "the technical way" to do it, but real
> >> world usability kind of prevents us to do it this way.
> On 24 Nov. 2016, at 11:04, Yawning Angel wrote:
>
> On Thu, 24 Nov 2016 01:43:15 +0200
> s7r wrote:
>> I agree that this would be "the technical way" to do it, but real
>> world usability kind of prevents us to do it this way. The spec for
>> ADD_ONION indeed does not say that v2 hidden servi
> On 24 Nov. 2016, at 10:56, s7r wrote:
>
>
> teor wrote:
>>
>>>
>>> Very good. We can add a new torrc option for ed25519 key based
>>> authentication for clients (v3) so the current
>>> HiddenServiceAuthorizeClient (v2) will not break old torrc's until
>>> everyone upgrades.
>>>
>>> However
teor wrote:
> No-one is proposing we abolish ADD_ONION with v2 services straight away.
>
> What we will do is make BEST mean v3, rather than v2.
> RSA1024 will continue to mean v2, as it always has.
>
> ADD_ONION has always had an explicit BEST option, if clients don't want
> the BEST type of key
On Thu, 24 Nov 2016 01:43:15 +0200
s7r wrote:
> I agree that this would be "the technical way" to do it, but real
> world usability kind of prevents us to do it this way. The spec for
> ADD_ONION indeed does not say that v2 hidden services will be
> supported forever and it clearly SHOULD NOT, but
teor wrote:
>
>>
>> Very good. We can add a new torrc option for ed25519 key based
>> authentication for clients (v3) so the current
>> HiddenServiceAuthorizeClient (v2) will not break old torrc's until
>> everyone upgrades.
>>
>> However, we could just add an auth-type value after
>> HiddenServi
> On 24 Nov. 2016, at 10:43, s7r wrote:
>
>
> teor wrote:
How does ADD_ONION fit in?
>>>
>>> It's forward compatible by design, since you have to specify a key type
>>> when you handle key management, and Tor gets to do whatever it wants if
>>> you ask it to generate a key with the
teor wrote:
>>>
>>> How does ADD_ONION fit in?
>>
>> It's forward compatible by design, since you have to specify a key type
>> when you handle key management, and Tor gets to do whatever it wants if
>> you ask it to generate a key with the `BEST` algorithm.
>>
>> Assuming people who use it aren't
On Thu, 24 Nov 2016 01:18:46 +0200
s7r wrote:
> Yes, this looks good to me as well. As for ADD_ONION, I think we
> should give the people that use it automatically for other apps a
> change until they upgrade to be compatible with v3, so for the
> transition period as long as v2 is supported (but
> On 24 Nov. 2016, at 10:18, s7r wrote:
>
> Hello David,
>
> David Goulet wrote:
>> Hi everyone!
>>
>> We are soon at the stage of implementing the service part of proposal 224
>> (next gen. hidden service.). Parent ticket is #20657 but I'll be discussing
>> here ticket #18054.
>>
>> In a nut
> On 24 Nov. 2016, at 09:00, Yawning Angel wrote:
>
> On Wed, 23 Nov 2016 03:12:22 +0400
> meejah wrote:
>
>> David Goulet writes:
>>
>>> 1) Once v3 is released, from that point on _no_ v2 service will be
>>> allowed to be created by "tor" itself. It will always be possible
>>> to do it by h
Hello David,
David Goulet wrote:
> Hi everyone!
>
> We are soon at the stage of implementing the service part of proposal 224
> (next gen. hidden service.). Parent ticket is #20657 but I'll be discussing
> here ticket #18054.
>
> In a nutshell, we need to figure out the interface for the torrc f
On Wed, 23 Nov 2016 03:12:22 +0400
meejah wrote:
> David Goulet writes:
>
> > 1) Once v3 is released, from that point on _no_ v2 service will be
> > allowed to be created by "tor" itself. It will always be possible
> > to do it by hand by creating an RSA key and putting it in the
> > service di
> On 24 Nov. 2016, at 06:09, Jesse V wrote:
>
> On 11/23/2016 09:39 AM, David Goulet wrote:
>> I agree with you on the fact that ADD_ONION is nice and also crucial to
>> hidden
>> service as well. That will be addressed with the control port implementation
>> of next generation. It's still an u
On 11/18/2016 10:30 AM, ban...@openmailbox.org wrote:
> New research on Distributed RNGs is published: "Scalable Bias-Resistant
> Distributed Randomness"
>
> eprint.iacr.org/2016/1067
Nice! There's also https://eprint.iacr.org/2015/1015.pdf, which shows
that you can extract at least 32 bits of en
On 11/23/2016 09:39 AM, David Goulet wrote:
> I agree with you on the fact that ADD_ONION is nice and also crucial to hidden
> service as well. That will be addressed with the control port implementation
> of next generation. It's still an undecided part of the engineering work which
> is how we ar
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi there!
More than five years of development [0] led to the very first
release of Onionoo, which is now available here:
https://dist.torproject.org/onionoo/3.1-1.0.0/
For those who haven't heard of Onionoo:
Onionoo [0] is a web-based pro
Nick Mathewson writes:
> [ text/plain ]
> Hi! I thought I'd write this up while it was fresh in my mind. It
> could be used as an alternative method to the current proposed client
> authentication mechanism. We could implement both, or just this, or
> just the other.
>
> My description here wi
On 23 Nov (03:12:22), meejah wrote:
> David Goulet writes:
>
> > 1) Once v3 is released, from that point on _no_ v2 service will be allowed
> > to
> >be created by "tor" itself. It will always be possible to do it by hand
> > by
> >creating an RSA key and putting it in the service direc
21 matches
Mail list logo
