Note that Phantom allows both the service and the
client to choose the number of hops under their
respective control. I believe this applies in part to
I2P as well. There is thus no force to accept
any globally enforced maximum hopcount there.
This concept may or not work for Tor.
_
Hi all,
Apologies for top-posting. I'm making a brief comment about general
concerns in this design. Additional apologies if something already
said obviates my comments. I have purposely not looked at most of the
developments in HS design changes because they are _too_ interesting
to me and I have
On Wed, Feb 12, 2014 at 6:15 AM, Abhiram Chintangal <
abhiram.chintan...@gmail.com> wrote:
>
> On 02/05/2014 07:59 PM, Philipp Winter wrote:
>
>>
>> Regarding development and coordination: This mailing list is great for
>> high-latency, broad, conceptual, and public discussions. For low-latency
>
On Tue, Feb 11, 2014 at 9:07 PM, Zack Weinberg wrote:
> (3) Service transmits to Client:
>
> { E_b(Fs), E_b(Fg), E_b(F1), ..., E_b(Fn), F1, ..., Fn }_s
>
> where Fs is the fingerprint of the service itself, Fg the fingerprint
> of the service's selected guard, and F1...Fn the fingerprints of t
On 02/05/2014 07:59 PM, Philipp Winter wrote:
Regarding development and coordination: This mailing list is great for
high-latency, broad, conceptual, and public discussions. For low-latency
questions, the #tor-dev channel on OFTC is better.
Should I create a temporary wiki-page at tor/wiki ?
On 02/11/2014 11:55 AM, Qingping Hou wrote:
> Hi all,
>
> We are a university research group and following is a proposal for
> possible optimization on Tor's rendezvous circuit design. It's not
> written as a formal Tor proposal yet because I want to have a
> discussion with the community first, ge
On 02/11/2014 04:51 PM, Roger Dingledine wrote:
> On Tue, Feb 11, 2014 at 11:55:05AM -0500, Qingping Hou wrote:
>> (0) client fetches descriptor for a hidden service.
>> (1) client connects to introduction point.
>> (2) since client and HS are connected via introduction point, they can
On 02/11/2014 01:53 PM, George Kadianakis wrote:
>> 2. Negotiate random numbers between two nodes [RAND_NEGO]
>>
>> H(a) here means digest of message a.
>>
>> (1) client generates a random number R_a and sends the digest H(R_a) to
>> HS
>> (2) HS remembers H(R_a), generates a random nu
On Tue, Feb 11, 2014 at 11:55:05AM -0500, Qingping Hou wrote:
> (0) client fetches descriptor for a hidden service.
> (1) client connects to introduction point.
> (2) since client and HS are connected via introduction point, they can
> negotiate a random number using this channe
Qingping Hou writes:
> Hi all,
>
> We are a university research group and following is a proposal for possible
> optimization on Tor's rendezvous circuit design. It's not written as a formal
> Tor proposal yet because I want to have a discussion with the community first,
> get some feedbacks and
Hi all,
We are a university research group and following is a proposal for possible
optimization on Tor's rendezvous circuit design. It's not written as a formal
Tor proposal yet because I want to have a discussion with the community first,
get some feedbacks and make sure it does not introduce ne
BTW, we might be able reduce number of hops to 4 or even 3 if entry
guard is not required. Because entry guard is basically not negotiable.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-de
12 matches
Mail list logo
