.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
https://gitlab.torproject.org/tpo/core/torspec/-/issues/64
___
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,
uite expensive:
>> doing so involving path selection, crypto and making circuits. We will need
>> to profile this procedure and see how we can do this scheduling better.}
>
> With the above, we should be within the same performance as we have right now
> since we just defe
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
t;
> >> (Histograms vs distribution is not the problem -- its what they encode
> >> and how they encode it that matters).
> >>
> >> I don't see this paper on Tobias's website. Is it up anywhere yet?
> >>
> > Hmm. Looking at the README o
George Kadianakis:
> Hello Mike,
>
> I had a talk with Marc and Mohsen today about WTF-PAD. I now understand
> much more about WTF-PAD and how it works with regards to histograms. I
> think I might even understand enough to start some sort of conversation
> about it:
>
>
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
Rob Jansen:
> Thanks for the detailed write-up Mike! Theoretically, moving to QUIC
> seems great; it seems to solve a lot of problems and has enough
> advantages that we could just run with it.
>
> I'll reiterate some of my primary concerns that I gave in Rome:
>
>
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
George Kadianakis:
> Hello Mike,
>
> I'm finally getting out of the prop224/microdescriptor bug pile, and
> getting more time to start working on guard stuff like prop247 again.
>
> I'm planning to spend a few days next week to regain knowledge on
> prop247. I&
7;m trying to ensure people
understand the possibilities...
I am sorry that I do not write papers as you wish I would... I hope that
you enjoy my explanation of a solution more than you have about the issue
itself.
have a great week,
mike
On Mon, Apr 10, 2017 at 8:04 PM, dawuud wrote:
>
&
feature.
I'll post as soon as I'm finished..
Thanks,
Mike Guidry
-
>This appears to describe an active network modulation attack (node DoS).
>Either hammer tree on nodes of the expected path and trace the modulation,
>or on all but the expected path to find unmodulated.
>
I'm not presenting a scientific paper. Its an actual method that works.
You can DDoS various networks to compare against active connections on TOR,
and otherwise...
On Mon, Apr 10, 2017 at 12:22 PM, dawuud wrote:
>
>
> Dear Mike Guidry,
>
> My reply here is snarky but I
not a proxy (of possibly several) just exist in that country. It
is imperative to understand this, and always attempt to get as close to the
networks in question being verified.
Original message:
Are you trolling us? I don't get it!
On Sun, Apr 09, 2017 at 08:19:28PM -0400, Mike Guidry wrot
yILlMPpyJjPS57w7axQ
Feel free to e-mail me directly..
Thanks,
Mike Guidry
tcp_tracing_internet.pdf
Description: Adobe PDF document
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
9b34a14c247ba3
[3]:
https://github.com/mtigas/iObfs/commit/00fac92d620a6401de7b699720f3caa79b7a34c6
--
Mike Tigas
News Applications Developer, ProPublica
https://www.propublica.org/
@mtigas | https://mike.tig.as/ | 0xA993E7156E0E9923
signature.asc
Description: OpenPGP digital signature
_
ell
in my limited testing so far. Will continue working on it in the coming
weeks and keep y’all posted.
Best,
Mike Tigas
@mtigas | https://mike.tig.as/ | 0xA993E7156E0E9923
signature.asc
Description: OpenPGP digital signature
___
tor
d, and don't trust myself to write these bits in C/C++.)
For now I'm just *much* more comfortable building the contraption to fit
the square peg to the round hole, than building the new peg from
scratch. It's suboptimal, but I'm also partially doing this to see if
it&#
rary-ifying", and linking -- rather than the
software implementation bits.
Anyway, that's where things are. Progress will surely ramp up a bit
over the next few weeks. Comments welcome.
Best,
Mike Tigas
@mtigas | https://mike.tig.as/ | 0xA993E7156E0E9923
-BEGIN PGP SIGNATURE---
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
Aaron Johnson:
> Hi Mike,
>
> Here are some specific comments on the proposal, most of which I
> didn’t mention at the session yesterday.
>
> Sec. 2: “When a hidden service picks its guard nodes, it also picks
> two additional sets of middle nodes `second_guard_set` and
&
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
/www.torproject.org/docs/verifying-signatures.html.en#BuildVerification
We want to do this for MacOSX as well. Does anyone happen to know if we can
use otool in some way to remove these LC_CODE_SIGNATURE sections easily,
and get the same exact binary as before signing?
We won't be doing this for iOS
Here is some info about OSX codesigning, courtesy of Mike Tigas. It
sounds like undoing the codesigning to verify build (and signing
machine) integrity will be tricky. If anyone has more info on how to do
that, it would be appreciated.
- Forwarded message from Mike Tigas -
Date: Fri, 10
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
1 - 100 of 255 matches
Mail list logo
