.torproject.org/tpo/core/torspec/-/issues/307
Comment here is also acceptable.
--
Mike Perry
___
tor-dev mailing list -- tor-dev@lists.torproject.org
To unsubscribe send an email to tor-dev-le...@lists.torproject.org
epend upon full parsing and
protocol context, as opposed to just relay message command.
This work is part of Sponsor 112; arti-client support is due by EOY 2024.
C-Tor will not implement this proposal.
--
Mike Perry
___
tor-dev mailing list
to
.
I am posting just the intro section of this proposal here. The full
proposal is at:
https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/344-protocol-info-leaks.txt
Filename: 344-protocol-info-leaks.txt
Title: Prioritizing Protocol Information Leaks in Tor
Author: Mike Perry
impl will mean fewer relays in the consensus,
because of multicore support. It will also probably mean better
consensus diff support. But that isn't done either.
--
Mike Perry
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On 7/30/21 6:22 PM, Mike Perry wrote:
> As a heads up, I have updated Proposal 324: RTT-based Congestion Control
> for Tor -
> https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/324-rtt-congestion-control.txt
>
> The updated version has a new congestion control
/torspec/-/blob/main/proposals/ideas/xxx-backward-ecn.txt
- Update old trac URLs
- Add Acknowledgements
Review and comments are welcome!
--
Mike Perry
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman
plitting
Author: David Goulet, Mike Perry
Created: 2020-11-25
Status: Draft
0. Status
This proposal describes the Conflux [CONFLUX] system developed by
Mashael AlSabah, Kevin Bauer, Tariq Elahi, and Ian Goldberg. It aims at
improving Tor client network performance by dynamically splitting
traffic betwe
On 3/3/21 1:14 PM, David Goulet wrote:
>
> On 02 Mar (20:58:43), Mike Perry wrote:
>>
>>
>> On 3/2/21 6:01 PM, George Kadianakis wrote:
>>>
>>> David Goulet writes:
>>>
>>>> Greetings,
>>>>
>>>>
On 3/2/21 6:01 PM, George Kadianakis wrote:
>
> David Goulet writes:
>
>> Greetings,
>>
>> Attached is a proposal from Mike Perry and I. Merge requsest is here:
>>
>> https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/22
>>
>
&g
yte truncation? (so an adversarial issuer could choose a key to
> match another issuer's keys) Because you can generate an RSA key with
> a targeted most- or least-significant bytes value in roughly the same
> amount of work that it takes to generate an RSA key at all. (For
> example, if we are talking about the 4 least-significant bytes: find a
> prime p, then set the 4 least-significant bytes of a candidate q to
> (t*p^{-1} mod 2^{32}) before choosing the rest of q at random)
Well, again, the dirauths will list the full-length issuer fingerprints
in the consensus to determine the actual key, so all we need here is a
key-id hint which key to verify the signature with. Since we don't
expect a lot of issuers, the likelihood of 32bit collision is low. I
suppose we should probably specify that the REST service must reject any
keys that collide key-ids.
--
Mike Perry
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
; [REF_CHAUM]: https://eprint.iacr.org/2001/002.pdf
> [REF_PRIMO]: https://repo.getmonero.org/selene/primo
> https://www.monerooutreach.org/stories/RPC-Pay.html
> [REF_POW_PERF]:
> https://gitlab.torproject.org/tpo/core/torspec/-/blob/master/proposals/327-pow-over-intro.txt#L1050
> [REF_RES_BENCH]: https://github.com/asn-d6/res_tokens_benchmark
--
Mike Perry
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-too-he-used-the-time-wisely/ar-BB118Jyp
> 38. https://www.youtube.com/watch?v=Ofp26_oc4CA - Raccoons are Legion
> 39.
> https://www.usenix.org/conference/usenixsecurity21/artifact-evaluation-information
> 40. https://petsymposium.org/artifacts.php
> 41. https://en.wikipedia.org/wiki/Liar_paradox
> 42. https://www.youtube.com/watch?v=04_rIuVc_qM - WTF
This is an auspicious number of top-tier references!
> For Karsten:
> https://cs5.livemaster.ru/storage/3a/1f/1449eb23f3c3b318ab4960815fn4--watercolour-watercolor-sad-raccoon.jpg
It is comforting to know that Karsten had friends even among the
raccoons. Probably among the aliens too.
--
Mike Perry
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
sbws.
> FlashFlow, the python code for coordinator, measurer, etc.
> https://gitlab.torproject.org/pastly/flashflow
>
> The rendered documentation for/from the above https://flashflow.pastly.xyz/
>
> Tor repo with branch https://gitlab.torproject.org/pastly/tor/-/tre
https://github.com/mikeperry-tor/torspec/blob/rtt-congestion-control/proposals/324-rtt-congestion-control.txt
https://github.com/torproject/torspec/pull/125
Filename: 324-rtt-congestion-control.txt
Title: RTT-based Congestion Control for Tor
Author: Mike Perry
P_VEGAS_TOR] to [TCP_WESTWOOD_TOR] to
BOOTLEG_RTT_TOR, and see how they perform in competition with each
other, and in competition with Tor's currently fixed-size SENDME
windows. We can also implement CoDel in circuitmux to track transit
times and determine which circuits to s
or set it
automatically.
We actually have this work included in a future performance funding
proposal, but the timeline on that getting approved (or even rejected)
is so far out that we should figure out a way to do this before that,
especially if Flashflow development is going to begin soon.
iculty.
This also eliminates the need for a "default" difficulty.
So in order for the attacker to "total overwhelm" that system, don't
they have to submit not just 200 requests per second, but *continuously*
send requests with higher difficulty than anyone else in the queue,
).
As described above, multithreading still provides a multiplier in the
AES bottleneck case, even over onionbalance.
But, there may be more bottlenecks than just AES crypto, so this is a
further argument for not jumping the gun just yet, and trying v1 first
(or even a simple prototype witho
edentials" -- We can use anonymous credentials and
> a
> third-party token issuance server on the clearnet to issue tokens
> based on PoW or CAPTCHA and then use those tokens to get access to
> the
> service. See [REF_CREDS] for more details.
>
> "PoW + Anony
Merging these defenses into Tor
is a significantly larger engineering task than making a python control
port addon.
It is rather sad that we have to make such choices for security
features/improvements like this, and for the tagging problem. But
security features are surprisingly difficult to obtain funding for (!),
and so we often have to find ways to do whatever we can in these areas.
--
Mike Perry
signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
t
you (the service operator) control, so that that 3rd hop can check if
the rend succeeds because the TLS connection happened to be open (benign
behavior) or because the reversed ntohl() got corrected somehow (attack).
Thank you for your vigilance, Neal!
--
Mike Perry
signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
TT-based Congestion Control for Tor:
Section 4.1 of https://cseweb.ucsd.edu/~savage/papers/PETS11.pdf
TCP ECN: https://tools.ietf.org/html/rfc3168#section-6.1
Backward ECN: https://tools.ietf.org/html/draft-salim-jhsbnns-ecn-00
Stream Flow Control Issues and Ideas:
https://lists.
#x27;s
analysis. Any other choice would be arbitrary or specific to a custom
circumstance, and thus provide less cover.
--
Mike Perry
signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
teor:
> Hi Mike,
>
>> On 4 Jun 2019, at 06:20, Mike Perry wrote:
>>
>> Mike Perry:
>>> teor:
>>>> I have an alternative proposal:
>>>>
>>>> Let's deploy sbws to half the bandwidth authorities, wait 2 weeks, and
>>&
Mike Perry:
> teor:
>> I have an alternative proposal:
>>
>> Let's deploy sbws to half the bandwidth authorities, wait 2 weeks, and
>> see if exit bandwidths improve.
>>
>> We should measure the impact of this change using the tor-scaling
>>
urn like this over time naturally, anyway. This
switching-back-and-forth methodology is meant to control for that.
--
Mike Perry
signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
s, onion service DoS protections, conflux,
explicit congestion control signaling, full datagram Tor, etc.
It would be awesome if such a session could result in a proposal like
this one, but the flip side: explaining how to use protovers to roll out
involved features so that clients ado
> 9) Can we include an example definition of one of these state
> machines, with pseudocode included?
Hrmm.. I highly suggest checking out Tobias's blog posts, which the
proposal cites in Section 4. They are very succinct and accurate. If
they are insufficient, please explain how they fall
ne sooner than
a decade from now, so it would be wise not to bake this sig fig limit
into our actual consensus format.
> Does sbws need a maximum consensus weight fraction?
>
> https://trac.torproject.org/projects/tor/ticket/27336
>
> Torflow uses 5%, but I suggest 1%, becaus
Hi Yawning!
Yawning Angel:
> On 08/02/2018 08:26 PM, Mike Perry wrote:
> > Should we consider recommending basket2 also?
>
> No.
>
> > Is anyone running bridges with it? Probably not, I guess :/.
>
> No one should be, it is incomplete, buggy, and needs a re-de
aster/padding_ape.go
Ooh nice! This is done as a PT implementation.
You might like:
https://github.com/mikeperry-tor/vanguards/blob/master/README_SECURITY.md
In it, I recommend obfs4 with iat-mode=2 because it does some limited
traffic packet size and timing obfuscation. Should we consider
rec
they encode
and how they encode it that matters).
I don't see this paper on Tobias's website. Is it up anywhere yet?
> Let me know what you think. I still don't understand the entire space
> completely yet, so please be gentle. ;)
I hope I was gentle enough. If there'
restrictions in general/default cases as part of Proposal #291 (see the
"Proposal #291 Properties" thread).
We may decide to change the vanguard restriction behavior as we finalize
the restriction story for all of the other cases.
--
Mike Perry
signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
George Kadianakis:
> Mike Perry writes:
>
> > Mike Perry:
> >> teor:
> >> >
> >> >
> >> > > On 25 Apr 2018, at 18:30, Mike Perry wrote:
> >> > >
> >> > > 1. Hidden service use can't push you o
Mike Perry:
> teor:
> >
> >
> > > On 25 Apr 2018, at 18:30, Mike Perry wrote:
> > >
> > > 1. Hidden service use can't push you over to an unused guard (at all).
> > > 2. Hidden service use can't influence your choice of guard (at
teor:
>
>
> > On 25 Apr 2018, at 18:30, Mike Perry wrote:
> >
> > 1. Hidden service use can't push you over to an unused guard (at all).
> > 2. Hidden service use can't influence your choice of guard (at all).
> > 3. Exits and websites can'
George Kadianakis:
> Mike Perry writes:
>
> > Mike Perry:
> >> Mike Perry:
> >> > Heyo.
> >> >
> >> > We're going to have a meeting to discuss Proposal 291. See this thread:
> >> > https://lists.torproject.org/pipermail/
Mike Perry:
> Mike Perry:
> > Heyo.
> >
> > We're going to have a meeting to discuss Proposal 291. See this thread:
> > https://lists.torproject.org/pipermail/tor-dev/2018-April/013053.html
>
> 3. Describe adversary models for our variant proposals from t
Roger Dingledine:
> On Wed, Apr 11, 2018 at 11:15:44AM +0000, Mike Perry wrote:
> > > To be clear, the design I've been considering here is simply allowing
> > > reuse between the guard hop and the final hop, when it can't be avoided. I
> > > don't me
Mike Perry:
> Heyo.
>
> We're going to have a meeting to discuss Proposal 291. See this thread:
> https://lists.torproject.org/pipermail/tor-dev/2018-April/013053.html
Ok, we had this meeting. High level (ammended) action items are:
1. Use patches in https://trac.torproject
r some timescale, based on the information we
have available today.
People who mos def should attend:
George Kadianakis,
Roger,
Nick,
Me
People who probably maybe should attend:
Aaron Johnson,
Isis (and others concerned about guard fingerprinting),
You?
--
Mike Perry
signature.asc
Roger Dingledine:
> On Sat, Mar 31, 2018 at 06:52:51AM +0000, Mike Perry wrote:
> > 3.1. Eliminate path restrictions entirely
> >
> I'm increasingly a fan of this option, the more I read these threads.
>
> Let's examine the two attacker assumptions behind two of
Mike Perry:
> In Rome, I held a session about network protocol upgrades. My intent was
> to cover the switch to two guards, conflux, datagram transports, and
> QUIC. We ended up touching only briefly on everything but QUIC, but we
> went into enough depth on QUIC itself that it was
In-line below for ease of comment. Also available at:
https://gitweb.torproject.org/user/mikeperry/torspec.git/tree/proposals/xxx-two-guard-nodes.txt?h=twoguards
===
Filename: xxx-two-guard-nodes.txt
Title: The move to two guard nodes
Author: Mike Perry
Created: 2018-03
l to the
adversary and enables Sniper attacks), DoS attacks will become
congestion attacks that slow down service at specific bottlenecks, which
I believe that conflux can further mitigate by dynamically avoiding
them.
> I think it would be worth including R&D effort to investigate these
>
Florentin Rochet:
> On 2018-03-20 04:57, Mike Perry wrote:
> >
> >Arguments for staying with just one guard:
> >
> >1. One guard means less observability.
> >
> >As Roger put it in the above blog post: "I think the analysis of the
> >network
Mike Perry:
> David Goulet:
> > On 22 Mar (13:46:36), George Kadianakis wrote:
> > > Mike Perry writes:
> > >
> > > > Arguments in favor of switching to two entry guards:
> > > >
> > > > 1. One guard allows course-grained netflow co
I am personally having a hard time coming up with cases
where such side channels and resource starvation conditions could be any
worse than those that already exist, or are unique to the OOM and DoS
conditions currently possible due to Tor's lack of congestion control.
--
Mike P
George Kadianakis:
> David Goulet writes:
> > On 22 Mar (13:46:36), George Kadianakis wrote:
> >> Mike Perry writes:
> >> > Roger suggested that I enumerate the pros and cons of this increase on
> >> > this mailing list, so we can discuss and consider th
David Goulet:
> On 22 Mar (13:46:36), George Kadianakis wrote:
> > Mike Perry writes:
> >
> > > Arguments in favor of switching to two entry guards:
> > >
> > > 1. One guard allows course-grained netflow confirmation attacks
> > >
> >
nt clients will switch over immediately.
What do we think?
--
Mike Perry
signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
etworkScanners/BwAuthority/README.spec.txt#n353
If feedback is enabled (via consensus parameters), it drives relays to
other forms of resource exhaustion which we do not currently measure
(primarily CPU exhaustion, which we could approximate by circuit
failure, but potentially also memory pressure
that we basically can all agree on the high level approach, and all
agree it is an improvement over status quo, but we will want the extra
time to actually make specific parameter choices and decide if we need
to or want to live with shorter paths for some scenarios..
--
Mike Perry
signature.asc
will discuss usability, configuration, and any recent user
study progress. Anyone interested in these topics for any user-facing
Tor application is welcome and encouraged to participate!
--
Mike Perry
signature.asc
Description: Digital signature
___
to
David Goulet:
> On 21 Jan (10:28:16), Mike Perry wrote:
> > George Kadianakis:
> > > Mike Perry writes:
> > >
> > > > George Kadianakis:
> > > >> Mike Perry writes:
> > > >>
> > > >> > George Kadianakis:
>
to R&E, making it a high probability that if malicious E
sees an extend from a middle M to R&E, it is in the right position in
the circuit and wins the Sybil, discovering M.
This makes me think that while this detector is useful for Rend#2 or
Rend#4 (modulo Roger's concerns), it
ect.org/projects/tor/ticket/16861#comment:39 that I
have mostly fixed, minus the callback issue. I will be posting a reply
and a new branch later today.
I think that's it. Please reply with questions, comments, or additions,
or if I missed anything.
--
Mike Perry
signature.asc
Descr
George Kadianakis:
> Mike Perry writes:
>
> > George Kadianakis:
> >> Mike Perry writes:
> >>
> >> > George Kadianakis:
> >> > > I have mixed feelings about this.
> >> > >
> >> > > - If client guard disco
George Kadianakis:
> Mike Perry writes:
>
> > George Kadianakis:
> > > I have mixed feelings about this.
> > >
> > > - If client guard discovery is the main reason we are doing this,
> > > I think we should first look into these guard discovery
George Kadianakis:
> Mike Perry writes:
>
> > While discussing proposal 247 with George yesterday, we realized that we
> > still get security benefit from additional ephemeral hops beyond the
> > vanguards themselves.
> >
> > Recall the high-level 247 path des
engths also (or instead)?
--
Mike Perry
signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
ent, and get some
> > assurance about the performance and correctness of the system. Also, we
> > need
> > to see how CBT interacts with it.
> >
> > If you want to help with any of the above, show up for the little-t-tor
> > meeting
> > tomorrow.
> >
> > ---
> >
> > [0]:
> > https://lists.torproject.org/pipermail/tor-dev/2016-January/010219.html
> > ___
> > tor-dev mailing list
> > tor-dev@lists.torproject.org
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
--
Mike Perry
signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
It's me again. It looks like I'm still the Internet champion of
"Thinking once and posting twice".
Mike Perry:
> George Kadianakis:
> > Hello there,
> >
> > we recently finished implementing proposal 250 which is one of the first
> > steps
> &
e
adversary has to get in the guard, hsdir, and intropoint positions to be
fully successful).
I think this is reason enough to reject Proposal 246 for high security
onion services by itself, but the complications with onionbalance also
concern me, as well.
--
Mike Perry
signature.asc
Description
Mike Perry:
> Tim Wilson-Brown - teor:
> > > On 13 Jan 2016, at 00:53, Mike Perry wrote:
> > > 1. Overview
> > >
> > > For padding overhead due to Proposals 251 and 254, and changes to hidden
> > > service path selection in Proposal 247, it will
Tim Wilson-Brown - teor:
> > On 13 Jan 2016, at 00:53, Mike Perry wrote:
> > 1. Overview
> >
> > For padding overhead due to Proposals 251 and 254, and changes to hidden
> > service path selection in Proposal 247, it will be useful to be able to
> > specify
-load-balancing-with-overhead.txt?h=load_balancing-squashed
Here is the text in-line, for ease of commenting on-list:
==
Filename: xxx-load-balancing-with-overhead.txt
Title: Load Balancing with Overhead Parameters
Authors: Mike Perry
hould discuss.
--
Mike Perry
signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
prototype showcasing site.
Things like Ricochet, Pond, and OnionShare are obvious great choices,
but we should create a singular list of stuff we want to highlight,
perhaps on a pad.
--
Mike Perry
signature.asc
Description: Digital signature
__
Mike Perry:
> I spent some time trying to clean up proposal 247 based on everyone's
> comments, as well as based on my own thoughts. Please have a look if you
> commented on the original proposal, and complain if I've not taken your
> thoughts into account.
Ok, I've n
pression correctly):
def ProbR(N, r, ProbFunc=ProbMinXX):
sum1 = 0.0
i=r+1
while i < N:
sum1 += ProbFunc(N, i)
i += 1
return sum1/ExpFn(N, ProbFunc)
Here's the current head of the full proposal, for convenience:
https://git
From: Nima Fatemi
To: Mike Perry
Subject: UX Principles
Hi Mike,
sorry for late email. I was meaning to send you this sooner but I've had
a big pile of email, I had to take care of.
So the forwarded message below includes an attachment, which is the
Yee's principles and then there'
Tim Wilson-Brown - teor:
>
> > On 27 Oct 2015, at 20:06, Mike Perry wrote:
> >
> > teor:
> >>
> >> On 27 Oct 2015, at 05:41, Conrad Kramer wrote:
> >>
> >>>> On Oct 26, 2015, at 11:22 AM, Spencer wrote:
> >>>>
&g
any time soon, nor will we be using the
App Store. I think this means we can ignore the more complicated DRM
encryption/decryption jailbreaking steps in the docs that Mike Tigas
linked to, as DRM encryption should not be involved for us. Hopefully
this makes it easier?
--
Mike Perry
signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Jul 2015 01:29:02 -0400
From: Mike Tigas
To: Mike Perry
Subject: Re: Apple developer account + codesigning
Hey Mike,
Cool seeing y'all at that CPJ thing briefly. Yeah, that account is what
you'll need to get the Apple-signed certs that let you codesign an app &
allow it to la
update the chaining value, we need a one-way function. One
>option would be your-favorite-hash-function; blake2b isn't _that_
>bad, right?
>
>We could also try to XOR it with a function of some hidden value
>from AEZ: E(S,-1,?) is promising, but i
for hidden services
* Future Research:
* Conflux + Guard Sets
* Provides Redundancy against active delay and DoS attacks
* May help against fingerprinting and correlation
* However, still won't help against a datacenter adversary :/
--
Mike Perry
signature.asc
Descr
before work begins. "Actual Points"
specify the units of time the ticket actually took after completion, for
evaluation of estimate accuracy/drift/multiplier.
Popular choices for units of time for Points are "minutes", "hours", and
"days".
https://tra
discover what that actually meant, and the EFF
unfortunately did not feel it was worth pursuing to help me find out. It
may have been a scare tactic, but it could just as easily have not been,
and for all I know they may have been actually able to convince a judge
to l
George Kadianakis:
> Mike Perry writes:
>
> > Mike Perry:
> >> I spent some time trying to clean up proposal 247 based on everyone's
> >> comments, as well as based on my own thoughts. Please have a look if you
> >> commented on the original p
George Kadianakis:
> Mike Perry writes:
>
> > Mike Perry:
> >> I spent some time trying to clean up proposal 247 based on everyone's
> >> comments, as well as based on my own thoughts. Please have a look if you
> >> commented on the original p
Mike Perry:
> I spent some time trying to clean up proposal 247 based on everyone's
> comments, as well as based on my own thoughts. Please have a look if you
> commented on the original proposal, and complain if I've not taken your
> thoughts into account.
I spent yet mo
Tim Wilson-Brown - teor:
>
> > On 14 Sep 2015, at 09:07, Mike Perry
> > wrote:
> >
> > ...
> >
> >
> > 4. Security concerns and mitigations
> >
> > 4.1. Mitigating fingerprinting of new HS circuits
> >
> > By pinning th
Tim Wilson-Brown - teor:
> Hi Mike,
>
> Just a few questions about the proposal, inline below:
>
> > On 12 Sep 2015, at 10:34, Mike Perry wrote:
> >
> > Here's a proposal describing some padding negotiation cell primitives that
> > should be
To make it harder for an adversary, a hidden service MAY extend
the path length of its circuits by an additional static hop. This
forces the adversary to use another coercion attack to walk the
chain up to the hidden service.
7. Acknowledgments
Thanks to Aaron Johnson, John Brooks, Mike
https://gitweb.torproject.org/user/mikeperry/torspec.git/tree/proposals/xxx-padding-negotiation.txt?h=padding_negotiation
==
Filename: xxx-padding-negotiation.txt
Title: Padding Negotiation
Authors: Mike Perry
Created: 01 September 2015
Status: Draft
0. Overview
that doesn't support it, then that relay will
emit a warning log message from connection_edge_process_relay_cell() in
relay.c. How should I detect support? Based on advertised relay version
in the consensus? What about non-standard relay implementations that
don't use Tor's versioni
: Mike Perry
Created: 01 September 2015
Status: Draft
0. Motivation
It is currently possible for Guard nodes (and MITM adversaries that
steal their identity keys) to perform a "tagging" attack to influence
circuit construction and resulting relay usage[1].
Because Tor uses AES as a str
do, especially if we still have not solved the
circuit setup fingerprinting problem to prevent an observer from easily
differentiating the two before this (or a similar mechanism) is deployed.
--
Mike Perry
signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
and kludges to the
> minimum to keep the logic simple. Unfortunately, it seems that without a
> "network down" indicator (#16120) there is no way to avoid edge cases and
> false positives here.
If you can't find a more reliable OS-specific indicator, y
Filename: xxx-netflow-padding.txt
Title: Padding for netflow record resolution reduction
Authors: Mike Perry
Created: 20 August 2015
Status: Draft
0. Motivation
It is common practice by many ISPs to record data about the activity of
endpoints that use their uplink, if nothing else for billing
r any related topics, please join us!
The meeting format is described here:
https://lists.torproject.org/pipermail/tbb-dev/2014-February/00.html
--
Mike Perry
signature.asc
Description: Digital signature
___
tor-dev mailing list
to
ven circuit, you
can only extend to the third-level guards that correspond to the bucket
for that second-level guard.
That way, if one third-level guard was compromised via a successful
Sybil attack, the adversary would learn at most 1 of your second-level
guards, instead of learning all of them an
perhaps even immediately), the code
could change to use increasingly harder forms of error upon 160bit
collision (like asserts). But there seems to be no real reason to break
all the old code before we actually spot a collision in a consensus
(which again, we can determine in the field
isis:
> WARNING: much text. so email. very long.
Right. If I cut your previous text, assume I'm in agreement, not
ignoring it.
> Mike Perry transcribed 13K bytes:
> > isis:
> > > > Now that we have a browser updater, I think it is also OK for us to
> > >
isis:
> Mike Perry transcribed 5.1K bytes:
> > […]
> >
> > 2. Perhaps cleaner: if BridgeDB itself were accessible through a domain
> > front, we could export its captcha and bridge distribution through an
> > API on this domain front. Once your IP forwarding i
ridges for either a
given type of the user's choice, or optionally all non-meek types (with
an additional warning that this increases their risk of being discovered
as a Tor user).
Would you and/or Isis be able to work on this on the backend? If not,
can either of you recommend someone that m
to deploy the router
side of this protocol in an easy-to-use router formfactor, we would
implement the corresponding part in Tor Launcher. This would cover
Tails, Tor Browser, Tor Birdy, and Tor Messenger users right off the
bat.
--
Mike Perry
signature.asc
Description: Digital signature
__
issues that Tim Berners-Lee is seemingly so concerned about.
--
Mike Perry
signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
In addition to being a more sane way of handling web browsing, it also
enables a very simple circuit status UI. The Torbutton menu now tells
you the current circuit for the site in the URL bar in a compact display
that is no larger than the dropdown menu itself.
> > On Mar 27, 2015, at 1:28
1 - 100 of 236 matches
Mail list logo
