so I'd
be up for doing the rest of the work (nb: I am traveling/in meetings for
the rest of the week, so it'll be next week at the earliest that I can
really spend quality time).
Regards,
--
Yawning Angel
pgp3QgpFuOMph.pgp
Description: OpenPGP digital signature
at wants to work on this should find the relevant data
formats documented in prop 220.
Regards,
--
Yawning Angel
pgpJcH4BDshFu.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
ut I have a rough idea of what I want our PQ options to look
like.
Regards,
--
Yawning Angel
pgpqk8e9qQLKD.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
ch difficulty...
The alternative to all of this would be something like including
handshake methods/supported link crypto in the descriptors, but that
seems silly.
Regards,
--
Yawning Angel
Filename: 260-cryptography-agility.txt
Title: Link Cryptography Agility
Created: 2015-11-15
Status: Draf
Yeah, the obfs4proxy change is mostly just to save bundle size/disk
space for android and the like.
Regards,
--
Yawning Angel
pgpWolTQ8xEgY.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
nce to any roadmap
> documentation at the end of the spec.
The things listed there are the things that need to happen from
Tor's perspective, and I'm not currently considering a huge "Change All
The Things" type of rework if we were to bump the spec version. But
I'll remove the section
mplemented.
Regards,
--
Yawning Angel
Pluggable Transport Specification (Version 1)
Abstract
Pluggable Transports (PTs) are a generic mechanism for the rapid
development and deployment of censorship circumvention,
based around the idea of modular sub-processes that transform
traffic
at
aren't tor.
* Document the tor pt external mode torrc configuration format (In my
defense, the current spec doesn't do this either).
So, yes? Dunno. There's a limit to how far I can de-torify this sort
of document, and I think this is a reasonable step in the right
direction.
Regards,
.torproject.org/projects/tor/wiki/doc/meek),
the basis of which will probably also be used for bridge distribution
purposes in the future.
Regards,
--
Yawning Angel
pgpYXv2foZmjQ.pgp
Description: OpenPGP digital signature
___
tor-dev maili
e will be owned by root and stored in /etc.
Ah I see (I assume/hope you'll fix this anyway).
(Will there also ever be an option for configuring a different tun
address?)
Neat project. I'll be looking forward to subsequent releases, since
this is slick, and I thi
here should be documentation that this requires a minimum of
CAP_SYS_ADMIN (for the various unshare() calls) and CAP_NET_ADMIN (to
bring the tun interface up).
* The config file load/parse routine has a trivially exploitable
buffer overflow.
--
Yawning Angel
[1]: Tor Browser would be the
memory safe
language, but I like C/C++11 more than all the new popular stuff so I
probably would have made a similar decision.
Should be easily portable to the U*IXes, Windows will give you pain,
but I'm not sure you care. I assume you use version control for the
code and are just not exposing it to
is
possible if they run a node that's part of the network and obtain
enough key material (But, I'd need to look at the floodfill system
again to figure out how many nodes for how long is realistically
required).
Regards,
--
Yawning Angel
pgptgowGyqoHR.pgp
Description: O
o give an accurate representation of how much less.
Regards,
--
Yawning Angel
pgpRhKLezTcGv.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
t; (Note: Probably Lantern people are reading this too. And probably they
> would benefit from the same things we would, since their architecture
> is similar to ours.)
Now despite all of this, the obfs2/3/4 and ScrambleSuit
implementations I did for obfs4proxy do in fact implement a net.Conn
in
under this scheme, in that anyone tapping the link between the user
and the proxy can see what domain the user is trying to view. Anyone
with the capability to inject RSTs can censor on a per-site basis as
well.
Regards,
--
Yawning Angel
pgpDz8wgITs4p.pgp
Descr
eem interested in giving feedback
anyway at present so I'll probably end up drafting something that does
what I want it to do (which fixes the major current shortcomings of the
interface from my POV), at which point all the other people will appear
to complain.
Regards,
--
Yawning Angel
pgpcm
thority
fits together, and figure out how it can be redesigned in a way that is
more inline with how things work now/need to work now (PTs were not a
thing when this started being one of the bigger stumbling blocks).
Regards,
--
Yawning Angel
pgpNTCxTZUKfj.
> As far as reproducibility of builds goes, if a reproducible Python
> build is a challenge, an alternative is to port FTE to Go and retire
> flashproxy.
Or port both to Go (flashproxy would be easy)/deprecate both.
Regards,
--
Yawning Angel
pgpeJ
ere people are talking
about buffing up pyptlib (might make sense), and further deprecating
obfsproxy (Python). I don't particularly see a reason to do either
things, though the Debian people apparently see obfsproxy as the
program and not a library, when it's both.
Regards,
--
Yawning
On Tue, 8 Sep 2015 17:39:58 +1000
Tim Wilson-Brown - teor <teor2...@gmail.com> wrote:
>
> > On 8 Sep 2015, at 08:45, Yawning Angel <yawn...@schwanenlied.me>
> > wrote:
> >
> > So, we currently have a Pluggable Transport (PT) spec, and it
> > kind-
e case.
I probably missed some things. If people have strong opinions about
this, do reply, otherwise I *will* design something that I like, which
will not include what other people want.
Regards,
--
Yawning Angel
pgpk_4mdbY6Vi.pgp
Description: OpenPGP digital
On Mon, 7 Sep 2015 17:03:00 -0700
Kevin P Dyer <kpd...@gmail.com> wrote:
> Response inline.
>
> On Mon, Sep 7, 2015 at 3:29 PM, Yawning Angel
> <yawn...@schwanenlied.me> wrote:
>
> > On Mon, 7 Sep 2015 14:37:07 -0700
> > Kevin P Dyer <kpd...@gmail
the service you’re
connecting to
While such a censor would only be able to deny service to clients as
a fraction of their relay(s) consensus weight, it's still something
that probably should get consideration.
Regards,
--
Yawning Angel
[0]:https://lists.torproject.org/pipermail/to
On Fri, 21 Aug 2015 17:51:20 -0700
Kevin P Dyer kpd...@gmail.com wrote:
On Wed, Aug 19, 2015 at 11:58 AM, Yawning Angel
yawn...@schwanenlied.me wrote:
[snip]
The FTE semantic attack they presented isn't the easiest one I know
of (the GET request as defined by the regex
are attacks against either the Tor
network, or limitations of the tor implementation itself[1].
Regards,
--
Yawning Angel
[0]: Distribution still is an important problem that needs to be
solved, and maybe linking it closer to the protocol design is something
that is required. Open research
of our paper.
Would be interesting to learn what the data tells us.
I would be interested in seeing the results.
--
Yawning Angel
[0]: Ngnix supports hooking the error handler rather easily, apache
less so.
pgpufIOwlRYHG.pgp
Description: OpenPGP digital signature
in the
intervening time period.
Regards,
--
Yawning Angel
pgpkGFnUn8J6o.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
mappings.
2. No canonical visualization that can be shared across users.
3. Something Yawning randomly made up before going to bed.
Regards and good night,
--
Yawning Angel
pgpm_xywJhZs5.pgp
Description: OpenPGP digital signature
___
tor-dev mailing
deploy a few user select-able representation modules.
Without doing so, trying to hash out any sorts of design(s) will likely
end badly, and going with write the framework that lets us do UX
testing will let us get a better handle on the problem[0].
Regards,
--
Yawning Angel
[0]: And who knows
On Thu, 20 Aug 2015 11:00:51 -0400
Ian Goldberg i...@cs.uwaterloo.ca wrote:
On Thu, Aug 20, 2015 at 02:41:51PM +, Yawning Angel wrote:
What would be useful here is the number of onion addresses an
average user visits. If it's small, something like this would
probably be sufficient
.
It's worth noting that Dust2 (mostly done but not yet deployed) can
reduce payload entropy to match a target distribution, but will have
issues with protocol whitelist based DPI.
Regards,
--
Yawning Angel
pgpFY2al5Ysy5.pgp
Description: OpenPGP digital signature
signed tarballs up somewhere sensible.
Since there are no dependencies required beyond a new-ish Go compiler,
this should be utterly trivial to package.
I'll try to do this sooner rather than later, but no promises since IRL
stuff is on fire for the remainder of the week.
Regards,
--
Yawning
things in depth).
I'm planning on revisiting this issue at some point, but last I looked
into it, using an assembly optimized Curve25519 implementation was
potentially a 7-10% gain (but is neither from libsodium nor djb NaCl).
https://trac.torproject.org/projects/tor/ticket/8897
--
Yawning Angel
/bugfixes/maintenance from my end, there's a limit
to what I can do for quirky/broken routers, and in a lot of cases
this will end up as patches accepted.
I hope this clarifies things.
Regards,
--
Yawning Angel
pgpIdmA2SmBnG.pgp
Description: OpenPGP digital signature
with dealing with supporting users
when this fails, I won't do the flashproxy work, but someone else is
more than welcome to do it.
Regards,
--
Yawning Angel
pgplTso9cEf2L.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev
every
single router ever made. And more importantly, compromised routers due
to shitty/out of date uPnP implementations are Not My Problem.
Regards,
--
Yawning Angel
pgpphKdsowO7U.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor
widely supported/deployed uPnP, on consumer routers
at least, should be disabled and treated with extreme suspicion till
proven otherwise.
Regards,
--
Yawning Angel
pgpyEKzNPX65d.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor
of the ones that ship with broken uPnP/NAT-PMP
implementations does not fill me with warm fuzzy feelings.
Regards,
--
Yawning Angel
pgpoHkfbE2rHa.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https
time? Pretty
please? :-)
Unlikely, AFAIK the general plan was to have it as a separate package.
--
Yawning Angel
pgplUoRJtq2TV.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https
).
Regards,
--
Yawning Angel
pgptxSAf8ktjE.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
of connections), which makes machines behind such devices
extremely poor Tor relays (and even worse Guards)[0].
--
Yawning Angel
[0]: In an ideal world every relay should be able to handle having a TCP
connection open to any other relay simultaneously, plus connections from
clients
/13737
https://trac.torproject.org/projects/tor/ticket/13738
(If you happen to be more interested in making non-HS use cases faster,
then look elsewhere. :P)
Regards,
--
Yawning Angel
[0]: I do have a branch that makes circuit build crypto substantially
faster that I've been poking at so
curves (Ed25519, Ed448) which
hopefully will see uptake in the longer run, but ECDHE with the NIST
curves is the current least bad choice.
Regards,
--
Yawning Angel
pgptam3OkluOA.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor
/master
--
Yawning Angel
[0]: Honestly, I'll merge trivial things, but I won't bust out my
windows box to test/debug this, and I don't have an OSX box.
pgp4kvHS2QXRf.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev
the vendor's OpenSSL. The only resolution is Too bad,
so sad, install a modern OpenSSL.
See #16034 and #16040 for details.
--
Yawning Angel
pgp01DoAVjA4U.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
in a single Tor Browser
instance while being relatively safe[1].
Regards,
--
Yawning Angel
[0]: The code assumes it's talking to a system tor instance (it doesn't
launch Tor for you), my control port filter is present so circuit
display is broken intentionally, etc.
[1]: User safety is the #1 goal
form of my shim will support running with any combination of
nothing (Tor Browser just for the privacy benefits, probably
unsafe, I may reconsider this), I2P, and Tor (Though the most useful
configuration is probably I2P + Tor).
Thanks in advance,
--
Yawning Angel
pgp4CFhRjXQuC.pgp
Description
was chosen such that it would be blatantly obvious in
circuit listings as to which torsocks instance things belong to. There
is space in the username field, so appending a hexdecimal large random
number or something is certainly possible and quite trivial.
Regards,
--
Yawning Angel
pgpAXdf3KDOMa.pgp
a higher or lower limit. A
warning is logged periodically (rate limited to avoid log spam/clutter)
if circuits exceed the limit, so adjusting the parameter should be
relatively straight forward.
Regards,
--
Yawning Angel
pgpEKoiBJTmPv.pgp
Description: OpenPGP digital signature
added support
for that feature to torsocks specifically for them). Other tests may
or may not fail if you chose to go down this path.
Regards,
--
Yawning Angel
pgpf9q_ceZn_j.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev
goptlib-0.4 or newer to work around tor bug #15240. Without this
workaround, certain bridges will fail to operate correctly when the
ExtORPort is enabled (the Tor side fix is in tor-0.2.6.5-rc and
newer).
Questions, comments, feedback appreciated,
--
Yawning Angel
, but if not, we may have to add Obfsclient back into Orbot
for supporting x86 devices.
Hmm, maybe I should add obfs4 support to obfsclient. I have code for
all of the crypto I would need to add.
Regards,
--
Yawning Angel
pgpROO5FvVuvJ.pgp
Description: OpenPGP digital signature
is
required).
Patches accepted.
--
Yawning Angel
pgpCrZZmkj5AW.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
on tor's master.
* Maybe should use stem/txtorcon instead of bulb[0].
But as a proof of concept and a demonstration of the feature, I think
it gets the point across. Thanks to special for inspiring me to write
this.
Regards,
--
Yawning Angel
[0]: Which is another quick and dirty hack I wrote, so
to be that big of a win, at least on my hardware, and the sort of
performance I'm seeing feels too much of a performance hit to me.
Regards,
--
Yawning Angel
pgpDNb5K2d0Nd.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev
/projects/tor/wiki/doc/PluggableTransports#PluggableTransportIRCmeetings
--
Yawning Angel
ps: UTC does not do daylight savings. Those of you that have had
clocks change, please double check the time and let me know if we need
to change the time.
pgpDv6z9btUDC.pgp
Description: OpenPGP digital
On Wed, 11 Mar 2015 02:35:10 +
Yawning Angel yawn...@schwanenlied.me wrote:
The code: https://github.com/Yawning/tor/compare/feature6411
The spec: https://github.com/Yawning/torspec/compare/feature6411
Minor updates to both over the course of yesterday, thanks to all that
gave useful
is truely oneshot and
the user does not wish to preserve it).
* Documentation.
Regards,
--
Yawning Angel
pgpAaj3f82G9d.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin
a lose consensus is reached here that this is ok, so I'm going
to leave the design as is and write the control-spec.txt patch.
--
Yawning Angel
[0]: The first HS I ever set up was when I finished my first pass
implementation, and got the code to a working state.
pgpBl_7Y6_Y46.pgp
Description
poorly written
(and not cleaning up all the ephemeral HSes), and (optionally, though
lacking this would be a reduction in features) limiting cross
application HS enumeration, I'd be more inclined to change things.
Regards,
--
Yawning Angel
pgpw3rUD3yJJF.pgp
Description: OpenPGP digital signature
to discuss at the dev-meeting if consensus hasn't been
reached by then.
Regards,
--
Yawning Angel
pgpfWLpkffCJ7.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman
are essentially free, so does this matter?
I have this mindset too.
--
Yawning Angel
pgpUVCOT7N8h3.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
. This clearly indicates the argument type and should be future
proof (and also has the side benefit of being easier for me to
validate.
Thoughts?
--
Yawning Angel
pgp7Nxg_N4dT5.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev
generation entirely the application's problem,
but nickm convinced me otherwise).
Questions, comments, feedback appreciated,
--
Yawning Angel
pgpeQtjfKpLIu.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
for reporting this. The bug was fixed in master, and should be
in the next 0.2.6.x-alpha release. The fix suggested was fine but was
tweaked somewhat when applied
See: https://trac.torproject.org/projects/tor/ticket/14764
Regards,
--
Yawning Angel
pgpy4jp7142Fy.pgp
Description: OpenPGP digital
belive stem has seen performance
improvements since I tried using it for this.
https://github.com/torps/torps
Regards,
--
Yawning Angel
pgpr2VyLy2bvp.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
a loopback interface, so cutting out 1xRTT isn't
worth the added code (There's a case to be made for using TFO for
inter-relay traffic, but that's entirely orthogonal to this.).
Regards,
--
Yawning Angel
pgpVhB7cqfu70.pgp
Description: OpenPGP digital signature
so.
Regards,
--
Yawning Angel
pgp040JdSEWuS.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
to be systematically evaluating defenses as
part of his research work, so perhaps he can provide more insight into
algorithm selection.
Regards,
--
Yawning Angel
pgpdDB_Sg9Y0F.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev
), 7000 calls to gettimeofday() is 17.09 ms worth of
calls.
The clock code in tor does need love, so I wouldn't object to cleanup,
but I'm not sure it's in the state where it's causing the massive
performance degradation that you are seeing.
Regards,
--
Yawning Angel
pgpN7QOVVGLMt.pgp
Description
be a good opportunity to switch more things over to monotonic time.
Regards,
--
Yawning Angel
pgpyHZsfFsxzw.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman
information). The patch is still trivial for anyone that's
familiar with the TCP/IP code.
I don't think we should be in the business of maintaining kernel
patches either, so I'm not sure what the right thing to do would be for
non-Darwin *BSD.
Regards,
--
Yawning Angel
pgpus7JlLTwWJ.pgp
Most of the fixes require major revisions to the wire protocol. As
it appears that there is no versioning, how that will be done is
left as an exercise for the student.
Alternatively, rebase the system on I2P.
Regards,
--
Yawning Angel
pgpGSqhEPfHVU.pgp
Description: OpenPGP digital
heavyweight the other crypto bits are).
Regards,
--
Yawning Angel
pgpI20qKE8Gnl.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
that is intended to be
used in production) in terms of completeness.
Thanks to Marc Juarez (KU Leuven) and Mike Perry for inspiration to
write the CS-BuFLO component of basket.
Questions, comments, feedback appreciated as always,
--
Yawning Angel
ps: Seriously, unless you are a developer
Hello!
Just wanted to remind you that the regular biweekly pluggable
transports meeting is going to occur tomorrow at 16:00 UTC. Place is
the #tor-dev IRC channel in the OFTC network.
Thanks for your attention!
--
Yawning Angel
pgpmwTq6Jwj11.pgp
Description: OpenPGP digital signature
Hello!
just wanted to remind you that the regular biweekly pluggable
transports meeting is going to occur tomorrow at 16:00 UTC. Place is
the #tor-dev IRC channel in the OFTC network.
Thanks for your attention!
--
Yawning Angel
pgpgttQ9aqVoM.pgp
Description: OpenPGP digital signature
intermediary commits between tagged releases? Yes, signing
each commit is possible, and probably even a good idea, but it's not
currently done.
Regards,
--
Yawning Angel
pgpBtpnfUsqCQ.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
On Sun, 30 Nov 2014 19:19:58 -0500
Jason Cooper t...@lakedaemon.net wrote:
On Sun, Nov 30, 2014 at 11:55:31PM +, Yawning Angel wrote:
On Sun, 30 Nov 2014 17:32:05 -0500
Jason Cooper t...@lakedaemon.net wrote:
It is unauthenticated and you probably shouldn't use it if at
all
, so I went with something lighter (Thus
SipHash). I may go back to the two box design if I do an obfs5, not
sure about that yet.
Regards,
--
Yawning Angel
pgpgvpPIf0y5d.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev
countermeasures in section 6 of the paper (So an identical failure to
a modified plaintext/tag is observed).
Regards,
--
Yawning Angel
[0]: http://cr.yp.to/mac/poly1305-20050329.pdf
pgpD4SkRCdRkT.pgp
Description: OpenPGP digital signature
___
tor-dev mailing
On Fri, 28 Nov 2014 17:57:26 +
Michael Rogers mich...@briarproject.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 28/11/14 15:50, Yawning Angel wrote:
A one time poly1305 key is calculated for each box, based on 32
bytes of zeroes encrypted with a one time Salsa20 key
Hello!
just wanted to remind you that the regular biweekly pluggable
transports meeting is going to occur tomorrow at 16:00 UTC. Place is
the #tor-dev IRC channel in the OFTC network.
Thanks for your attention!
--
Yawning Angel
pgp17oIBtS3qf.pgp
Description: OpenPGP digital signature
plans for obfsng (aka obfs6 depending on how
long it gets stuck in design and deployment) involves 1 KiB keys...
Regards,
--
Yawning Angel
pgp1Omyydtsp8.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
specifically at detecting obfs2). I personally think that it should be
deprecated sooner rather than later, but others have disagreed with me
on this.
Hope that helps,
--
Yawning Angel
pgpRkxhRUfSjM.pgp
Description: OpenPGP digital signature
___
tor-dev
,
--
Yawning Angel
pgpGA5tzki8YH.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
my branch.
I have verified that the linux64 and windows (thanks to a friend)
bundles appear to be functional. If you wish to follow obfs4
deployment the bug associated with this task is #12130.
Questions, comments, feedback welcome.
--
Yawning Angel
signature.asc
Description: PGP signature
.
* The obfs4proxy and Go licenses are now included in the bundle.
I have verified that the linux64 and windows (thanks to a friend)
bundles appear to be functional. If you wish to follow obfs4
deployment the bug associated with this task is #12130.
Questions, comments, feedback welcome.
--
Yawning
).
If you wish to follow obfs4 deployment the bug associated with this
task is #12130.
Questions, comments, feedback welcome.
--
Yawning Angel
signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https
for
compatibility.)
How to do this in Java depends on which crypto API you are using, look
at oracle.security.crypto.asn1 or org.bouncycastle.asn1. Additionally
this (http://lapo.it/asn1js/) will probably be useful.
Regards,
--
Yawning Angel
signature.asc
Description: PGP signature
.
However, it allows us to modify bridge addresses without releasing a
new TBB.
I don't see that as being a sufficiently compelling reason to give a
third party the ability to enumerate (a unknown fraction of) the PT user
base (while making them rich at the same time).
Regards,
--
Yawning Angel
for obfs3 (and ScrambleSuit/obfs4 both have
some defenses against those, although not all are enabled as a
performance tradeoff).
Regards,
--
Yawning Angel
signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https
only
supported obfs2, but that's been fixed for a while now.
Regards,
--
Yawning Angel
signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
(Fixing such things is also on my TODO list).
Regards,
--
Yawning Angel
signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
(The fact that it
coincidentally happens to be the bridge fingerprint has no effect on
the obfs4 protocol itself).
Regards,
--
Yawning Angel
signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https
that SIOCOUTQ isn't portable, because checking the send
socket buffer's size is one of the better ways to do this.
Regards,
--
Yawning Angel
signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https
and get the added defenses without (many? any?) code changes.
Regards,
--
Yawning Angel
signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
.
* Development was done with go1.2.x, older versions of the runtime are
not supported.
* It would be a terrible idea to use obfs4proxy as anything other than
a client at this point.
Questions, comments, feedback all appreciated.
--
Yawning Angel
PS: I also wrote https://github.com/yawning
as the scary build process can handle
flashproxy and meek. I've been a bit more focused on getting the
protocol design and implementation to a point where I feel generally
good about it.
--
Yawning Angel
signature.asc
Description: PGP signature
___
tor-dev
101 - 200 of 228 matches
Mail list logo
