Re: [tor-dev] Draft Proposal: Random Number Generation During Tor Voting

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, Sending the comments from #tor-dev here as well. This is related to the attack where exactly half of the directory authorities commit to some values, and the last directory authority can send different values to both camps, and have the

Re: [tor-dev] Draft Proposal: Random Number Generation During Tor Voting

I'm not a big fan of automated systems that ban authorities as it may get false positives and it may be gamed and/or attacked. An alternative solution is to make the voting a two-step system: first you publish the sha256 hash of your vote, then a few minutes later you publish the actual vote.

Re: [tor-dev] Draft Proposal: Random Number Generation During Tor Voting

> On 7 Sep 2015, at 23:36, David Goulet wrote: > ... > Please review it, mostly format of the state (before the SR document) > has changed. As well as a new "conflict" line is added to the vote. > … > If an authority sees two distinct commitments from an other authority in >

Re: [tor-dev] Draft Proposal: Random Number Generation During Tor Voting

Hello! While working on the implementation of this proposal, we realized that it was much more complicated to add a new consensus flavor than we originally anticipated. nickm then suggested to NOT use this new flavor (shared random document) and instead change it to a persistent state on disk

Re: [tor-dev] Towards a new version of the PT spec...

Yawning Angel writes: > So, we currently have a Pluggable Transport (PT) spec, and it kind-of > sort-of works (The documentation is a mess that I'm working on > cleaning up, but it's an orthogonal issue for how well it works). > > There are a number of problems with the

Re: [tor-dev] fteproxy depends on obfsproxy...

Response inline. On Mon, Sep 7, 2015 at 3:29 PM, Yawning Angel wrote: > On Mon, 7 Sep 2015 14:37:07 -0700 > Kevin P Dyer wrote: > > > ...and it shouldn't. > > > > Fortunately, the dependency is isolated to a single file. See [1]. > > > > My

[tor-dev] Towards a new version of the PT spec...

So, we currently have a Pluggable Transport (PT) spec, and it kind-of sort-of works (The documentation is a mess that I'm working on cleaning up, but it's an orthogonal issue for how well it works). There are a number of problems with the current PT spec that require breaking backward

Re: [tor-dev] fteproxy depends on obfsproxy...

On Mon, 7 Sep 2015 17:03:00 -0700 Kevin P Dyer wrote: > Response inline. > > On Mon, Sep 7, 2015 at 3:29 PM, Yawning Angel > wrote: > > > On Mon, 7 Sep 2015 14:37:07 -0700 > > Kevin P Dyer wrote: > > > > > ...and it shouldn't. > >

[tor-dev] fteproxy depends on obfsproxy...

...and it shouldn't. Fortunately, the dependency is isolated to a single file. See [1]. My understanding is that pyptlib [2] is no longer maintained. wiley/asn/etc. - What's the proper way to remove this dependency, but make it easy for fteproxy to be a PT? -Kevin [1]