Filename: 240-auth-cert-revocation.txt
Title: Early signing key revocation for directory authorities.
Author: Nick Mathewson
Created: 09-Jan-2015
Status: Draft
1. Overview
This proposal describes a simple way for directory authorities to
perform signing key revocation.
2. Specification
On Tue, Jan 6, 2015 at 1:54 PM, Sebastian G.
wrote:
> 06.01.2015, 18:51 Andrea Shepard:
>> Here's a proposal Nick Mathewson and I just wrote for ticket #11157.
>>
>> [...]
>> 1. Introduction and overview
>>
>> To avoid some categories of attacks aga
On Sun, Jan 11, 2015 at 4:23 AM, Peter Palfrader wrote:
> On Sat, 10 Jan 2015, Nick Mathewson wrote:
>
>>This proposal describes a simple way for directory authorities to
>>perform signing key revocation.
>>
>> 2. Specification
>>
>>We add th
On Sun, Jan 11, 2015 at 6:33 AM, Ian Goldberg wrote:
> On Sat, Jan 10, 2015 at 03:46:32PM -0500, Nick Mathewson wrote:
>> 5. Circular revocation
>>
>>My first attempt at writing a proposal here included a lengthy
>>section about how to handle cases where ce
On Thu, Jan 22, 2015 at 1:12 AM, Frédéric CORNU wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Dear all,
>
> The Tor Manual [1], as of today, says that ORListenAddress option is
> deprecated and that same behaviour can be achieved by specifying the
> listening address within the OR
Hi!
Here's my plan for the Tor 0.2.6 feature freeze.
I had hoped to to the freeze today, but I'm going to be travelling to
a kid's birthday party for most of the day. So instead, I'm aiming
for *Monday* for merging all features that are done, and giving
possible extensions to high-value features
Filename: 241-suspicious-guard-turnover.txt
Title: Resisting guard-turnover attacks
Author: Aaron Johnson, Nick Mathewson
Created: 2015-01-27
Status: Draft
1. Introduction
Tor uses entry guards to prevent an attacker who controls some
fraction of the network from observing a fraction of
This is an update to the Tor proposal status overview. I last sent one
of these out almost a year ago; since 0.2.6 has entered feature freeze,
I really ought to do this regularly again.
Future versions of this document will be maintained in the torspec
repository as "proposals/proposal-status.txt
Hi, all!
Work on the Tor 0.2.6.x release series will proceed on the
"maint-0.2.6" branch; releases will be build against "release-0.2.6".
The master branch new has Tor 0.2.7.0-alpha-dev.
cheers,
--
Nick
___
tor-dev mailing list
tor-dev@lists.torprojec
Filename: 242-better-families.txt
Title: Better performance and usability for the MyFamily option.
Author: Nick Mathewson
Created: 2015-02-27
Status: Open
1. Problem statement.
The current family interface allows well-behaved relays to
identify that they all belong to the same 'f
On Tue, Mar 10, 2015 at 6:07 AM, George Kadianakis wrote:
> Hello Nick,
>
> I noticed that the 0.2.6.3 changelog does not contain the
> guardfraction blurb of #9321. I think this happened in
> c2312f4f5fbc37581180f53fb67edb70f3360104 where the bug9321 file was
> deleted but its contents were not a
On Mar 12, 2015 8:26 PM, wrote:
>
> I love short 2-3 letters commands, they feel super UNIX-y and arm was one
of them.
> Some alternatives:
>
> trm - Tor Relay Monitor
> Can't find any notable clash in https://en.wikipedia.org/wiki/TRM
> Clash if read as "trim"
>
> tm - Tor Monitor
> Maybe clashin
On Thu, Mar 12, 2015 at 11:16 PM, Mike Perry wrote:
>
> As fair warning, I am very likely to decide that it will be better to
> ship 0.2.7.x in TBB 5.0-stable on Aug 11th, as I suspect that the risk
> from things like PT compatibility and control port compatibility issues
> will actually make a r
On Fri, Mar 13, 2015 at 11:50 AM, Isabela wrote:
> This is a great discussion, thanks Mike for writing down TBB release
> process.
>
> I think is very important to start being more strategical on how we plan the
> different projects releases. Of course this doesn't mean we have to force a
> big ch
On Sun, Mar 15, 2015 at 4:30 PM, Mike Perry wrote:
[...]
> Thanks for breaking out all the options, Isabela and Nick!
>
> After more consideration of all of them, given that these next few
> months will be spent mostly doing rebase work, I think either Option 2
> or Option 4 above seem like the b
On Wed, Mar 18, 2015 at 6:15 AM, Nusenu wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hi,
>
> 'systemctl reload tor'
> fails due to hardening restrictions in tor's systemd service file [1]:
>
> CapabilityBoundingSet = CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE
>
> Removing that li
Hi! I've got an end-of-month deliverable to flesh out as many good
ideas here as I can, and I'd appreciate feedback on what kind of
features it would be good to add to the controller protocol in order
to better support testing.
More ideas would be most welcome.
Yes, some of these ideas are proba
On Sun, Mar 22, 2015 at 12:12 AM, Sebastian Hahn
wrote:
> Hi there,
>
> we have some functions which we never call anywhere. In many cases, it
> appears we shouldn't delete them from the source because they "belong"
> there - the thing I initially stumbled across was
> ed25519_seckey_write_to_file
On Mon, Mar 23, 2015 at 8:56 AM, Nusenu wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hi,
>
> I like prop242 [1] because it doesn't "Nuke MyFamily" [2] but replaces
> it with a better approach. "Better" in terms of scalability and
> maintainability.
>
> I don't know of any current
0. Summary
I've got some end-of-month deliverables to try to figure out how Tor
fits together to identify the most important areas to test, the
hardest areas to test, and the best ways to modularize Tor in the
future. Here's my current draft. Some of these ideas are
half-baked; ma
On Fri, Mar 20, 2015 at 11:55 AM, Nick Mathewson wrote:
> Hi! I've got an end-of-month deliverable to flesh out as many good
> ideas here as I can, and I'd appreciate feedback on what kind of
> features it would be good to add to the controller protocol in order
> to
On Fri, Mar 27, 2015 at 1:28 AM, Mike Perry wrote:
> Mike Perry:
>> In Tor Browser 4.5a5, we decided to increase MaxCircuitDirtiness to 2
>> hours (https://trac.torproject.org/projects/tor/ticket/13766).
>>
>> Because we also use Tor's SOCKS username isolation using the URL bar
>> domain as the SO
On Fri, Mar 27, 2015 at 11:34 AM, Isabela wrote:
> Hello there!
> we are almost done with the triage of 0.2.7 - we have a good chunk of
> tickets organized into 2 groups at the spreadsheet.
>
> Now what I would like to ask people from today till our next IRC meeting
> (Core Tor meeting on Wednesda
Hi, all!
Since Isabela is ill (get well soon, Isabela!), I've tried to
translate the results of 0.2.7 triage onto the bugtracker. To ensure
that everything is reversible, I've tagged items with:
027-triaged-1-in
027-triaged-1-out
027-triaged-1-deferrable.
I've then moved all of the 027-tri
Hi!
Here are some notes on Donncha O'Cearbhaill's design proposal at
https://gist.github.com/DonnchaC/03ad5cd0b8ead0ae9e30 . (David asked
me to write these up in time for them to be useful.)
You'll probably understand what I'm saying here a lot better if you
read the link above. :)
In general
Filename: 244-use-rfc5705-for-tls-binding.txt
Title: Use RFC5705 Key Exporting in our AUTHENTICATE calls
Author: Nick Mathewson
Created: 2015-05-14
Status: Draft
1. Proposal
We use AUTHENTICATE cells to bind the connection-initiator's Tor
identity to a TLS session. Our current ty
On Sun, May 24, 2015 at 2:32 PM, Ondrej Mikle wrote:
> On 05/24/2015 05:19 AM, Lars Boegild Thomsen wrote:
>> On Friday 22 May 2015 09:20:29 Shawn Nock wrote:
>>> Will you post the Makefile for the buildroot package?
>>
>> Sorry guys, I sorted this one out. The culprit was actually my added
>> -
I posted this on a blog comment, but others may be interested too.
As near as I can tell, the "logjam"/"weakdh" attacks should not affect
current Tor software very much, for a few reasons:
* All currently supported Tor versions, when built with OpenSSL 1.0 or
later, prefer 256-bit elliptic
m: Karsten Loesing
> To: Nick Mathewson
>
> Ugh, long mail ahead. This turns out to be more difficult than
> expected...
Just like life itself! Never fear, we will solve all problems and
build a better world.
> On 29/05/15 19:29, Nick Mathewson wrote:
>> On Fri,
On Sat, May 30, 2015 at 5:16 PM, Karsten Loesing wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 30/05/15 16:44, Nick Mathewson wrote:
>> On Fri, May 29, 2015 at 4:23 PM, Karsten Loesing
>> wrote:
>>>> router euler [scrubbed] 8000 0 0 identity-
On Mon, Jun 1, 2015 at 3:27 AM, Karsten Loesing wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Nick,
>
> On 31/05/15 16:21, Nick Mathewson wrote:
>> On Sat, May 30, 2015 at 5:16 PM, Karsten Loesing
>> wrote:
>>> So, I think a "fi
Filename: 245-tap-out.txt
Title: Deprecating and removing the TAP circuit extension protocol
Author: Nick Mathewson
Created: 2015-06-02
Status: Draft
0. Introduction
This proposal describes a series of steps necessary for deprecating
TAP without breaking functionality.
TAP is the original
Hello, all!
Usually the Tor development team has our weekly online[1] Tor
developers meetings at Wednesday 1330 UTC (==0930 EDT), and our weekly
online patch workshop time at 1800 UTC (==1400 EDT).
(This is for the program 'tor', not for all the other software that
happens in the Tor universe)
B
On Sun, Jun 28, 2015 at 2:12 PM, Cory Pruce wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hey,
>
> I see now that the multithreading on the crypto operations is at least
> partly resolved (#9682) but there still exists more to be done. I could
> help on the condition variables and
I'm about to go on vacation, but before I started, Isabela asked me
for coverage information on Tor, to help people decide where more
tests should be written.
I've re-run coverage, and uploaded the gcov output here:
https://people.torproject.org/~nickm/volatile/coverage-65a1e27.tar.bz2
That arch
tl;dr: CVE-2015-1793 does not appear to affect Tor. Update your
OpenSSL anyway; other applications are certainly affected.
Hi, all!
Here's the announcement for today's major security issue in
OpenSSL1.0.2c, 1.0.2b, 1.0.1n and 1.0.1o:
https://www.openssl.org/news/secadv_20150709.txt
So far,
On Thu, Jul 9, 2015 at 11:44 AM, intrigeri wrote:
> Moritz Bartl wrote (09 Jul 2015 14:21:26 GMT) :
>> Just copy the /lib/systemd/system/tor.service file to
>> /etc/systemd/system and edit it there -- it will take precedence over
>> the one in /lib . You don't want to edit the one in /lib directly
On Sat, Mar 21, 2015 at 7:33 PM, Matthew Finkel
wrote:
>
> Hi All,
>
> Here's an updated version of prop 237. I rewrote some parts
> for clarity and brought it inline with the current implementation
> for #12538.
>
> Updated branch on prop237_update in my torspec repo.
>
Thanks! Just merged to t
On Tue, Jun 30, 2015 at 9:01 PM, wrote:
> I'd like to introduce two new works on website fingerprinting I've written
> with my supervisor, Ian Goldberg.
>
> The first is titled ``On Realistically Attacking Tor with Website
> Fingerprinting''. We talk about methods to allow website fingerprinting
Filename: 248-removing-rsa-identities.txt
Title: Remove all RSA identity keys
Authors: Nick Mathewson
Created: 15 August 2015
Status: Draft
1. Summary
With 0.2.7.2-alpha, all relays will have Ed25519 identity keys. Old
identity keys are 1024-bit RSA, which should not really be considered
On Tue, May 19, 2015 at 3:20 PM, Gisle Vanem wrote:
> This gcc-centric macro in or/config.c doesn't work well in
> MSVC v16/18:
>
> #define COMPLAIN(args...) \
> STMT_BEGIN log_warn(LD_CONFIG, args); STMT_END
>
> I suggest it should be patched like this:
>
> --- a/config.c 2015-05-06 22:22
On Wed, Jul 15, 2015 at 7:54 PM, Ian Goldberg wrote:
> On Wed, Jul 15, 2015 at 01:37:06PM -0400, Nick Mathewson wrote:
>> Filename: 248-removing-rsa-identities.txt
>> Title: Remove all RSA identity keys
>> Authors: Nick Mathewson
>> Created: 15 August 2015
>&g
Yawning's mail below reminds me: I am considering removing the C
implementation of tor-fw-helper from the tor distribution, and recommending
Yawning's pure-Go implementation instead. But before I do this, I'd like
to get some sense of whether folks are shipping tor-fw-helper today, or
using it in
On Fri, Jul 17, 2015 at 6:32 AM, Gisle Vanem wrote:
> Nick Mathewson wrote:
>
>> I made the changes conditional on not having GCC, since the GCC syntax
>>
>> will work with older versions of GCC. (Somebody should check whether
>> we care about those versions.)
>
On Tue, Jul 21, 2015 at 11:56 AM, Yawning Angel wrote:
> On Tue, 21 Jul 2015 11:38:00 -0400
> Nick Mathewson wrote:
>
>> Yawning's mail below reminds me: I am considering removing the C
>> implementation of tor-fw-helper from the tor distribution, and
>>
Filename: 249-large-create-cells.txt
Title: Allow CREATE cells with >505 bytes of handshake data
Authors: Nick Mathewson
Created: 23 July 15
Status: Draft
1. Summary
There have been multiple proposals over the last year or so for
adding post-quantum cryptography to Tor's circuit e
On Mon, Aug 3, 2015 at 6:55 PM, s7r wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi,
>
> Tor 0.2.7.x will support Ed25519 router identities along with the
> traditional 1024-bit RSA ones which will be used simultaneously for
> some time, until we will completely deprecate RSA rou
On Tue, Aug 4, 2015 at 8:24 PM, s7r wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 8/4/2015 5:42 PM, Nick Mathewson wrote:
>> Hi, s7r!
>>
>> This is an impressive writeup; thanks!
>>
>> One thing that makes it hard for me to follow t
On Sat, Aug 8, 2015 at 9:05 AM, Roger Dingledine wrote:
> On Sat, Aug 08, 2015 at 11:36:35AM +, Alec Muffett wrote:
>> 5) taking a cue from World War Two cryptography, breaking this into banks of
>> five characters which provide the eyeball a point upon which to rest, might
>> help:
>>
>>
On Thu, Aug 6, 2015 at 6:26 PM, s7r wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> I am also sending the steps I imagine Tor should take when started as
> a relay. Apologies if I am missing something obvious.
>
> They are expressed as simple as possible, Tor's interpretation is way
On Mon, Aug 10, 2015 at 1:11 PM, nusenu wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hi,
>
> https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2028
>
>> If 3 or more authorities provide a Measured= keyword for a router,
>> the authorities produce a consensus containing
On Wed, Aug 12, 2015 at 11:59 AM, Alec Muffett wrote:
> Aside: in pursuit of helping Jake register “.onion” as a "special name” in
> an RFC, I am currently being beaten-up on the IETF discussion mail-list
> regards the potential future length of onion addresses, and that they may
> possibly exceed
On Wed, Aug 12, 2015 at 5:34 PM, nusenu wrote:
> from today's measurement meeting:
>
>> 15:00:20 karsten: I've decided I'm going to fix the definition of
>> median
>> 15:00:26 in the tor sourcecode
>> 15:00:36 virgil: is it broken?
>> 15:00:53 or just not specified as clearly as it should be?
Hi, all!
Here's the schedule we worked out for the Tor 0.2.7 feature freeze.
(These are defaults, not promises. We can make exceptions, but please
remember that delaying a freeze will delay release, and every day we
delay a release will delay all the _other_ features getting out into a
stable To
On Fri, Aug 21, 2015 at 12:12 AM, Mike Perry wrote:
> Filename: xxx-netflow-padding.txt
> Title: Padding for netflow record resolution reduction
> Authors: Mike Perry
> Created: 20 August 2015
> Status: Draft
>
Added as proposal 251!
___
tor-dev mailing
Hi!
I've moved all the TorCoreTeam201508 tickets to TorCoreTeam201509 or
out entirely. I've also moved some of them to the 0.2.8 milestone,
and tentatively assigned the PostFreeze027 ticket to others.
If I'm wrong about any of those, please feel free to fix 'em!
Now I'm moving on to the 0.2.7 m
On Wed, Aug 26, 2015 at 10:35 AM, Nick Mathewson wrote:
> Hi!
>
> I've moved all the TorCoreTeam201508 tickets to TorCoreTeam201509 or
> out entirely. I've also moved some of them to the 0.2.8 milestone,
> and tentatively assigned the PostFreeze027 ticket to others.
>
On Tue, Sep 8, 2015 at 7:10 AM, David Goulet wrote:
> On 08 Sep (01:04:36), Tim Wilson-Brown - teor wrote:
>>
>> > 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
On Wed, Sep 9, 2015 at 4:21 PM, George Kadianakis wrote:
> Nick Mathewson writes:
>
>> On Tue, Sep 8, 2015 at 7:10 AM, David Goulet wrote:
>>> On 08 Sep (01:04:36), Tim Wilson-Brown - teor wrote:
>>>>
>>>> > On 7 Sep 2015, at 23:36, David G
On Thu, Sep 24, 2015 at 7:49 AM, Isabela wrote:
> Hello everyone!
>
> We are planing on doing a triage session for 0.2.8 release in Berlin!
> Below is some guidance of what you can do to prepare for that, also what
> you can do if you are planning on being there but want to help build the
> releas
Hi, all!
I hope things are going well for you.
This week, many tor developers are all at a meeting in Berlin. So,
there will probably be far fewer people than usual at the Tuesday
patch workshop time or at the Wednesday tor status meeting. We should
be back as usual next week!
peace,
--
Nick
[This isn't done yet, but I've shown it to enough people that I should
share it with the list.]
1. Introduction and background
1.1. Motivation
Frequently, we find that very old versions of Tor should no longer be
supported on the network. To remove relays is easy enough: we
simply upda
On Wed, Oct 7, 2015 at 11:56 AM, David Goulet wrote:
> Hello tor-dev!
>
> While 028 bug triaging, we realized that we *really* need priorities to
> not be a banana field deprive of useful meaning. If you are unaware or
> don't remember, the priority field in a trac ticket can be:
>
> blocker c
On Wed, Sep 30, 2015 at 11:27 AM, Tom van der Woerdt wrote:
> Hey all,
>
> I'd like your thoughts and comments on this proposal.
>
> Tom
>
>
> PS: If you want to deliver them in person, I'm in Berlin.
>
>
>
>
> Filename: xxx-intro-rendezvous-controlsocket.txt
> Title: Load-balancing hidden service
On Thu, Oct 8, 2015 at 4:37 AM, Tim Wilson-Brown - teor
wrote:
>
> On 8 Oct 2015, at 05:01, Nick Mathewson wrote:
>
> On Wed, Oct 7, 2015 at 11:56 AM, David Goulet wrote:
>
> Hello tor-dev!
>
> While 028 bug triaging, we realized that we *really* need priorities to
[This is a draft proposal; I'm not giving it a number yet. I'm hoping
it'll receive some good advice.]
Filename: xxx-aez-relay.txt
Title: AEZ for relay cryptography
Author: Nick Mathewson
Created: 13 Oct 2015
Status: Draft
1. Summary and preliminaries
This proposal descri
On Tue, Oct 13, 2015 at 8:05 AM, Mike Perry wrote:
> Nick Mathewson:
[...]
>> (How fast is it?
>>
>> To encrypt a 509-byte relay cell with a 16 byte nonce and 32 bytes
>> of additional data, AEZ only uses 360 aes rounds. This is the same
>>
Filename: 256-key-revocation.txt
Title: Key revocation for relays and authorities
Authors: Nick Mathewson
Created: 27 October 2015
Status: Open
1. Introduction
This document examines the different kinds of long-lived public keys
in Tor, and discusses a way to revoke each.
The kind of
Filename: 257-hiding-authorities.txt
Title: Refactoring authorities and taking parts offline
Authors: Nick Mathewson, Andrea Shepard
Created: 2015-10-27
Status: Draft
1. Introduction
Directory authorities are critical to the Tor network, and represent
a DoS target to anybody trying to
Hi!
Reminder 1: There is a weekly meeting where we talk about development
progress on the program "tor".
Reminder 2: It has been at 1330 UTC; it is still at 1330 UTC for this
week. (Remember, some of the world has made DST changes, but not all
of the world.)
Reminder 3: It will be at a different
[Here's a new proposal from Andrea. See ticket 4581 for
implementation details.]
Filename: 258-dirauth-dos.txt
Title: Denial-of-service resistance for directory authorities
Author: Andrea Shepard
Created: 2015-10-27
Status: Open
1. Problem statement
The directory authorities are few in numb
On Thu, Oct 29, 2015 at 5:01 PM, isis wrote:
> Hello,
>
> For your reviewing pleasure, may I present you with a new (draft) proposal for
> a new entry guard selection algorithm, and associated data structures (with
> reference implementations!). [0] The bulk of it is based upon George
> Kadianaki
On Thu, Oct 29, 2015 at 9:19 AM, Yawning Angel wrote:
> Hello all,
>
> In an attempt to make Pluggable Transports more accessible to other
> people, and to have a spec that is more applicable and useful to other
> projects that seek to use Pluggable Transports for circumvention, I have
> drafted a
Hello all!
As a reminder, we have a weekly patch workshop and a weekly
developer's meeting on the #tor-dev IRC channel on OFTC.
With the ending of DST in the US, these times are now convenient for
even fewer people than before. With that in mind, we're changing!
The new times will be effective s
On Wed, Nov 4, 2015 at 4:06 AM, Karsten Loesing wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello developers,
>
> in the past few days I have been working on a grammar to parse Tor
> bridge network statuses and hopefully other Tor descriptors in the
> future. It's working, for so
On Thu, Nov 5, 2015 at 1:31 AM, Tim Wilson-Brown - teor
wrote:
>
> On 3 Nov 2015, at 13:01, Nick Mathewson wrote:
>
> Secondary meeting time and patch workshop:
> Monday at 0100 UTC (8:00pm EST, 5:00pm PST)
>
>
> Hi Nick,
>
> I'm not sure which time
On Fri, Nov 6, 2015 at 11:16 AM, teor wrote:
> Hi all,
>
> Is there any reason an onion service would want to temporarily switch from
> 1-hop to 3-hop paths?
> Is it ok if we force operators to restart the tor instance when onion
> service path lengths change?
Just said on IRC, but saying here to
On Fri, Nov 13, 2015 at 1:51 PM, nusenu wrote:
> Hi,
>
> since tor 0.2.7.5 is apparently not very far [1] from being released I
> was wondering whether there is any documentation about the new offline
> master key functionality?
Hi! There's a draft faq at https://trac.torproject.org/projects/tor/
immediately. For the last draft, see
https://www.mail-archive.com/tor-dev@lists.torproject.org/msg07104.html
.]
Filename: xxx-aez-relay.txt
Title: AEZ for relay cryptography
Author: Nick Mathewson
Created: 13 Oct 2015
Last-changed: 29 Nov 2015
Status: Draft
0. History
I wrote the first draft of
On Sun, Nov 29, 2015 at 7:06 PM, Tim Wilson-Brown - teor
wrote:
>
> On 30 Nov 2015, at 09:13, Nick Mathewson wrote:
> ...
> 2.2. New relay cell payload
> ...
> When encrypting a cell for a hop that was created using one of these
> circuits, clients and relays encry
Hi, all!
(This is about the IRC meeting on OFTC on #tor-dev to talk about
developing the program called "tor".)
We have have fewer people at the new Wednesday time than we did at the
old one. That's not great. The Monday/Tuesday time is convenient for
a bunch of folks, though, so that's nice.
S
On Thu, Dec 10, 2015 at 1:10 PM, Lain Iwakura wrote:
> Hello guys;
>
> Sorry such silly questions novice.
> But what IDE you use, and why? In Linux, of course.
> ... For C and python.
> I see Eclipse (Mars), but it seems more to own java.
> Codeblocks, perhaps?
>
> Excuse me still could not find m
-- Forwarded message --
From: Nick Mathewson
Date: Thu, Dec 10, 2015 at 2:49 PM
Subject: Weekly Tor developers meetings; IRC time change!
To: tor-dev@lists.torproject.org
Hi, all!
(This is about the IRC meeting on OFTC on #tor-dev to talk about
developing the program called
On Mon, Nov 30, 2015 at 2:12 AM, Tim Wilson-Brown - teor
wrote:
> Hi Nick,
>
> The AEZ paper says:
>
> "We impose a limit that AEZ be used for at most 2^48 bytes of data (about
> 280 TB); by that time, the user should rekey. This usage limit stems from
> the existence of birthday attacks on AEZ, a
On Mon, Dec 28, 2015 at 5:34 PM, Zhenfei Zhang
wrote:
> Hi list,
>
> This is a proposal to use quantum-safe hybrid handshake for Tor
> communications.
> Given NSA's recent announcement on moving towards quantum-safe cryptography,
> it would be nice to have a quantum-safe feature for Tor.
>
> The i
[Okay, I'm pulling this out of draft stage. Still not sure this is the
right primitive, but I'm pretty sure this would be about the right way
to do it.]
Filename: 261-aez-crypto.txt
Title: AEZ for relay cryptography
Author: Nick Mathewson
Created: 28 Oct 2015
Status: Open
0. History
[Proposal 261 probably needs this.]
Filename: 262-rekey-circuits.txt
Title: Re-keying live circuits with new cryptographic material
Author: Nick Mathewson
Created: 28 Dec 2015
Status: Open
1. Summary and Motivation
Cryptographic primitives have an upper limit of how much data should
be
On Thu, Dec 31, 2015 at 3:51 PM, isis wrote:
> Zhenfei Zhang transcribed 22K bytes:
[...]
>> In addition, this is a modular design that allows us to use any quantum-safe
>> cryptographic primitives. As a proof of concept, we instantiated the
>> protocol with NTRUEncrypt lattice-based crypto. We
Filename: 264-subprotocol-versions.txt
Title: Putting version numbers on the Tor subprotocols
Author: Nick Mathewson
Created: 6 Jan 2016
Status: Open
1. Introduction
At various points in Tor's history, we've needed to migrate from one
protocol to another. In the past, we'
On Thu, Jan 7, 2016 at 9:35 AM, Mike Perry wrote:
> Mike Perry:
>> 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
On Mon, Jan 11, 2016 at 9:16 AM, Zhenfei Zhang
wrote:
> Hi list,
>
> Thanks for all your valuable comments.
> We have updated the feature request following your comments.
> Please see the attachment for the updated feature request, and see
> https://github.com/zhenfeizhang/ntru-tor/commit/0354fe1d
So, one of the longstanding problems with Tor's (change) proposal
system has been that proposals sit around for a long time without
sufficient discussion or approval. When they're about to be
implemented, we do an informal "hey did anybody look at that?" check,
but that's not really good enough.
On Tue, Jan 12, 2016 at 8:53 AM, Mike Perry wrote:
> This proposal aims to allow us to load balance properly between Guard,
> Middle, and Exit nodes with the addition of padding traffic to the
> network.
>
> Canonical proposal current lives in my load_balancing-squashed branch:
> https://gitweb.to
On Thu, Jan 7, 2016 at 12:12 PM, Nick Mathewson wrote:
> [This is a significantly revised version of the last version of this
> proposal draft, sent here for comment.
>
> The last version of this draft was
> https://lists.torproject.org/pipermail/tor-dev/2015-September/009587.ht
On Sun, Jan 17, 2016 at 8:39 PM, isis wrote:
> Nick Mathewson transcribed 2.8K bytes:
>> Here's the schedule I have in mind for the first meeting, based on
>> proposals already nominated at the IRC dev meeting.
>
> This idea and the schedule sound great to me. (Min
As mentioned on the other thread, George and David (who wrote proposal
250) can't make it at the originally planned time. So instead, we'll
be discussing proposal 250 at 11 am eastern (1600 UTC) on Tuesday!
(I'll still be around at the planned time to talk about patches and
code and whatever.)
c
On Mon, Jan 25, 2016 at 5:14 AM, David Goulet wrote:
> On 18 Jan (07:13:36), Tim Wilson-Brown - teor wrote:
>>
>> > On 15 Jan 2016, at 03:31, David Goulet wrote:
>> >
>> >> Friday January 29: 8:30 am eastern (1330 UTC)
>> >>
>> >> Prop#252: Single Onion Services [DRAFT]
>> >> Prop#260: R
On Tue, Jan 26, 2016 at 9:01 PM, Tim Wilson-Brown - teor
wrote:
>
> On 26 Jan 2016, at 23:19, David Goulet wrote:
>
> On 26 Jan (07:00:31), Nick Mathewson wrote:
>
> On Mon, Jan 25, 2016 at 5:14 AM, David Goulet wrote:
>
> On 18 Jan (07:13:36), Tim Wilson-Brown - teo
Somebody always asks whether Tor is affected by each OpenSSL advisory,
so I'm sending this mail in order to get a URL to send people to. :)
Here are today's advisories:
https://mta.openssl.org/pipermail/openssl-announce/2016-January/61.html
With respect to the first ( "DH small subgroups
Hi, friends!
This is a followup to the previous thread on the subject of proposal
reviews. If you didn't read it, you can find it here:
https://lists.torproject.org/pipermail/tor-dev/2016-January/010219.html
[If you don't know how proposals work, see Lunar's explanation here:
https://lists
1 - 100 of 807 matches
Mail list logo
