On Tue, Apr 25, 2023 at 01:02:28PM +0100, Q Misell via tor-dev wrote:
> Security Considerations:
> The second layer descriptor is encrypted and MACed in a way that only a
> party
> with access to the secret key of the hidden service could manipulate what is
> published there. Therefore, Tor
On Tue, Sep 07, 2021 at 11:22:30AM -0700, Neel Chauhan wrote:
> 3. Implementation details
>
> The MiddleOnly flag can be assigned to relays whose IP addresses are
> configured at the directory authority level, similar to how the BadExit flag
> currently works. In short, if a relay's IP is
On Tue, Jul 13, 2021 at 11:34:47AM -0700, Trevor Perrin wrote:
> You also wanted to add an (optional) pre-shared key, which Noise supports:
>
> NKpsk0:
> <- s
> ...
> -> psk, e, es
> <- e, ee
Out of curiosity, Trevor, what properties does this Noise protocol
provide for low-entropy psk?
On Mon, Jul 12, 2021 at 03:09:02PM -0400, Nick Mathewson wrote:
> On Mon, Jul 12, 2021 at 3:04 PM Ian Goldberg wrote:
> >
> > On Mon, Jul 12, 2021 at 12:01:47PM -0400, Nick Mathewson wrote:
> > > Both parties know that they used the same verification string; if
>
On Mon, Jul 12, 2021 at 12:01:47PM -0400, Nick Mathewson wrote:
> Both parties know that they used the same verification string; if
> they did not, they do not learn what the verification string was.
> (This feature is required for HS handshakes.)
I'm not sure the protocol you specify has this
://git-crysp.uwaterloo.ca/sengler/relay-throughput-testing
--
Ian Goldberg
Canada Research Chair in Privacy Enhancing Technologies
Professor, Cheriton School of Computer Science
University of Waterloo
___
tor-dev mailing list
tor-dev@lists.torproject.org
On Wed, Dec 09, 2020 at 10:09:51AM -0500, David Goulet wrote:
> On 07 Dec (15:36:53), Ian Goldberg wrote:
> > On Mon, Dec 07, 2020 at 03:06:43PM -0500, David Goulet wrote:
> > > Greetings,
> > >
> > > Attached is a proposal from Mike Perry and I. Merge
tinguish "not overloaded" from "does not support
this extension"? (Ideally in a better way than checking the tor release
version number and inferring when support was added?)
--
Ian Goldberg
Canada Research Chair in Privacy Enhancing Technologies
Professor, Cheriton Schoo
se stream_id 0
> for any command that doesn't take a stream ID. For commands that
> _do_ take a steam_id, we use whichever nonzero stream_id appeared
> last in this cell.
Do you mean "last in this cell" as in "the one closest to the end of the
cell" or as in "t
On Mon, May 11, 2020 at 04:47:53PM -0400, Nick Mathewson wrote:
> ## INTRODUCE cells, RENDEZVOUS cells, and ntor.
>
> We allow clients to specify the rendezvous point's ntor key in the
> INTRODUCE2 cell instead of the TAP key. To do this, the client
> simply sets KLEN to 32, and includes the
On Wed, Apr 22, 2020 at 11:56:54AM +1000, teor wrote:
> a bad fallback guard can continue to manipulate its client's view of
> the network
This is only true to the extent that the fallback guard can choose which
of three still-valid consensuses to give to the client, right?
lly wanted to keep the current consensus
format, but still prove that this SNIP was part of it,
Cinderella[0]-style.]
[0] https://www.andrew.cmu.edu/user/bparno/papers/cinderella.pdf
Another issue not addressed by the current proposal is how to handle the
"not all the relays have upgraded
On Wed, Jan 09, 2019 at 08:17:15AM -0500, Ian Goldberg wrote:
> On Wed, Jan 09, 2019 at 08:42:18PM +1100, Todd Hubers wrote:
> > There are early plans to distribute crypto operations across multiple cores
> > [https://trac.torproject.org/projects/tor/ticket/1749], but there might
t with the current circuit-level
crypto. But, once circuits are established, handing each circuit to a
different thread/core (or more clever worker structure) is something
that I think at least boradly makes sense, and indeed I have been
proposing to have my students work on.
--
Ian Goldberg
Pr
On Thu, Sep 20, 2018 at 02:47:23PM +0100, Iain Learmonth wrote:
> Hi,
>
> On 20/09/18 00:51, Ian Goldberg wrote:
> > If you make it use, say, the timestamp on the tip git commit of the
> > source, then it's (a) automated, and (b) reproducible. But that's more
> > of
On Thu, Sep 20, 2018 at 09:40:49AM +1000, teor wrote:
> Hi,
>
> This proposal seems good to me.
>
> > On 20 Sep 2018, at 02:20, Nick Mathewson wrote:
> >
> > I propose that when deciding whether to shut down because of
> > subprotocol requirements, a Tor implementation should only shut
> >
>
> The third change prevents an adversary from learning the guard node by way
> of noticing which nodes were not chosen for the hop before it.
To be clear, you are proposing removing these path restrictions for
which circuits? All? All HS-related? All HS-related, but only
On Thu, May 10, 2018 at 12:20:05AM +0700, Suphanat Chunhapanya wrote:
> On 05/09/2018 03:50 PM, George Kadianakis wrote:
> > b) We might also want to look into XEdDSA and see if we can potentially
> >use the same keypair for both intro auth (ed25519) and desc auth
> (x25519).
>
> This will be
On Thu, Apr 19, 2018 at 06:19:29PM +, isis agora lovecruft wrote:
> Ian Goldberg transcribed 2.5K bytes:
> > On Wed, Apr 18, 2018 at 04:53:59PM +0300, George Kadianakis wrote:
> > > Thanks for the help!
> > >
> > > Hmm, so everyone gets a s
[Warning: recovering from illness. Brain may not be operating at
nominal capacity. :-p ]
On Wed, Apr 18, 2018 at 04:53:59PM +0300, George Kadianakis wrote:
> Thanks for the help!
>
> Hmm, so everyone gets a shot at a single malleability "attack" with
> everye d25519 sig? What's the point of
On Thu, Jan 04, 2018 at 05:14:00PM +, nusenu wrote:
> Hi,
>
> it would be great if someone could review this change
> so we can move forward on this topic:
>
> https://gitweb.torproject.org/nickm/tor.git/commit/?h=bug24526=fbb6f9a1865a923ca97c57757a694532faf9fe93
The added "n" and "s" at
f solving infinite
> captchas from Cloudflare.[0][1]
To give proper credit, it's not "Ian and his team at uWaterloo"; it's
"the (now mostly former) Cloudflare people plus Ian".
--
Ian Goldberg
Professor and University Research Chair
Cheriton School of Compute
I just restarted my node, and saw this in the log:
Nov 23 14:07:21.000 [warn] Tried to establish rendezvous on non-OR
circuit with purpose Acting as rendevous (pending)
What does this mean? I'm a little worried someone out there is playing
games with the protocol...
On Wed, Nov 01, 2017 at 09:09:36AM -0400, David Goulet wrote:
> On 01 Nov (07:31:50), Ian Goldberg wrote:
> > On Wed, Nov 01, 2017 at 02:28:03PM +1100, teor wrote:
> > >
> > > > On 31 Oct 2017, at 06:57, David Goulet <dgou...@ev0ke.net> wrote:
> > &
>
> It depends what the goal of the channel layer is.
>
> Do we seriously think we will use another protocol in place of TLS?
The channel layer has certainly been used fruitfully in the past for
experiments with other transports, such as UDP-based ones, QUIC
Are there plans to implement PeerFlow in Tor? Connectivity information
like this would be an automatic byproduct.
- Ian
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
My earlier mail in this thread bounced for Reasons. Here it is again.
- Ian
Thanks for the writeup! Some notes inline.
On Mon, Sep 25, 2017 at 09:26:13AM +0200, Carolin Zöbelein wrote:
> 1. Introduction
>
> Assume, we have a given secret s which we want to share with a
> particular
On Tue, Sep 19, 2017 at 08:29:41PM -0400, Nick Mathewson wrote:
> > Is your goal that someone who sees the *plaintext* of that cell won't be
> > able to tell if it's a legacy RENDEZVOUS1 cell or a new one? If so,
> > life is a bit complicated, since the g^y field will always be in the
> >
Resending from a subscribed address.
On Tue, Sep 19, 2017 at 05:44:46PM +0300, George Kadianakis wrote:
> Hello Ian, (and other cryptographers on the list)
>
> here is a quick question which you might be able to answer super fast:
>
> Legacy RENDEZVOUS1 cells are bigger than the prop224 ones.
On Fri, Jun 23, 2017 at 10:00:28AM -0400, David Goulet wrote:
> Yes. Overlap period is between 00:00 and 12:00 UTC. This is the if condition
> being used:
>
> if (valid_after_tm.tm_hour > 0 && valid_after_tm.tm_hour < 12) { ...
Shouldn't that be
if (valid_after_tm.tm_hour >= 0 &&
On Tue, Apr 25, 2017 at 03:38:37PM +0300, George Kadianakis wrote:
> > It turns out the point whose packed representation is 32 bytes of 0x00
> > is a torsion point; it is the point (-1,0).
> >
> > Indeed, these are the 7 pure torsion points in ed25519:
> >
> >
On Mon, Apr 24, 2017 at 04:47:44PM +0300, George Kadianakis wrote:
> Ian Goldberg <t...@cypherpunks.ca> writes:
>
> > On Thu, Apr 20, 2017 at 03:40:58PM +0300, George Kadianakis wrote:
> >> Hey Ian,
> >>
> >> so the current problem with ed25519-don
eport bwscan results
> again?
> thanks,
> a concerned relayoperator
I am also seeing a strange sudden drop in usage:
https://atlas.torproject.org/#details/BCEDF6C193AA687AE471B8A22EBF6BC57C2D285E
What's going on?
--
Ian Goldberg
Professor and University Research Chair
Cheriton Schoo
On Thu, Apr 06, 2017 at 03:37:35PM +0300, George Kadianakis wrote:
> Hello again,
>
> this is the second subthread of the AONT thread that grew too big for
> its own good, and it's about ed25519.
>
> The topic of this subthread is the above ed25519 verification of onion
> addresses that Ian
On Wed, Apr 12, 2017 at 05:57:00PM +0300, George Kadianakis wrote:
> An update:
>
> After lots of discussions in the Amsterdam Tor meeting, the following
> approach was suggested for cleansing keys of their torsion components
> that is more friendly towards hierarchical key-derivation schemes:
>
Note that the torsion-safe method explicitly *does* result in the low 3
bits being "000". It does not explicity preserve the top bits being
"10", because in discussion, we could not determine an actual reason for
them to be fixed in that way.
Another thing to keep an eye on is how one produces
On Wed, Apr 05, 2017 at 10:02:07AM -0400, David Goulet wrote:
> Another thing about this I just thought of. This AONT construction seems wise
> to use. But it's still not entirely clear to me why we need a 1bit version
> field. Taking this:
>
> base64( AONT( pubkey || 0x ) || version)
>
On Mon, Apr 03, 2017 at 04:40:52PM +0100, Alec Muffett wrote:
> On 3 Apr 2017 3:48 p.m., "Ian Goldberg" <i...@cs.uwaterloo.ca> wrote:
>
> The other thing to remember is that didn't we already say that
>
> facebookgbiyeqv3ebtjnlntwyvjoa2n7rvpnnaryd4a.onion
>
&
f version*, then
I'm not totally sold on the point of the AONT, since there are exactly 0
bits that can be twiddled while not changing the pubkey. *Note*: this
is assuming that if we ever change the version number, *then* we do an
AONT or something so that version 0 and version 1 addresses that have
On Mon, Mar 27, 2017 at 01:59:42AM -0400, Ian Goldberg wrote:
> > 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
2 encoding, I think, so the AONT is back to working on full bytes.
But is a single byte of redundancy enough? It will let through one out
of every 256 typos. (I thought we had spec'd 2 bytes for the checkcum
now, but maybe I misremember? I'm also assuming we're using a simple
256-bit encod
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.
> >
> > Specif
d 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
t; 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 hashin
ch 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 essenti
On Mon, Jan 23, 2017 at 03:36:07PM +0200, George Kadianakis wrote:
> [D2] Checksum strength:
>
> In the suggested scheme we use a hash-based checksum of two bytes (16
> bits).
> This means that in case of an address typo, we have 1/65536 probability
> to not detect the error
On Fri, Jan 13, 2017 at 09:29:25AM -0500, Nick Mathewson wrote:
> Hi, all!
>
> This is a draft for a tor long-term support policy for the program
> "tor". Please let me know what you think. It's based on earlier work
> and surveys, but it isn't final till we say it is, and it needs more
>
I had a crazy thought the other day: has anyone tried running the Linux
version of tor (client or node) on the new GNU/Windows (or whatever
they're officially calling their Linux compatability layer)?
___
tor-dev mailing list
tor-dev@lists.torproject.org
On Mon, Oct 26, 2015 at 06:06:36AM -0700, Mike Perry wrote:
> Essentially, codesign only touches executable binaries in the .app (see
> that second link for info on how the binary's segments get moved around)
> and also adds an SC_Info directory for codesign/DRM metadata.
Wait; does that mean
On Thu, Oct 08, 2015 at 05:04:14PM +0200, Jeff Burdges wrote:
>
> What is the advantage of using X or p-X in UniformDH in obfsproxy?
>
> https://gitweb.torproject.org/pluggable-transports/obfsproxy.git/tree/d
> oc/obfs3/obfs3-protocol-spec.txt#n65
>
> Isn't just X itself dense pretty quickly
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:
0. Browser generates/stores a long term salt.
1. On onion access, calculate
Nice work! A couple of minor comments:
On Mon, Aug 03, 2015 at 05:03:38PM +0300, George Kadianakis wrote:
A shared random document requires 50% + 1 authority signatures to be
considered valid. As this proposal is being written, there are 9
authorities thus we would need 5.
Careful
On Fri, Apr 24, 2015 at 08:05:43PM -0700, Mike Perry wrote:
** Sure, there could be a pile of new attribute flags that could be set
on every HTML resource tag that says the resource must use a secure
http: channel if the parent document happened to load over a secure
channel, but the net
On Fri, Apr 17, 2015 at 08:37:23PM +0200, Peter Palfrader wrote:
On Fri, 17 Apr 2015, Jacob Appelbaum wrote:
I think this list would be created at release time and ship with the
tor binaries/source.
That gives a build person a lot of power - should we expect each
distro to do it
On Mon, Mar 16, 2015 at 04:00:25PM +, Speak Freely wrote:
Hey,
Great read. Very information.
[snip]
Thanks for the edits!
Anywho, I realize it was already published, but wanted to help anyway.
It's quite possible I missed some as well. There were other things I
would have changed,
and its current research questions. Congrats!
aloha,
Paul
On Fri, Mar 13, 2015 at 02:01:56PM +0100, Ian Goldberg wrote:
As I mentioned at the dev meeting, Mashael and I were just finishing up
a survey paper on Tor performance and security research.
The tech report version was just
As I mentioned at the dev meeting, Mashael and I were just finishing up
a survey paper on Tor performance and security research.
The tech report version was just posted on eprint:
https://eprint.iacr.org/2015/235
for your perusing pleasure. ;-)
Thanks,
- Ian
On Thu, Jan 22, 2015 at 05:18:10PM +0100, Mohiuddin Ebna Kawsar wrote:
how tor knows which socket belongs to which stream, and so to which
circuit ?
which function handle this mapping??
I would guess it's the on_circuit member of the edge_connection_t
struct, but others could probably give a
On Thu, Jan 22, 2015 at 04:19:55PM +0100, Mohiuddin Ebna Kawsar wrote:
Hi,
Suppose an exit node is acting as Exit for 2 different client connected by
2 different middle and guard node.
suppose one of the client make http get request which will pass through
Exit and TCP packet Header will be
On Tue, Dec 02, 2014 at 08:57:09PM +, George Kadianakis wrote:
This is worth researching and even implementing a PoC of. There are
various places in the Tor protocols that PIR could be applied.
However I don't know how feasible it is for an MSc thesis. I remember
that Ian Goldberg had
On Mon, Dec 01, 2014 at 09:14:03AM -0500, Nick Mathewson wrote:
Then how about specifying something like this for the RSA-signed part
(in place of the SHA1):
[fixed string] 8 bytes
[SHA512 signature] 32 bytes
Where the fixed sting could be something like HSNONTOR, and we can
reserve
On Mon, Dec 01, 2014 at 09:59:57AM -0500, Nick Mathewson wrote:
On Mon, Dec 1, 2014 at 9:30 AM, Ian Goldberg i...@cs.uwaterloo.ca wrote:
On Mon, Dec 01, 2014 at 09:14:03AM -0500, Nick Mathewson wrote:
Then how about specifying something like this for the RSA-signed part
(in place
On Fri, Nov 28, 2014 at 03:22:18PM +, Steven Murdoch wrote:
On 24 Nov 2014, at 18:54, Tom Ritter t...@ritter.vg wrote:
Attached is a document written in the specification format for one
aspect of CA-signed .onion addresses - specifically a What is a safe
way to sign (or not sign) a
On Wed, Nov 12, 2014 at 09:30:47AM +0100, Karsten Loesing wrote:
Hi George,
I found this in my IRC backlog from November 7, 2014:
20:34 #tor-dev: asn karsten: how should one read these graphs
https://metrics.torproject.org/bandwidth.html#bandwidth-flags ?
20:34 #tor-dev: asn karsten:
On Wed, Sep 10, 2014 at 08:31:56AM +0200, Peter Palfrader wrote:
On Tue, 09 Sep 2014, Ian Goldberg wrote:
On Tue, Sep 09, 2014 at 04:35:15PM -0400, Peter Swire wrote:
You've avoided that for both binaries and sources? That's interesting. I
guess it makes sense, if it's been a problem
On Tue, Sep 09, 2014 at 04:35:15PM -0400, Peter Swire wrote:
Dear Roger,
You've avoided that for both binaries and sources? That's interesting. I
guess it makes sense, if it's been a problem before.
I mostly would like to be able to wget the the sources and build them
automatically,
On Sun, Jul 13, 2014 at 11:01:23PM -0400, grarpamp wrote:
On Sun, Jul 13, 2014 at 7:23 PM, Ian Goldberg i...@cs.uwaterloo.ca wrote:
On Sun, Jul 13, 2014 at 07:20:29PM -0400, grarpamp wrote:
/* Don't actually allow compression; it uses ram and time, but the
data
* we transmit
On Sun, Jul 13, 2014 at 07:20:29PM -0400, grarpamp wrote:
/* Don't actually allow compression; it uses ram and time, but the data
* we transmit is all encrypted anyway. */
result-ctx-comp_methods = NULL;
This comment is confusing. Why are you asserting/mixing the two with
the
On Fri, Jul 11, 2014 at 01:44:36PM +0300, George Kadianakis wrote:
Hey Nick,
this mail is about the schemes we were discussing during the dev
meeting on how to protect HSes against guard discovery attacks (#9001).
I think we have some ideas on how to offer better protection against
such
Just some spec-level nitpicking.
On Fri, Jul 04, 2014 at 10:22:59AM +0200, Virgil Griffith wrote:
The value field must be printable ASCII (characters 32-126).
Presumably all values are literal? There's no special meaning to , \,
etc.?
The value must not under any condition contain a newline.
On Sat, May 31, 2014 at 05:51:16PM +0100, George Kadianakis wrote:
Hello Ian,
hope you are well :)
I have a question wrt a new PT and ntor.
Yawning Angel has been developing a new PT called obfs4 (temp name),
which is basically scramblesuit using ntor and elligator2. This
results in
IP
address. With this, you reveal that you probably aren't or maybe are
the same person that was last seen over there at that particular time.
What are the implications here?
--
Ian Goldberg
Associate Professor and University Research Chair
Cheriton School of Computer Science
University
On Tue, Apr 01, 2014 at 12:02:23PM -0400, Zack Weinberg wrote:
On 04/01/2014 11:23 AM, Griffin Boyce wrote:
In your git config, you can define a pushurl that is different from
url. Which effectively means that you can pull from github but push
to tor.
That's not the issue; the issue
On Wed, Mar 19, 2014 at 12:01:09PM +0100, Marc Juarez wrote:
Hi everyone,
Thanks for the answers. Some inline comments below.
You may also be interested in our new tech report:
T. Wang, X. Cai, R. Nithyanand, R. Johnson and I. Goldberg
Effective Attacks and Provable Defenses for Website
On Tue, Feb 25, 2014 at 02:06:39AM +, George Kadianakis wrote:
And because release-early-release-often, here is a graph:
https://people.torproject.org/~asn/guards/guard_boxplot_4000.png
The middle boxplot is the probability distribution of our current
guard selection process (e.g. the
On Sat, Jan 18, 2014 at 01:40:43AM +, Matthew Finkel wrote:
obfs3 is supposed to be fairly difficult to detect because entropy
estimation is seemingly more difficult than typically assumed,
and thus far from what has been seen in practice this seems to be true.
Wouldn't the way to detect
On Tue, Jan 07, 2014 at 06:41:02AM -0800, Jacek Wielemborek wrote:
Hi,
I recently had an opportunity to watch David Fifield's lightning talk on
pluggable transports that he gave on 30C3. I find the topic fascinating and
I'm
considering an application to your project for the upcoming
On Sun, Nov 17, 2013 at 07:33:12PM -0800, David Stainton wrote:
Hi,
I noticed that because the obfsproxy api can sometimes buffer and
resend smaller chunks of data. My simple use of Nacl stream_crypto to
wrap each incoming data buffers will not work... that is because the
client and server
On Tue, Oct 29, 2013 at 03:10:50PM -0400, David Goulet wrote:
That would work if there is a way I can differ the hijack of the
syscall symbol... Unfortunately, this is done at linking time thus
during run time, the syscall symbol is already hijacked by torsocks.
Let say we don't try to
private key.
Or, store the key on a hardware token.
The number of arbitrary file read bugs in pidgin makes me cry...
How is private information (e.g. passwords) stored in InstantBird now?
--
Ian Goldberg
Associate Professor and University Research Chair
Cheriton School of Computer Science
On Thu, Oct 03, 2013 at 02:34:50PM -0700, Malard Joel wrote:
Do you think that the code at https://github.com/malardj/ slice, that uses
neither encryption nor a password, could help a community proof their
communications from massive systemic eavesdropping by making the latter
On Thu, Aug 22, 2013 at 10:25:00AM -0400, Nick Mathewson wrote:
On Thu, Aug 22, 2013 at 10:17 AM, Ian Goldberg i...@cs.uwaterloo.ca wrote:
I just tried to upgrade my tor exit node to 0.2.4.16-rc, and got this:
I rebuilt without bufferevents, and it hasn't crashed yet. (I also
don't see
On Sat, Jul 06, 2013 at 07:36:01AM -0400, m...@rndm.de wrote:
Added them both and fixed the bug where it defaults the search to
'relays'. The last version should also hash all the 40char hex
strings for search requests.
Hmm. I do see that it's hashing the data/fingerprint entry, but onionoo
On Fri, Jul 05, 2013 at 10:57:28AM -0400, m...@rndm.de wrote:
Sleek. ;-)
I thought I saw on this thread that searching for bridges by their
fingerprints is supposed to work, but it does not appear to for mine.
I'm just pasting the hex string (like
On Thu, Jun 27, 2013 at 03:11:23PM -0400, David Goulet wrote:
Ian Goldberg:
On Wed, Jun 26, 2013 at 03:55:58PM -0400, David Goulet wrote:
Hi everyone,
For those who don't know, I've been working on a new version of Torsocks
in the last three weeks or so.
https://lists.torproject.org
On Tue, Jun 18, 2013 at 09:56:21PM +0200, Lunar wrote:
Matthew Finkel:
Some months ago, the petname system interested me enough that I started
to write a proposal for it. At this point, it's wound up in bitrot.
Though I'd spent a bit of time working on it, there was no comprehensive
way
On Mon, Jun 03, 2013 at 09:38:30PM -0400, David Goulet wrote:
There might be some rebasing going on in that branch in the next weeks
so please don't consider it right now as git stable since I'm in the
heavy part of getting everything together before starting a normally
growing master branch.
On Tue, May 28, 2013 at 03:59:15PM +0100, Steven Murdoch wrote:
Hi Chang,
We've been discussing how to build better pluggable transports for Tor as
part of your application to Google Summer of Code. Now that you've been
accepted, I thought it would be good to bring this discussion to
On Thu, May 02, 2013 at 10:58:54AM -0400, MF Nowlan wrote:
I am working on integrating uTCP and uTLS (
http://arxiv.org/abs/1103.0463) into Tor to see if we can lower the
latency due to head of line blocking across circuits.
You have to be careful to preserve cell ordering *within* circuits,
On Sat, May 04, 2013 at 12:13:09PM -0400, MF Nowlan wrote:
What you're saying about HOL blocking in the output queue for a relay makes
sense if the receive window fills up, but I didn't explain how uTCP actually
works. uTCP (and paired with uTLS) is a kernel patch that will expose to the
On Sun, Jan 27, 2013 at 04:37:55PM +, Jacob Appelbaum wrote:
Hi Ian,
This version of Torsocks is the initial bug clean up that will lead us
into fixing larger issues such as that one. We think this is a good idea
as a few of those bugs are quite a lot of work and there were many
On Mon, Dec 31, 2012 at 02:36:30PM -0800, Damian Johnson wrote:
So here's what I propose. For the next couple months stem will have an
open beta. If you'd like to have input on the future of our python
controller space then please give Stem a try and tell me the
following...
* What pain
lines 30-32:
# Let a,A=KEYGEN() yield a new private-public keypair in G, where a is
# the secret key and A = EXP(g,a). If additional checks are needed to
# insure a valid keypair, they should be performed.
s/insure/ensure/
Should those checks be specified? In particular, you need to ensure
On Wed, Dec 12, 2012 at 04:52:11AM +0200, George Kadianakis wrote:
Let p = 3 mod 4 be prime, with q=(p-1)/2 also prime, and p is at least
1536 bits. (2048 if there's room.) [Use group 5 or group 14 from RFC
3526.] Let g be a generator of the order-q subgroup of Z_p^* (g=2 for
the
On Wed, Dec 12, 2012 at 11:14:08AM -0500, vmonmoonsh...@gmail.com wrote:
The only issue with your trick, is that I'm not looking forward
implementing a custom DH key exchange in Python (especially the DH
parameter generation and public key validation parts).
From the conversation of Zack
On Wed, Dec 12, 2012 at 03:13:59AM +0200, George Kadianakis wrote:
Ian Goldberg i...@cs.uwaterloo.ca writes:
[Should we not be copying tor-dev on this thread?]
We definitely should.
Is it OK if I forward the whole thread to tor-dev (including this mail
and your reply)? Feel free
On Mon, Dec 03, 2012 at 10:36:54PM -0500, Nick Mathewson wrote:
On Mon, Dec 3, 2012 at 10:19 PM, Mike Perry mikepe...@torproject.org wrote:
Thus spake George Kadianakis (desnac...@riseup.net):
Hi,
- Started researching and developing obfs3, an improved version of the
obfs2 pluggable
On Mon, Nov 19, 2012 at 05:06:58PM -0500, Nick Mathewson wrote:
On Sun, Nov 18, 2012 at 7:43 PM, Andrea Shepard and...@torproject.org wrote:
I've made some notes on parallelizing cell crypto on relays which I've
attached to this mail and added to the wiki page on this [1], which I
would
On Mon, Nov 19, 2012 at 05:29:50PM -0500, Nick Mathewson wrote:
Circuit-related public key should already be parallelized
(configurably, via the NumCPUs option).
Wow; I totally missed that. I've turned the node back to a single
process with a 14MB limit, and set NumCPUs to 4. Let's see what
On Mon, Sep 10, 2012 at 02:33:30AM -0600, vmon wrote:
3) Thank you for telling me about fts. I'm going to replace boost code with
fts soon.
What is fts? This sounds potentially useful.
Thanks,
- Ian
___
tor-dev mailing list
1 - 100 of 114 matches
Mail list logo
