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 de
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
> &g
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 fea
https://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.torp
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 "
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 ntor
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?
___
hing one could
conceivably use if you really 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
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
arallel on different cores, at least 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 st
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
>
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 if t
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 shot at
[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 the
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&id=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
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 wrote:
> > > >
> > > >
nds 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,
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
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
> number N of participants who are only together be able to reconstruct
> i
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
> > prime-or
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. Th
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 && valid_aft
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:
> >
> > 26e8958fc2b227b045c3f489f2ef98f0d5dfa
On Mon, Apr 24, 2017 at 04:47:44PM +0300, George Kadianakis wrote:
> Ian Goldberg writes:
>
> > On Thu, Apr 20, 2017 at 03:40:58PM +0300, George Kadianakis wrote:
> >> Hey Ian,
> >>
> >> so the current problem with ed25519-donna is that when I'm doi
ill report 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
Cher
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 sugge
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 su
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" wrote:
>
> The other thing to remember is that didn't we already say that
>
> facebookgbiyeqv3ebtjnlntwyvjoa2n7rvpnnaryd4a.onion
>
> and
>
> fa
On Mon, Apr 03, 2017 at 02:53:17PM +0100, Alec Muffett wrote:
> On 3 April 2017 at 13:04, George Kadianakis wrote:
>
> > I'm calling it weird because I'm not sure how an
> > attacker can profit from being able to provide two addresses that
> > correspond to the same key, but I can probably come u
f we're down to just pubkey + checksum + *1 bit of 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 o
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
base32 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 sim
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:
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
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
cksum 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
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 (fa
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
> comment
On Tue, Jun 07, 2016 at 02:27:02AM +0200, ban...@openmailbox.org wrote:
> A paper presented at the Security and Human Behaviour 2016
> conference examining how Tor pluggable transports old up against
> dozens of detection techniques. Censors focus more on detecting
> circumvention techniques during
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 Sat, Apr 02, 2016 at 07:19:30PM +, Yawning Angel wrote:
> It's not a request header set by the browser. archive.is is acting
> like a HTTP proxy and explicitly setting X-F-F.
I wonder what would happen if the browser *also* set X-F-F...?
___
tor-
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 that
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 any
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, cal
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 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
> Status: Draft
>
> 1. Summary
>
>With 0.2.7.2-alpha, all relays will have Ed25519 identity key
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
> > distr
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 ch
ce to give to people wanting to
> > get up to speed on Tor 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 wer
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 Sun, Feb 08, 2015 at 02:01:40AM -0500, Roger Dingledine wrote:
> In the distant past, we had a ".noconnect" special extension in Tor:
> https://gitweb.torproject.org/torspec.git/tree/address-spec.txt#n58
> and the idea was that you would connect to Tor's control port, induce a
> request for foo.
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
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 wi
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 certificate A revokes the key
>of certificate B, and certificate B revokes the key of cert
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
&g
On Mon, Dec 01, 2014 at 09:59:57AM -0500, Nick Mathewson wrote:
> On Mon, Dec 1, 2014 at 9:30 AM, Ian Goldberg 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
> >
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
>
On Fri, Nov 28, 2014 at 03:22:18PM +, Steven Murdoch wrote:
> On 24 Nov 2014, at 18:54, Tom Ritter 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 statemen
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> k
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
> >
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
> automaticall
On Sun, Jul 13, 2014 at 11:01:23PM -0400, grarpamp wrote:
> On Sun, Jul 13, 2014 at 7:23 PM, Ian Goldberg 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
> >> >
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
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
>
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 newlin
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
> resul
y used
Tor (if recentish). Say you're a mobile client that gets a dynamic 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 Profes
On Tue, Apr 08, 2014 at 02:15:12PM -0500, Nicholas Hopper wrote:
> > 4. Interface
> >
> >To use this feature, a router should rename its secret_id_key
> >file to secret_id_key_OLD. The first time that Tor starts and
> >finds a secret_id_key_OLD file, it generates a new ID key if one
>
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
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 F
Is there a Tor-ish paper you'd like to nominate for the 2014 PET Award?
See the CFN below.
Thanks,
- Ian
Call for Nominations
[Please forward and distribute]
You are invited to submit nominations to the 2014 PET Award.
The PET Award is presented annually to researchers who have made an
ou
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. th
On Fri, Jan 17, 2014 at 10:01:13PM -0600, Nicholas Hopper wrote:
> > Yes: Nick (who would probably be the one writing the code anyway)
> > generates the shares encrypted to keys generated by the authority
> > operators, sends them to the authority operators, and forgets the
> > intermediate results
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 se
On Sun, Nov 03, 2013 at 01:14:26PM -0500, m...@rndm.de wrote:
> Hi there,
>
> I worked on a new update for globe. This update addresses some
> features that were missing or not possible in the current version of
> globe ( http://globe.rndm.de/ ).
>
> These changes include:
> - fixed minification
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
ging the unencrypted messages with skulls and crossbones.
Is "skull and crossbones" an easily understandable icon for "message
received insecurely"? It would certainly need a tooltip hint, or
something like that.
> > 7. Logging should be off by default wh
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
> co
On Mon, Sep 30, 2013 at 01:03:14AM -0700, Rohit wrote:
> This should satisfy most goals.
> - A passive attacker wouldn't be able to distinguish between HTTPS->HTTPS
> traffic and Tor->Bridge. (Both use TLS)
This seems false to me; it's not too hard to distinguish Tor-over-TLS
from HTTP-over-TLS,
On Thu, Aug 22, 2013 at 10:25:00AM -0400, Nick Mathewson wrote:
> On Thu, Aug 22, 2013 at 10:17 AM, Ian Goldberg 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
I just tried to upgrade my tor exit node to 0.2.4.16-rc, and got this:
Aug 22 09:55:09.000 [warn] Something tried to close an or_connection_t
without going through channels at src/or/connection.c:3185
Aug 22 09:55:10.000 [warn] Something tried to close an or_connection_t
without going through chan
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
> >"6E2FF9C59A809882E1BAF2BD19
On Fri, Jul 05, 2013 at 09:18:45AM +0200, Karsten Loesing wrote:
> On 7/3/13 5:16 PM, m...@rndm.de wrote:
> >>
> >> Okay. Looking forward to seeing your tool display Onionoo's bridge
> >> details!
> >>
> >
> > I updated it to display bridge detail and enable bridge search. Works
> > fine so far.
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
>
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
>
1 - 100 of 157 matches
Mail list logo
