Re: [tor-dev] Proposition: Applying an AONT to Prop224 addresses?

[Alec Muffett]

>
> We could leave the version field outside the AONT, though, but commit to
> changing the paramaters of the AONT (in particular, the domain
> separation constant?) if we change the version number, so that an
> adversary changing the version number to "2" would just cause the client
> to throw an error (before version 2 exists) or be an invalid address
> (after version 2 exists)?


To add an aside from a discussion with Teor: the entire "version" field
could be reduced to a single - probably "zero" - bit, in a manner perhaps
similar to the distinctions between Class-A, Class-B, Class-C... addresses
in old IPv4.

Thus: if the first bit in the address is zero, then there is no version,
and we are at version 0 of the format

If the first bit is one, we are using v1+ of the format and all bets are
off, except that the obvious thing then to do is count the number of 1-bits
(up to some limit) and declare that to be version number.  Once we're up to
3 or 4 or 7 or 8 one-bits, then shift version encoding totally.

Teor will correct me if I misquote him, but the advantage here was:

a) the version number is 1 bit, ie: small, for the forseeable / if we get
it right

b) in pursuit of smallness, we could maybe dump the hash in favour of a
AONT + eyeballs, which would give back a bunch of extra bits

result: shorter addresses, happier users.

-- 
http://dropsafe.crypticide.com/aboutalecm
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposition: Applying an AONT to Prop224 addresses?

[Ian Goldberg]

On Sun, Mar 26, 2017 at 04:19:58PM -0400, Ian Goldberg wrote:
> On Sun, Mar 26, 2017 at 02:24:41PM +0200, Alec Muffett wrote:
> > Hi,
> > 
> > So: a bunch of us were discussing Prop224 Onion addresses, and their
> > UX-malleability.
> > 
> > Specifically: that there are small bit fields in the current Prop224 Onion
> > Address schema (eg: version, and other future structure?) which can be
> > tweaked or amended without otherwise changing the functionality of the
> > address, or without much changing what the user sees in the (say) browser
> > address bar.
> > 
> > This is a point of significant concern because of issues like phishing and
> > passing-off - by analogy: t0rpr0ject.0rg versus torproject.org  - and other
> > games that can be played with a prop224 address now, or in future, to game
> > user experience.
> > 
> > We discussed the existing "hash the public key before base-32 encoding"
> > approach, but hashing breaks the prop224 key blinding.
> > 
> > Ian Goldberg - thank you Ian - offered this attractive solution: apply a
> > *reversible* "All Or Nothing Transform" (AONT) to the entire Prop224 Onion
> > Address, prior to Base32 Encoding.
> > 
> > This way, even a single-bit mutation of (say) version number will have a
> > "diffusion" effect, impacting ~ N/2 of the bits whilst having O(1) cost and
> > being reversible so as not to impact the rest of Prop224.
> > 
> > The result would be onion addresses which are less "tamperable" / more
> > deterministic, that closer to one-and-only-one published onion address will
> > correspond to an onion endpoint.
> > 
> > What does the panel think?
> 
> One thing I thought of later is that, assuming the version field is
> "under" the AONT, then there is *no* visible version field in the final
> address, so you would have to commit to "For any possible future onion
> address of this fixed length, the first thing you have to do to decode
> it is this particular AONT."  This seems a bit suboptimal to me.  And
> since the version field basically *is* the tweakable field in the
> current prop224 addresses, maybe this actually isn't so useful after
> all for this version of the spec?



We could leave the version field outside the AONT, though, but commit to
changing the paramaters of the AONT (in particular, the domain
separation constant?) if we change the version number, so that an
adversary changing the version number to "2" would just cause the client
to throw an error (before version 2 exists) or be an invalid address
(after version 2 exists)?

Then the address would look something like:

base32( AONT_1( pubkey || checksum ) || version=0x01 )

where AONT_1 is an unkeyed invertible function from 34(?)-byte strings
to 34(?)-byte strings.

(Of course, then all addresses would end in "b", or something like
that.)


-- 
Ian Goldberg
Professor and University Research Chair
Cheriton School of Computer Science
University of Waterloo
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] One Valid Next-Generation Onion Address per Private Key

[Ian Goldberg]

On Sun, Mar 26, 2017 at 10:39:08PM +1100, teor wrote:
> Hi all,
> 
> Most onion service users expect that there is only one valid onion
> address for their private key. (For example, one address is listed in
> SSL certificates.)
> 
> I spoke with Ian, and he said that as part of validating the onion
> address, we should check if it is a valid point.
> 
> He said we need to multiply the point by L, and make sure there's no
> torsion component (that is, that the result is the identity).
> 
> This avoids the complexity of choosing a canonical point using some
> lexicographic order, or the complexity of using something like decaf.
> 
> (Hopefully, Ian will write back if I transcribed things incorrectly.)

Just to transcribe the further conversation:

Yes, that's fine to make sure you're using a legitimate point, and not
one that's been munged, it turns out you don't need to do even that.
The reason is that the daily derived blinded point includes a hash of
the onion address, so if someone changes the onion address in any way,
the daily blinded version will be totally different, and the modified
address won't work, *even if* the contained public key is "equivalent"
to the original key.
-- 
Ian Goldberg
Professor and University Research Chair
Cheriton School of Computer Science
University of Waterloo
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposition: Applying an AONT to Prop224 addresses?

[Ian Goldberg]

On Sun, Mar 26, 2017 at 02:24:41PM +0200, Alec Muffett wrote:
> Hi,
> 
> So: a bunch of us were discussing Prop224 Onion addresses, and their
> UX-malleability.
> 
> Specifically: that there are small bit fields in the current Prop224 Onion
> Address schema (eg: version, and other future structure?) which can be
> tweaked or amended without otherwise changing the functionality of the
> address, or without much changing what the user sees in the (say) browser
> address bar.
> 
> This is a point of significant concern because of issues like phishing and
> passing-off - by analogy: t0rpr0ject.0rg versus torproject.org  - and other
> games that can be played with a prop224 address now, or in future, to game
> user experience.
> 
> We discussed the existing "hash the public key before base-32 encoding"
> approach, but hashing breaks the prop224 key blinding.
> 
> Ian Goldberg - thank you Ian - offered this attractive solution: apply a
> *reversible* "All Or Nothing Transform" (AONT) to the entire Prop224 Onion
> Address, prior to Base32 Encoding.
> 
> This way, even a single-bit mutation of (say) version number will have a
> "diffusion" effect, impacting ~ N/2 of the bits whilst having O(1) cost and
> being reversible so as not to impact the rest of Prop224.
> 
> The result would be onion addresses which are less "tamperable" / more
> deterministic, that closer to one-and-only-one published onion address will
> correspond to an onion endpoint.
> 
> What does the panel think?

One thing I thought of later is that, assuming the version field is
"under" the AONT, then there is *no* visible version field in the final
address, so you would have to commit to "For any possible future onion
address of this fixed length, the first thing you have to do to decode
it is this particular AONT."  This seems a bit suboptimal to me.  And
since the version field basically *is* the tweakable field in the
current prop224 addresses, maybe this actually isn't so useful after
all for this version of the spec?
-- 
Ian Goldberg
Professor and University Research Chair
Cheriton School of Computer Science
University of Waterloo
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] The behavior of ClientRejectInternalAddresses

[Jesse V]

Hi everyone,

I would like some clarification on ClientRejectInternalAddresses. The
manual says:
> "If true, Tor does not try to fulfill requests to connect to an
internal address (like 127.0.0.1 or 192.168.0.1) unless a exit node is
specifically requested (for example, via a .exit hostname, or a
controller request). (Default: 1)

In other words, if I disable this flag and I open 127.0.0.1:8080 in the
Tor Browser, will the browser or the tor binary attempt to connect to
the client's 127.0.0.1:8080? This is essentially what I'm after, and I
just want to confirm that ClientRejectInternalAddresses is the best
approach, or if there is a better setting. Just to clarify, I want to
connect the client's localhost and not an exit's.

-- 
Jesse



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

Re: [tor-dev] GSoC 2017 - Project "Crash Reporter for Tor Browser"

[Georg Koppen]

Tom Ritter:
> Hi Nur-Magomed,
> 
> Great to have you interested in this!
> 
> So we would want to use the Crash Reporter that's built into Mozilla
> Firefox (which is called Breakpad, and is adapted from Chromium).  At
> a high level, I would break down the project into the following
> sections:

Those look all good to me. I just have one small addition/clarification
below.

> 1) Get the crash reporter built (at all) in our toolchain. We
> currently disable it and I know there will be at least one or two
> hurdles to overcome here as we've never tried to built this on
> Linux-for-Windows.  If you wish you could focus on a single platform
> for this at a time (e.g. Linux) so you can move onto the next step.
> 
> 2) Audit the crash reporter data and see what it is that gets
> reported, when, and how. We'd want to err on the side of caution about
> what we report in a dump. So we'd need to enumerate each field that
> gets reported, get some samples of the data, and review if we'd want
> to include it or not. We'd also want to review what prefs govern crash
> submissions, how crashes get stored (which I think is on-disk next to
> Tor Browser), and when they get reported.
> 
> 3) Change the way they get reported. We absolutely cannot have crashes
> sitting around on disk next to Tor Browser for the next time the user
> starts the browser - no matter how much data we strip out of them. So
> we'll need to brainstorm how we might try submitting them immediately
> upon crash instead of next startup.

Even though it seems to me the critical UX part is implicit in the
section above, I thought it might be better to point it out explicitly
as well:

We should have a good user interface ready giving the user at least an
explanation on what is going on and a way to check what is about to be sent.

Georg

> 4) Get a submission server running. Mozilla has a ton of tools to
> analyze crashes (https://crash-stats.mozilla.org/home/product/Firefox
> is one and https://github.com/mozilla/socorro is the general backend).
> We should look at Socorro and probably adapt it for use by Tor rather
> than building our own.
> 
> 5) Circle back and get the crash reporter built reproducibly, and for
> all platforms. I put this one last because it may be the case that
> there are annoying time-sinks here, and I think by doing this last
> you'll be able to make the most headway on things that will take the
> most time - like enumerating, documenting, and evaluating the fields;
> and fiddling with Socorro.
> 
> 
> This is my take on it - Georg may have additional thoughts.
> 
> -tom




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

Re: [tor-dev] GSOC 2017: Proposal for anon-connection-wizard

[anonym]

irykoon:
> Currently, the Tor Launcher is shipped with the Tor Browser Bundle and
> heavily relies on the Tor Browser for its implementation. These facts
> cause using Tor Launcher without having the Tor Browser impossible. I
> agree with the whonix core developer Patrick Schleizer that "the Tor
> Browser Bundle has its kind of users. system Tor (refers to Tor from
> packages.debian.org or deb.torproject.org) users, where Tor runs as
> daemon, is used in different ways for different purposes. These users
> cannot use Tor Launcher, because it only works with Tor Browser".

I might be misunderstanding what you and Patrick mean with "impossible" (or 
rather, which use cases are impossible) w.r.t. using Tor Launcher outside of 
the Tor Browser; Tails uses the Tor Launcher shipped in Tor Browser, but it's 
run as a stand-alone XUL application (`firefox --app ...`), so the *web* 
browser isn't started as part of it. [1] One could even run it using 
Iceweasel/Firefox, i.e. completely without Tor Browser.

That said, this approach will not be viable any more some time next year when 
the Firefox ESR branch drops XUL support and Tor Launcher is deprecated 
upstream. It remains to see how the replacement of Tor Launcher will look, it 
might still work for Tails. However, if anon-connection-wizard would be a (more 
or less) drop-in replacement for Tor Launcher in Tails, that would be immensely 
helpful since we'd have a solution that will be guaranteed to work for us 
without much work. And I guess as long as the UX is more or less identical to 
the new Tor Launcher and rapidly adapts to changes, and there are good 
translations, we'd probably prefer it over the new Tor Launcher, since it 
probably will be even harder to decouple from the web browser.

Any way, I also see potential for future collaboration between Whonix and Tails 
for extending the usefulness of anon-connection-wizard beyond what Tor Launcher 
(and its replacement) offers [2]; anon-connection-wizard targets the OS, not 
just a single application, so it could integrate the choices of network 
configuration (wired? which wireless network? MAC spoofing?) and Tor 
configuration (proxy? pluggable transport?) in a single place which probably 
makes more sense for users and also allows us to more easily (optionally) save 
these settings so they are restored the next time you visit the same network. 
This could potentially even be used to help giving users control over entry 
node selection to avoid persistent Entry Guards from leaking information about 
you geographical movement. [3]

Cheers!

[1] The first two scripts are parts of the build process, the two latter ones 
are for starting it:
* 
https://git-tails.immerda.ch/tails/tree/config/chroot_local-hooks/06-adduser_tor-launcher?h=devel
* 
https://git-tails.immerda.ch/tails/tree/config/chroot_local-hooks/10-tbb?h=devel
* 
https://git-tails.immerda.ch/tails/tree/config/chroot_local-includes/usr/local/sbin/tails-tor-launcher?h=devel
* 
https://git-tails.immerda.ch/tails/tree/config/chroot_local-includes/usr/local/bin/tor-launcher?h=devel
[2] https://tails.boum.org/blueprint/network_connection/
[3] We discuss the issue of  
https://tails.boum.org/blueprint/persistent_Tor_state/

___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] GSoC 17 | Name System API for Tor Onion Services

[George Kadianakis]

Ivan Tham  writes:

> George Kadianakis  wrote:
>
>> Pickfire  writes:
>> 
>> > I am Ivan Tham. Currently studying in Computer Science in APIIT Malaysia. 
>> > I am
>> > interested particapate in Google Summer of Code 2017 under tor 
>> > organization. I
>> > am interested to see Proposal 224 coming along but I would really like to 
>> > see
>> > [Proposal 272][0] and hope that tor hidden services can be more 
>> > user-friendly.
>> 
>> there is still interest in this proposal but unfortunately it hasn't
>> been revised since it was first posted on the mailing list. The mailing
>> list feedback unfortunately has not been incorporated to the proposal
>> yet; particularly the comments by David Fifield are very relevant and
>> should be considered carefully before taking the proposal too seriously.
>
> Does
>
>> In general, I suggest to anyone who wants to work on this proposal, to
>> do it using a Tor controller instead of hacking the main C tor
>> code. meejah suggested this here:
>>   https://lists.torproject.org/pipermail/tor-dev/2016-October/011517.html
>
> Does that mean that I well be working on the prototype with python first and
> then convert it into C?
>

Hello,

I think a well made controller-based prototype in Python and one or two
PoC integrations of simple name systems (e.g. local hosts file, remote
hosts file) should be fine for a GSoC summer project.

If we like the controller prototype we could consider writing it in C in
the future.

>> and it seems like a proper solution here would involve controller events
>> like NEWRESOLVE, MAPADDRESS, and plus some extra magic.
>
> I don't quite understand what does that mean.
>

Please check control-spec.txt for a description of those events:
   https://gitweb.torproject.org/torspec.git/tree/control-spec.txt
It might make things clearer.

>> I must say that this project is definitely relevant for GSoC, but it
>> needs a _strong_ and _independent_ student that can handle it.
>
> I will definitely do my best for it but I will really need a mentor to help
> because I am confused by some parts of it as well.
>

Hmm. Which parts did you find confusing?

Cheers!


___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Proposition: Applying an AONT to Prop224 addresses?

[Alec Muffett]

Hi,

So: a bunch of us were discussing Prop224 Onion addresses, and their
UX-malleability.

Specifically: that there are small bit fields in the current Prop224 Onion
Address schema (eg: version, and other future structure?) which can be
tweaked or amended without otherwise changing the functionality of the
address, or without much changing what the user sees in the (say) browser
address bar.

This is a point of significant concern because of issues like phishing and
passing-off - by analogy: t0rpr0ject.0rg versus torproject.org  - and other
games that can be played with a prop224 address now, or in future, to game
user experience.

We discussed the existing "hash the public key before base-32 encoding"
approach, but hashing breaks the prop224 key blinding.

Ian Goldberg - thank you Ian - offered this attractive solution: apply a
*reversible* "All Or Nothing Transform" (AONT) to the entire Prop224 Onion
Address, prior to Base32 Encoding.

This way, even a single-bit mutation of (say) version number will have a
"diffusion" effect, impacting ~ N/2 of the bits whilst having O(1) cost and
being reversible so as not to impact the rest of Prop224.

The result would be onion addresses which are less "tamperable" / more
deterministic, that closer to one-and-only-one published onion address will
correspond to an onion endpoint.

What does the panel think?

- alec

-- 
http://dropsafe.crypticide.com/aboutalecm
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] One Valid Next-Generation Onion Address per Private Key

[teor]

Hi all,

Most onion service users expect that there is only one valid onion
address for their private key. (For example, one address is listed in
SSL certificates.)

I spoke with Ian, and he said that as part of validating the onion
address, we should check if it is a valid point.

He said we need to multiply the point by L, and make sure there's no
torsion component (that is, that the result is the identity).

This avoids the complexity of choosing a canonical point using some
lexicographic order, or the complexity of using something like decaf.

(Hopefully, Ian will write back if I transcribed things incorrectly.)

T
--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org




signature.asc
Description: Message signed with OpenPGP
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] [RFC] Proposal for the encoding of prop224 onion addresses

[teor]

> On 26 Mar 2017, at 21:41, Ian Goldberg  wrote:
> 
> On Sun, Mar 26, 2017 at 09:27:37PM +1100, teor wrote:
>> 
>>> On 26 Jan 2017, at 10:19, teor  wrote:
>>> 
> onion_address = base32(pubkey || checksum || version)
>>> 
>>> Is the order in which the address is encoded once the checksum is
>>> calculated. checksum represents (the first two bytes of) the result of
>>> the SHA3 hash.
>>> 
>>> We put pubkey first so that humans can distinguish addresses.
>>> (We could put checksum first, but that's non-standard.)
>> 
>> I just talked with some people who run a large onion site.
>> 
>> They asked if we can put the checksum at the front of the encoded
>> address.
>> 
>> This makes phishing with different bit(s) in the tail of the address
>> much harder. (That is, searching for a matching prefix for an existing
>> address is much harder if the checksum changes the first two characters
>> unpredictably. People ignore the checksum if it's at the end.)
> 
> Wait; why is searching for a matching checksum at the beginning harder
> than searching for a matching pubkey?  When trying to collide an onion
> address, the pubkey is essentially random, as is the checksum.

You're right - it only matters if the checksum is hard to compute.
(We could make it an scrypt or something, if we wanted to. But if we
don't, there's no need to make this change.)

T
--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org




signature.asc
Description: Message signed with OpenPGP
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] [RFC] Proposal for the encoding of prop224 onion addresses

[Ian Goldberg]

On Sun, Mar 26, 2017 at 09:27:37PM +1100, teor wrote:
> 
> > On 26 Jan 2017, at 10:19, teor  wrote:
> > 
> >>> onion_address = base32(pubkey || checksum || version)
> > 
> > Is the order in which the address is encoded once the checksum is
> > calculated. checksum represents (the first two bytes of) the result of
> > the SHA3 hash.
> > 
> > We put pubkey first so that humans can distinguish addresses.
> > (We could put checksum first, but that's non-standard.)
> 
> I just talked with some people who run a large onion site.
> 
> They asked if we can put the checksum at the front of the encoded
> address.
> 
> This makes phishing with different bit(s) in the tail of the address
> much harder. (That is, searching for a matching prefix for an existing
> address is much harder if the checksum changes the first two characters
> unpredictably. People ignore the checksum if it's at the end.)

Wait; why is searching for a matching checksum at the beginning harder
than searching for a matching pubkey?  When trying to collide an onion
address, the pubkey is essentially random, as is the checksum.
-- 
Ian Goldberg
Professor and University Research Chair
Cheriton School of Computer Science
University of Waterloo
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] [RFC] Proposal for the encoding of prop224 onion addresses

[teor]

> On 26 Jan 2017, at 10:19, teor  wrote:
> 
>>> onion_address = base32(pubkey || checksum || version)
> 
> Is the order in which the address is encoded once the checksum is
> calculated. checksum represents (the first two bytes of) the result of
> the SHA3 hash.
> 
> We put pubkey first so that humans can distinguish addresses.
> (We could put checksum first, but that's non-standard.)

I just talked with some people who run a large onion site.

They asked if we can put the checksum at the front of the encoded
address.

This makes phishing with different bit(s) in the tail of the address
much harder. (That is, searching for a matching prefix for an existing
address is much harder if the checksum changes the first two characters
unpredictably. People ignore the checksum if it's at the end.)

T
--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org




signature.asc
Description: Message signed with OpenPGP
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] french documentation

[teor]

> On 26 Mar 2017, at 20:58, Thierry Boibary  wrote:
> 
> hi,
> i'd like to collaborate to Tor, in the hidden services for example Tor2web, 
> Torbirdy, metrics portal .

Here is some information about these projects:
https://www.torproject.org/getinvolved/volunteer.html.en

Sorry, it is only in English.

Tim

> regards
> 
> T Boibary
> 06 85 55 34 89
> 
> <1481836001.1313601483.0>
> 
> 
>  Message d'origine 
> De : teor 
> À : tor-dev@lists.torproject.org
> Objet : Re: [tor-dev] french documentation
> Date : 24/03/2017 09:24:18 CET
> Copie à : Thierry Boibary 
> 
> 
> > On 11 Feb 2017, at 07:55, Thierry Boibary  wrote:
> >
> > hi,
> > where can i find french documentation?
> > i am expert in systems and networks administration so i'd like working for 
> > you, in a domain which needs my capabilities.
> >
> > help me to find a domain? please
> >
> > Regards
> > T
> 
> Hi Thierry,
> 
> Sorry it has taken a long time for me to reply.
> 
> We have Tor Browser in French:
> https://www.torproject.org/projects/torbrowser.html.en#downloads
> 
> We want other documentation in French, but we need people to help!
> 
> What documentation do you want?
> 
> T
> 
> --
> Tim Wilson-Brown (teor)
> 
> teor2345 at gmail dot com
> PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
> ricochet:ekmygaiu4rzgsk6n
> xmpp: teor at torproject dot org
> 
> 
> 

T
--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org




signature.asc
Description: Message signed with OpenPGP
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Pluggable Transports 2.0, draft 1 Specification

[Brandon Wiley]

As was discussed in the Pluggable Transports session at TorDev Amsterdam, the
Pluggable Transports 2.0, draft 1 specification [https://www.
pluggabletransports.info/spec/pt2draft1] was created by a committee of
censorship circumvention tool developers: Tor, Lantern, Psiphon, and
uProxy. It specifies a version of Pluggable Transports that meets the needs
of multiple circumvention tools.

There is one major change that has implications for tor, which is that the
Pluggable Transports 2.0, draft 1 IPC protocol uses a different type of
SOCKS authentication mechanism, which allows for larger parameters to be
send to transports.

We are currently working on a 2nd draft of this specification, which will
incorporate changes and errata from the community censorship circumvention
tool community. For instance, syntactic errors in the documentation of the
Go interface will be fixed in draft 2. Tor developers participated in the
specification meetings, and now feedback from the overall Tor community is
requested for incorporation in the next draft. There will also likely be a
2.1 specification process, possibility starting August, where we will
consider larger changes.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev