to be part of the filter or
prioritisation or both)
Some suggestions about how to fix some complex issues.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
OTR 8F39BCAC 9C9DDF9A DF5FAE48 1D7D99D4 3B406880
ricochet:ekmygaiu4rzgsk6n
to be part of the filter or
prioritisation or both)
Some suggestions about how to fix some complex issues.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
OTR 8F39BCAC 9C9DDF9A DF5FAE48 1D7D99D4 3B406880
ricochet:ekmygaiu4rzgsk6n
n the HS cache, but hidden services don't cache
their own descriptors?
Perhaps HSFETCH doesn't look at HidServAuth?
Perhaps HSFETCH shouldn't try to decrypt the descriptor before delivering it?
Perhaps it should?
I encourage you to log an issue for eac
estions for small changes before merging.
>
> Thanks,
> Iain.
>
> [1]: https://trac.torproject.org/projects/tor/ticket/5430
> [2]: https://trac.torproject.org/projects/tor/ticket/6787
> _______
> tor-dev mailing list
> tor-dev@lists.t
need to specify
it all in one place, and then convince a cryptographer to review it. (I am not
a cryptographer.) And then have your implementation reviewed against the spec.
How is the card you're using for side-channels?
Keys have beed extracted using power usage information, or electromag
ncrypt traffic from/to that node.
An attacker can prevent the node from getting some of the traffic. Typically,
the attacker will control the descriptor on each of the 6 hidden service
directories until the hidden service uploads a new one. All connections made by
clients using attacker-control
hash, that takes long
enough to calculate, and you use all the bits of the hash, and you check the
dates you're signing, and you rate-limit signing. But that means a lot of
moving pieces which can go wrong. And it likely means some attacks you haven't
thought of.
Tim
Tim Wilson
n hidden service protocol (proposal 224). It could be released in
0.2.9, and it could be running on enough authorities some time in 2017.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
ricochet:ekmygaiu4rzgsk6n
signature.asc
Description: Message signed with OpenPGP using GPGM
is not, due to network effects - a CoSi signer may
sign one request, but go down before signing them all.)
A third is for CoSi signatures to be appended to the consensus, just like
authority signatures are appended. Then authorities, mirrors, and clients only
serve consensuses with a majority (5/9
n case, if we really
needed to.
But do we really need to?
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
ricochet:ekmygaiu4rzgsk6n
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@
onger term, but in
the interim, it means an increase in memory usage.
Please feel free to let us know if this is a pressing issue for you, and we'll
see what we can do.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
ricochet:ekmygaiu4rzgsk6n
signature.as
;re replying to.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
ricochet:ekmygaiu4rzgsk6n
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://li
ilar to how the previous shared random value is determined.
I've added #19045 to keep track of this:
https://trac.torproject.org/projects/tor/ticket/19045
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
ricochet:ekmygaiu4rzgsk6n
signature.asc
Description: Message signe
> On 11 May 2016, at 12:49, Tim Wilson-Brown - teor wrote:
>
>>
>> On 11 May 2016, at 12:38, Nicholas R. Parker (RIT Student)
>> wrote:
>>
>> Hey again all, got another one for you.
>> When we've started adding bridges to the network, they send
dges 0|1
When set, Tor will fetch descriptors for each bridge listed in the
"Bridge" config lines, and use these relays as both entry guards
and directory guards. (Default: 0)
If you need more detail, I'd encourage you to read the other tor manual en
, but it's also worth testing with multiple exit relays to
ensure your code doesn't depend on their only being 1 exit.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
ricochet:ekmygaiu4rzgsk6n
signature.asc
Descriptio
> On 8 May 2016, at 02:46, Roger Dingledine wrote:
>
> On Sun, May 08, 2016 at 02:04:23AM -0400, Tim Wilson-Brown - teor wrote:
>>> ??? Each client will have a cache-microdesc-consensus file with 4
>>> relays in it. relay 0, 1 and 2 will always be there and the
likely that some of the relays are configured with the wrong
addresses and ports (either in the torrc or in the OS), or aren't actually
connected to your network properly at lower layers, such as TCP or IP or
ethernet.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
ric
2*v3)
>
> In this description, round() returns the closest integer and abs() returns the
> absolute value.
> Note that all computations involved in helprec operate on secret data and must
> be protected against timing attacks.
round() is underspecified here: does 0.5 round to 0
he network), the hanging issue resolves itself..
Hmm, then it's likely a configuration issue with your network.
> I'll try rebase back to an official release today.
That might help, we are still fixing bugs in 0.2.8.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
like a lack of nodes in the consensus.
Without context from the logs, it's hard to tell whether it's testing circuits
or standard circuits that are causing the path failures.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
ricochet:ekmygaiu4rzgsk6n
And I think having a completely separate list is wise for all sorts of reasons.
One request: please don't call this new list "fallback directory mirrors".
Relay operators who consented to being fallback directory mirrors did not
consent to other uses for their relay.
So while we could
thVoteExit
TestingDirAuthVoteExitIsStrict 1
You could try comparing the options that chutney sets with the "real network"
options you're using, and switching one chutney option to a real network option
until the bug occurs.
Remember that "TestingTorNetwork" changes a lot
serve each others' descriptors in order for clients to obtain
the fallback keys, this extra bandwidth needs to be accounted for.
If a descriptor is 1.5KB, and you need to download 100 of them, that's an extra
1.5MB at bootstrap time.
Microdescriptor consensuses are 1.3MB.
So that
itialDistDelay 20
>
> Nicholas R. Parker
> Rochester Institute of Technology
> 5thYear, BS/MS Computing Security
> 585-794-0029 / nrp7...@rit.edu
>
> On Sun, Apr 10, 2016 at 11:41 PM, Tim Wilson-Brown - teor
> wrote:
>
> > On 11 Apr 2016, at 09:28, Nicholas
the
implementation, it could well become one.
I'd want to make sure we really needed this feature before implementing it.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
ricochet:ekmygaiu4rzgsk6n
signature.asc
Description: Message signed with OpenPGP using GPGMail
though it's could be fixed and be more accurate, it's unlikely to be the
source of the issues you're having.
I also can't see how the issue you describes relates to the commit you linked
to: 62fb209d837f3f5510075ef8bdb6e231ebdfa9bc.
If it still concerns you, can you check you h
] https://github.com/globaleaks/Tor2web/wiki/Installation-Guide
>
> Best,
> Juha
> _______
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mail
nd hidden services can have before TLS or Tor-specific
crypto fails?
Does anyone want to spin up a VM and work this out?
In the interim, let's assume the crypto will work, and modify the proposal with
a larger clock skew.
Tim
[0]: https://en.wikipedia.org/wiki/List_of_UTC_time_offsets
Ti
rceful) entry guard. The prediction model would help the client
> to stay anonymous as it would refrain from unnecessarily switching
> guard nodes.
Are you aware of the existing CircuitBuildTimeout option, and the existing
dynamic model used to predict timeouts?
If you gradually increase the
or-onions mailing list is to discuss the technical details running
onion services.
Can we discuss onioncat, tor, and the development of prop224 on tor-dev mailing
list?
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
ricochet:ekmygaiu4rzgsk6n
signature.asc
Description: M
f. I
encourage you to try some of the things I've suggested, and ask more precise
questions next time.
Personally, I would find it easier to respond to targeted questions that come
one at a time, every few days or every week, rather than a large email every
few weeks.
It might also be he
> On 20 Apr 2016, at 07:22, David Goulet wrote:
>
> On 18 Apr (13:18:25), George Kadianakis wrote:
>> Tim Wilson-Brown - teor writes:
>>
>>> [ text/plain ]
>>>
>>>> On 16 Apr 2016, at 05:47, David Goulet wrote:
>>>>
&g
the same time.
I also wonder about the impact on path selection and client security - even an
honest operator can have their relays compromised or be compelled to provide
information.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
ricochet:ekmygaiu4rzgsk6n
m is O(Kn), which is ok as long as K is small.
This carries a slight risk of over-deallocating cache entries. Which is OK at
OOM time.
I like this one, because it's simple, performant, and doesn't need any extra
memory allocations.
Tim
Tim Wilson-Brown (teor)
teor2345 at
l-over.
Perhaps we should have a default, and then allow the period to be changed (like
in the current code).
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
ricochet:ekmygaiu4rzgsk6n
signature.asc
Description: Message signed with OpenPGP using GPGMail
6 hours? It's unlikely that the HS is still up and
>>> maintaining its intro circuits if it can't keep on refreshing its
>>> descriptor.
>>
>> The issue here is for the HSDir to notice that the HS might be gone? And we
>> can't rely on RendPostPer
on Services, like whether you can open a SOCKSPort or run Tor2Web.
We could add a compilation option --enable-single-onion-mode instead of
NonAnonymousMode, but I think making Single Onion Service operators compile
their own tor is unnecessary.
Tim
>
> --
> Ivan Markin
> ___
> On 12 Apr 2016, at 04:22, David Goulet wrote:
>
> On 08 Apr (10:15:19), Tim Wilson-Brown - teor wrote:
>> Hi All,
>>
>> I'm working on proposal 260's Rendezvous Single Onion Services in #17178.
>>
>> They are faster, because they have one hop
any failures, copy and paste the torrc, and the error
messages you're getting, and tell us what you've tried already.
(You can anonymise IP addresses if you need to, as long as it's clear which
ones are the same.)
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail do
figure
the user and permissions correctly?
Tor also has more specific requirements for security reasons, this protects the
keys from other users on the system.
It's hard to give more advice without more specific details.
If this advice doesn't help, please copy and paste the configurat
ling reasons against that design.
I hope that this will allow us to get SingleOnionMode merged early in tor 0.2.9.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
ricochet:ekmygaiu4rzgsk6n
signature.asc
Description: Message signed with OpenPGP using GPGMail
_
he test name.
chutney is slow, but it's used for whole-program and whole-network integration
tests.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
ricochet:ekmygaiu4rzgsk6n
signature.asc
Description: Message signed with OpenPGP using GPGMail
warn the user.
But we never considered failing closed in these circumstances: what if the user
just wants circumvention, and not anonymity?
https://trac.torproject.org/projects/tor/ticket/17849
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
ricochet:ekmygaiu4rzgsk6n
ting, and hard to discover during modelling.
Using a malicious guard has similar consequences to Tor failing closed, and
users switching to a non-tor browser.
I'm not sure which is worse. It probably depends on the user. But we should try
to avoid both scenarios.
Tim
Tim Wilson-Brown (teor)
less than X (5?) guards,
> expand SAMPLED guards using the regular process.
> - If SAMPLE guards reach SAMPLED_MAX (50?) size, we fail closed with
> an error saying something like "your current network settings make it
> impossible for us to safely choose an entry guard. If you
n based on
the connection type, use Tor's existing TCP socket implementation, or the QUIC
implementation.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
signature.asc
Descrip
ment of at the
> _very_ least the overlap period. If the overlap period is 6 hours, we can then
> add the "maximum clock skew" we think is reasonable and we would end up with
> an OK value imo.
>
> Descriptor maximum lifetime:24 hours
> Overlap period span:6
> On 25 Mar 2016, at 22:26, George Kadianakis wrote:
>
> Tim Wilson-Brown - teor writes:
>
>> [ text/plain ]
>>
>>> On 25 Mar 2016, at 00:31, George Kadianakis wrote:
>>>
>>> Tim Wilson-Brown - teor mailto:teor2...@gmail.com>>
&
> On 27 Mar 2016, at 05:42, s7r wrote:
>
> Hello,
>
> teor, asn, see comments inline.
>
> On 3/24/2016 5:00 PM, Tim Wilson-Brown - teor wrote:
> [snip]
>>>> The number of directory guards will increase when 0.2.8-stable is
>>>> released and r
process, I'd be happy to support it and review code.
Tim
[0]:
https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml
[1]:
https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml
[2]:
https://www.iana.org/assignments/iana-ipv4-s
is, is this worth the
>>> complexity
>>> that MAINT_INTRO and UPDATE-KEYS-SUBCMD add to the protocol logic?
I'm not convinced that this feature is necessary.
I think we should remove it, and if it looks like it's needed later, we can
write a se
> On 26 Mar 2016, at 21:36, intrigeri wrote:
>
> Hi,
>
> Tim Wilson-Brown - teor wrote (21 Mar 2016 18:16:46 GMT) :
>> If this feature does cause problems, or if your app needs to bootstrap only
>> from the
>> authorities (Tails time syncing? [2]), the fallb
> On 25 Mar 2016, at 00:31, George Kadianakis wrote:
>
> Tim Wilson-Brown - teor mailto:teor2...@gmail.com>>
> writes:
>
>> [ text/plain ]
>>
>>> On 24 Mar 2016, at 22:55, George Kadianakis >> <mailto:desnac...@riseup.net>> wrote:
&g
ke
> up to 6 minutes to get a working connection.
This seems far too long for most users. Usability studies have demonstrated
that users give up after approximately 30 seconds.
Can we design an algorithm that will automatically choose a dystopic guard and
bootstrap within 30 seconds?
What are
h fallback directory
mirrors (0.2.8.1-alpha / 0.2.4.7-alpha)
The release in brackets is when each issue was introduced.
I don't know of any other patches (assigned to me) that are urgent enough to
hold up the next alpha.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
teor
> On 22 Mar 2016, at 23:30, Nathan Freitas wrote:
>
> On Mon, Mar 21, 2016, at 02:16 PM, Tim Wilson-Brown - teor wrote:
>> Just a heads' up that tor 0.2.8 includes a fallback directory mirrors
>> feature, where tor clients bootstrap from a set of hard-coded long-lived
g/projects/tor/ticket/17158>
[2]: https://tails.boum.org/contribute/design/Time_syncing/
<https://tails.boum.org/contribute/design/Time_syncing/>
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
signature.as
27;m not sure 3 or more pairwise meeting times is a good idea, it seems very
complex.
But I'm concerned about the extra load on Nick and Isabela.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
s
up to date in both the tor source code and the
network consensus.
If you're using an old version of tor, some of the addresses may be outdated.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
sign
I'm so sorry I missed this, I'm still catching up on emails from the last two
weeks.
(I took a break after the tor developer meeting.)
How did the meeting go?
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
teor at blah dot im
OTR CAD08081 9755866D 89E2A0
n descriptor size that would stop
you listing 1000 fingerprints.)
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
signature.asc
Description: Message signed with OpenPGP using GPGMail
__
dering if one directory authority is enough.
>
> I never tested with 1. I know 3 works.
1 works fine. But there's no redundancy if it stops working.
(Even numbers are avoided because they run the risk of consensus ties: half
vote one way, half vote another, and there is no majority consensus
ing suggestions?
How do Tor engineers test new stuff?
I typically use chutney for smoke tests. Others use shadow for simulations:
https://gitweb.torproject.org/chutney.git/
<https://gitweb.torproject.org/chutney.git/>https://shadow.github.io/
<https://shadow.github.io/>
Tim
Tim Wilso
rder to distinguish whether a Tor
> connection you're observing is being used for an onion service or a
> normal (exit) connection -- for example, to stymie attacks like the
> "Circuit Fingerprinting Attacks" from the Usenix Security '15 paper. I
> think that is a tota
2016/tor-dev.2016-02-08-22.00.log.html>
[2]: https://trac.torproject.org/projects/tor/ticket/17178
<https://trac.torproject.org/projects/tor/ticket/17178>
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
ich is a "Can Comment" link).
I can't seem to edit the pad.
Does the link just allow annotation, or full-blown editing?
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
signatu
#x27;s really up to debian-legal, who I assume we've asked or will be asking.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
signature.asc
Description: Message signed with OpenPGP usi
> On 2 Feb 2016, at 10:06, Carolin Zöbelein
> wrote:
>
> ---
> Want to help in community team => Question: Is this the right mailing
> list for this?
> ---
I don't know. Maybe tor-talk woul
> On 15 Jan 2016, at 03:07, Mike Perry wrote:
>
> Tim Wilson-Brown - teor:
>>> On 13 Jan 2016, at 00:53, Mike Perry >> <mailto:mikepe...@torproject.org>> wrote:
>>> 1. Overview
>>>
>>> For padding overhead due to Proposals 251
a non-transparent proxy, as it requires the network's IP addresses to
be reconfigured.
Alternately, some combination of DNSPort and SOCKSPort is another
non-transparent proxy option for applications with SOCKS proxy support.
Oh, and please don't cross-post to multiple lists. Answering on t
> On 28 Jan 2016, at 01:05, Nick Mathewson wrote:
>
> On Tue, Jan 26, 2016 at 9:01 PM, Tim Wilson-Brown - teor
> mailto:teor2...@gmail.com>> wrote:
>>
>> On 26 Jan 2016, at 23:19, David Goulet wrote:
>>
>> On 26 Jan (07:00:31), Nick Mathewson wro
> On 26 Jan 2016, at 23:19, David Goulet wrote:
>
> On 26 Jan (07:00:31), Nick Mathewson wrote:
>> On Mon, Jan 25, 2016 at 5:14 AM, David Goulet wrote:
>>> On 18 Jan (07:13:36), Tim Wilson-Brown - teor wrote:
>>>>
>>>>> On 15 Jan 2016,
60223 192.168…. 48952 typ host generation 0
a=candidate:3800267063 1 tcp 1518280447 192.168…. 0 typ host tcptype active
generation 0
a=candidate:759726963 1 udp 1686052607 199... 48952 typ srflx raddr 192.168….
rport 48952 generation 0
a=ice-ufrag:gW3Squmad22xQeoQ
a=ice-pwd:OAGHWixl0ZICWg2
e/tor/geoip6.
Jan 26 12:25:50.000 [notice] Bootstrapped 0%: Starting
Jan 26 12:25:50.000 [notice] Delaying directory fetches: No running bridges
Jan 26 12:25:52.000 [notice] Bootstrapped 5%: Connecting to directory server
Jan 26 12:25:52.000 [notice] Bootstrapped 10%: Finishing handshake with
direc
> On 25 Jan 2016, at 03:10, s7r wrote:
>
> Signed PGP part
> Hi teor,
>
> On 1/24/2016 6:33 AM, Tim Wilson-Brown - teor wrote:
> > Please read the tor man page documentation for the option
> > Tor2webRendezvousPoints. It's implemented in the functi
> On 24 Jan 2016, at 13:04, s7r wrote:
>
> Signed PGP part
>
> On 1/24/2016 1:51 AM, Tim Wilson-Brown - teor wrote:
> >
> >> On 24 Jan 2016, at 09:28, s7r >> <mailto:s...@sky-ip.org>> wrote:
> >>
> >>> * This will break some
figured
to use the same rendezvous point(s) for every hidden service connection,
it will get banned if it connects to the same hidden service too many times.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
o for other
statistics, but I'm not sure there's much point, as they are never seen
outside the hidden service.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
signa
cts/tor/ticket/17840
See also #17849, where yawning and I discuss logging a warning if clients have
very restricted guard choices.
https://trac.torproject.org/projects/tor/ticket/17849
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
teor at blah dot im
OTR CAD08081 9755866D 8
s to retain connection information, so choosing a nearby
entry to me, and a nearby exit to a website in this country, would be very
detrimental to my anonymity.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E
> On 15 Jan 2016, at 03:07, Mike Perry wrote:
>
> Tim Wilson-Brown - teor:
>>> On 13 Jan 2016, at 00:53, Mike Perry >> <mailto:mikepe...@torproject.org>> wrote:
>>> 1. Overview
>>>
>>> For padding overhead due to Proposals 251
ers so moving this one before or after Febuary 2nd would be
> great for me. If impossible, I'll read the notes I guess :).
This is at half past midnight on a Saturday for me, can we move it to time
somewhere in 4pm - 8pm eastern (2100 - 0100 UTC)?
Thanks
Tim
Tim Wilson-Brown (teor
op246
> makes it worse?
Proposal 246 makes it worse, because now both HSDirs and introductions depend
on a potentially churning hash ring. If churn makes an introduction point
unreachable, this increases the load on the other introduction points.
Clients also cache descriptors from HSDirs,
> On 13 Jan 2016, at 20:02, David Goulet wrote:
>
> On 13 Jan (11:34:05), Tim Wilson-Brown - teor wrote:
>>
>>> On 13 Jan 2016, at 01:46, George Kadianakis wrote:
>>>
>>> ...
>>> For what it's worth, we expect this code to run for a lo
whether an exit or internal circuit is cannibalised, they can look
like:
G M E E
G M M E
And what about hidden service paths (paths that include two middle nodes?)
G M M
Or, if cannibalised from an exit or internal circuit:
G M E M
G M M M
Again, I think these will just be part of the ove
a make target, "test-network-all", that runs a series of chutney tests.
Each of these tests finish in around 35 seconds.
Can we get a SR chutney template to finish in around that time?
(With 10 second voting periods?)
What is the minimum number of voting periods that shared randomness require
or
address families, and
* tor may not be able to detect which address(es) it is exiting from, or it may
be an expensive or unreliable process.
But please feel free to submit a proposal to include exit IP addresses in the
consensus - it would help if it included strategies to address these conc
or social effect if people are seeking flags for their
relays. (Nor will it have much effect on policy, except, again, for a minor
social effect.)
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
signature.a
7;t need to do code archeology to determine which number
You did that thing where you start a sentence
Otherwise looks good, modulo a few typos that don't affect meaning.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
teor at blah dot im
OTR CAD08081 9755866D 89E2A06
; would see "this consensus never expires". This would prevent them
> from downloading new consensuses.
>
> [This proposal would result in the quietest shutdown.]
Are we aiming to do this for 0.2.8?
I think it would be a good idea, as adding default fallb
-#include
> -#else
> +#ifndef _MSC_VER
> #include
> #endif
>
> Since is already included in "or.h", it's not needed here
> too.
>
> --
> --gv
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.o
bandwidth.
(Given the small number of Exits flags affected by this change, I'm not sure if
this policy is responsible for all the good Exits, or if our exit-checking
tools are responsible.)
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
teor at blah dot im
> On 5 Jan 2016, at 19:33, Tom van der Woerdt wrote:
> ...
> Op 05/01/16 om 02:15 schreef Tim Wilson-Brown - teor:
>>
>>> On 5 Jan 2016, at 11:29, Tom van der Woerdt >> <mailto:i...@tvdw.eu>> wrote:
>>> ...
>>> 2.1. Exit flagging
>>
Alternately, we could add other widely used SSL ports in addition to XMMP, and
perhaps increase the rule to "at least two SSL ports".
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
si
nds.
https://docs.google.com/document/d/1OaatvGhEAq7VseQ9kkavxKNAfepWy2yhPUBs96FGV28/edit?pref=2&pli=1
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
signature.asc
Description: Message sig
> On 3 Jan 2016, at 14:12, Jesse V wrote:
>
> On 01/02/2016 05:42 PM, Tim Wilson-Brown - teor wrote:
>> And if we can't use the reference implementation, we have some decent
>> programmers…
>> (On the other hand, if there's no reference implementation, th
he differences between each consensus each hour, rather than
downloading a full consensus (~1.5MB).
It showed some great results, but still needs a little work before we merge it.
https://trac.torproject.org/projects/tor/ticket/13339
<https://trac.torproject.org/projects/tor/ticket/13339>
Tim
T
other hand, if there's no reference implementation, then that makes it
hard to recommend that particular crypto scheme.)
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
signature.as
> On 23 Dec 2015, at 03:59, Nick Mathewson wrote:
>
> On Mon, Nov 30, 2015 at 2:12 AM, Tim Wilson-Brown - teor
> wrote:
>> Hi Nick,
>>
>> The AEZ paper says:
>>
>> "We impose a limit that AEZ be used for at most 2^48 bytes of data (about
>&g
1 - 100 of 166 matches
Mail list logo
