> On 7 Dec 2021, at 19:26, Jeff Burdges wrote:
> I advise against allowing any libp2p cruft into tor itself though.
Among the many reasons. I’d expect libp2p to be a nightmare of downgrade
attacks, given the amount of badly rolled stuff they must still support, like
their dangero
I work on a project that selected libp2p, but only write cryptographic code,
not networking code.. I’d caution against using libp2p for anything serious.
Protocol Labs always took a pretty sophomoric approach: libp2p managed to be
better than ethereum’s but ignored almost everyone working in
I realize this would be the wrong part of the Tor project to which to suggest
this, but I know the people on this list and I do not know the people elsewhere
in Tor, and there is some small technical content here, so..
There are now a bunch of proof-of-stake cybercoins aka crypto-currencies, li
>> The French state is making a glosing about the "privacy-preserving",
>> "anonymous" contact tracing app they are developing with Inria (national
>> informatics research agency). You can check about the protocol proposal,
>> ROBERT, here: https://github.com/ROBERT-proximity-tracing/documents
There is another component of the design space:
Do you want credentials to be movable from one introduction point to another?
If so, you can do this or not with both blind signatures and OPRFs by enabling
or restricting their malleability properties, but probably not with anything
symmetric. I
> On 2019-06-20 00:19, Watson Ladd wrote:
>>
>> Privacy Pass has already been integrated into Tor Browser. Perhaps
>> work could be done to use it here?
>
> As I said above, any oblivious PRF scheme like privacy pass violates privacy
> *if* you can supply different keys to different users. We
On 2019-06-20 00:19, Watson Ladd wrote:
>
> Privacy Pass has already been integrated into Tor Browser. Perhaps
> work could be done to use it here?
As I said above, any oblivious PRF scheme like privacy pass violates privacy
*if* you can supply different keys to different users. We cannot de
As a rule, proof-of-work does not really deliver the security properties people
envision. We’ve no really canonical anti-sibel criteria in this case, but
maybe some mixed approach works:
First, introduction points have a default mode in which they rate limit new
connections and impose some ar
If I understand, proposal 295 looks similar to either BEAR or LION from the
LIONNESS. I vaguely recall both BEAR and LION being "broken" in some setting,
although I cannot site the paper. Anyone?
I suppose the BEAR and LION break originates from using them for authentication
while proposal 2
If I understand, proposal 295 looks similar to either BEAR or LION from the
LIONNESS. I vaguely recall both BEAR and LION being "broken" in some setting,
although I cannot site the paper. Anyone?
I suppose the BEAR and LION break originates from using them for authentication
while proposal 2
On Sat, 2016-10-01 at 14:35 +0200, ban...@openmailbox.org wrote:
> Since there were plans to use this service to circumvent Cloudflare
> CAPTCHAs and now its behind Cloudflare itself (it requires users to
> execute JS to access content) what alternative is planned for the
> upcoming CFC addon?
On Wed, 2016-09-28 at 19:45 -0400, Jesse V wrote:
> I am curious, what is your issue with the subdomains? Are you
> referring to enumerating all subdomains, or simply being able
> to confirm that a particular subdomain exists?
Yes, confirmation of subdomans can become a problem in some contexts
w
I'll add a note on GNS to your wiki George, but..
On Sat, 2016-08-20 at 16:48 +0300, George Kadianakis wrote:
> We really need to start serious work in this area ASAP! Maybe let's
> start by
> making a wiki page that lists the various potential solutions (GNS,
> Namecoin,
> Blockstack, OnioNS, et
I suspect the two known families you "do not want to rule out" are SIDH
schemes and LWE schemes with no ring structure, like Frodo. At present
SIDH is too slow and LWE keys are too big, but both could improve
dramatically over the next several years.
Jeff
signature.asc
Description: This is
Just a a couple questions :
Is SIDH costing 100 times the CPU such a big deal, assuming it's running
on another thread? Can it be abused for DOS attacks for example? Is
that CPU time needed for symmetric crypto? etc. If so, is it worth
restricting to your guard node?
Is New Hope's 3+ times
On Thu, 2016-05-12 at 15:54 +0200, Peter Schwabe wrote:
> Can you describe a pre-quantum attacker who breaks the non-modified
> key
> exchange and does not, with essentially the same resources, break the
> modified key exchange? I'm not opposed to your idea, but it adds a bit
> of complexity and I
On Thu, 2016-05-12 at 11:17 +, Yawning Angel wrote:
> Well, if we move the handshake identifier inside the AE(AD) envelope,
> we can also add padding to normalize the handshake length at minimal
> extra CPU cost by adding a length field and some padding inside as
> well.
>
> It would remove so
On Thu, 2016-05-12 at 05:29 +, Yawning Angel wrote:
> and move the handshake
> identifier into the encrypted envelope) so that only the recipient
> can see which algorithm we're using as well (So: Bad guys must have
> a quantum computer and calculate `z` to figure out which post quantum
> algo
On Sun, 2016-05-08 at 13:15 +, isis wrote:
> Also, deriving `a` "somehow" from the shared X25519 secret is a bit
> scary
> (c.f. the §3 "Backdoors" part of the NewHope paper,
Oh wow. That one is nasty.
> or Yawning's PoC of a
> backdoored NewHope handshake [0]).
>
> [0]:
> https://git.sch
On Sat, 2016-05-07 at 22:01 +, Yawning Angel wrote:
> how an adversary will be limited to just this information, and not
> things that enable a strong attack on it's own like packet timing
> escapes me
Yes, it's clear that an adversary who can get CPU timing can get packet
timing.
It's not
On Sat, 2016-05-07 at 13:14 -0700, Watson Ladd wrote:
> I'm not sure I understand the concern here. An attacker sees that we
> got unlucky: that doesn't help them with recovering SEED under mild
> assumptions we need anyway about SHAKE indistinguishability.
We're assuming the adversary controls a
On Sat, 2016-05-07 at 19:41 +, lukep wrote:
> It's hard to guarantee that any fixed, finite amount of SHAKE
> output will be sufficient for any rejection sampling method
> like gen_a.
Isn't some small multiple usually enough? I think 1024 is large enough
to tend towards the expected 42%ish f
Just a brief aside about post-quantum handshake approaches that
seemingly do not work.
I suppose Tor folk remember the article Using Sphinx to Improve
Onion Routing Circuit Construction by Aniket Kate and Ian Goldberg.
As key sizes are a main obstacle to a post-quantum key exchange,
one might
On Fri, 2016-05-06 at 19:17 +, isis wrote:
> --- Description of the Newhope internal functions ---
>
> gen_a(SEED seed) receives as input a 32-byte (public) seed. It expands
> this seed through SHAKE-128 from the FIPS202 standard. The output of
> SHAKE-128
> is considered a sequence
On Sun, 2016-04-03 at 15:36 +, Yawning Angel wrote:
> http://cacr.uwaterloo.ca/techreports/2014/cacr2014-20.pdf
>
> Is "optimized" in that, it is C with performance critical parts in
> assembly (Table 3 is presumably the source of the ~200 ms figure from
> the wikipedia article). As i said,
On Fri, 2016-04-22 at 11:10 +, Yawning Angel wrote:
> On Fri, 22 Apr 2016 11:41:30 +0200
> Jeff Burdges wrote:
> > I'd imagine everyone in this thread knows this, but New Hope requires
> > that "both parties use fresh secrets for each instantiation".
>
&
I'd imagine everyone in this thread knows this, but New Hope requires
that "both parties use fresh secrets for each instantiation".
I suppose any key exchanges designed around this meshes well enough with
ntor, so that's okay. It leaves you relying on ECDH for the key
exchange with long term k
Should we try to organize some public chat about web caching at PETs or
HotPETs this summer?
By that I mean, a discussion with anonymity researchers on security and
anonymity concerns around making tools like Yawning's CFC a long-term
solution to the CloudFlare problem?
Aside from our not know
On Sat, 2016-04-02 at 18:48 -0400, Jesse V wrote:
> I just wanted to resurrect this old thread to point out that
> supersingular isogeny key exchange (SIDH) is the isogeny scheme that
> that you're referring to. Using a clever compression algorithm, SIDH
> only needs to exchange 3072 bits (384 byt
Are there any more sites where CloudFalre appears on archive.is?
https://www.aei.org/publication/gen-michael-hayden-on-apple-the-fbi-and-data-encryption/
https://archive.is/7u5P8
It's some particularly harsh CloudFlare configuration perhaps?
Jeff
signature.asc
Description: This is a digita
the-resolution-of-the-bitcoin-experiment-dabb30201f7
It sometimes works if you hit refresh though.
> * Look into adding a "contact site owner" button as suggested by Jeff
>Burdges et al (Difficult?).
Just noticed this minimalist whois client in node.js :
https://github.com/carl
On Wed, 2016-03-23 at 14:09 -0400, Paul Syverson wrote:
> On Wed, Mar 23, 2016 at 12:33:15PM -0400, Adam Shostack wrote:
> > Random thought: rather than "unreachable from Tor", "unreachable when
> > using the internet safely." This is really about people wanting
> > security, and these companies n
Thank you, Yawning! This looks great. :)
I think Kate was planning on writing up an official position of the Tor
project on the CloudFlare situation. Amongst other things, it's
expected to contain several strong arguments for convincing sites that
the CAPTCHA does them no good and to make the
etter freenet using grants for
"security" work. And the long game would be to guilt the browser
makers and web standards people into tightening things up.
On Fri, 2016-02-19 at 20:57 +0100, Jeff Burdges wrote:
> On Fri, 2016-02-19 at 16:21 +, Spencer wrote:
> > At what
Symmetric crypto might start worrying more about being post-quantum
soon : http://arxiv.org/abs/1602.05973
Best,
Jeff
signature.asc
Description: This is a digitally signed message part
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lis
On Fri, 2016-02-19 at 16:21 +, Spencer wrote:
> At what point do the efforts to patch Firefox out weigh the efforts
> to build a browser from scratch?
Browsers are extremely complicated.
If you want to explore Mozilla's efforts to build a more modern
browser, then I suggest you look over an
On Fri, 2016-01-01 at 11:14 +, Yawning Angel wrote:
> On Thu, 31 Dec 2015 20:51:43 +
> isis wrote:
> [snip]
> > I feel like there needs to be some new terminology here. It's
> > certainly not post-quantum secure, but "quantum-safe" doesn't seem
> > right either, because it's exactly the
Appears Isis has interesting work that addresses the bridge problem
much more directly than anything in this thread.
On Fri, 2015-12-11 at 15:52 +0100, Henry de Valence wrote:
> > Taler is an electronic payment system that was built with the goal
> > of supporting taxation. With Taler, the re
On Thu, 2015-12-10 at 13:22 +0200, George Kadianakis wrote:
> The next idea would be to rate limit based on a different scarce
> resource
> (e.g. Bitcoin, passport, etc.). All of them kind of suck for
> different
> reasons, but maybe some of them are fine for most threat models.
After we get
I've been talked into formally participating in the W3C Payment
Interest/Working Group as part of working on GNU Taler, well my
employer INRIA is a member.
Drop me a line if there is anything I can do/say/watch to help keep
that potential standard tor friendly.
Best,
Jeff
p.s. There are relate
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 anyways?
Jeff
signature.asc
Description: This is a digitally signed messag
wants.
On Mon, 2015-09-28 at 16:26 -0400, Roger Dingledine wrote:
> On Mon, Sep 28, 2015 at 03:20:47PM +0200, Jeff Burdges wrote:
> > I proposed that Tor implement NameService rules using UNIX domain
> > sockets, or ports, since that's how GNUNet works, but maybe Tor
On Wed, 2015-09-30 at 15:39 +0200, Tim Wilson-Brown - teor wrote:
> > First, Tor adds the line "ACE :" to the
> > node's
> > Second, Tor allows connections to ip:port as if the torrc contains
> > :
> >ExitPolicy allow:
> > As ExitPolicyRejectPrivate defaults to 1, these policies should be
I have attached below the second half of the Special-Use TLD proposal
that discusses how a local name service tool contact a peer-to-peer
application running on an exist node
There is nothing specific here to providing name services, any peer-to
-peer application might potentially want an anycas
On Tue, 2015-09-29 at 00:59 +, Jeremy Rand wrote:
> Do I infer correctly that the main intention of this is to decrease
> the possibility of attack by a Sybil attack on the Namecoin network,
> by making the Namecoin peer selection process have similar properties
> to Tor relay selection (which
On Mon, 2015-09-28 at 16:26 -0400, Roger Dingledine wrote:
> On Mon, Sep 28, 2015 at 03:20:47PM +0200, Jeff Burdges wrote:
> > I proposed that Tor implement NameService rules using UNIX domain
> > sockets, or ports, since that's how GNUNet works, but maybe Tor
> > s
On Sun, 2015-09-27 at 19:47 +0200, Jeff Burdges wrote:
...
> Configuration
>
...
> NameService [.]dnspath socketspec
> [noncannonical] [timeout=num]
> [-- service specific options]
>
> We require that socketspec be either the path to a UNIX domain
> sock
geration though, maybe "server name
consistency system" or something. I don't think this really impacts
the spec since the DNS terminology is well defined.
On Mon, 2015-09-28 at 15:32 -0300, hellekin wrote:
> On 09/27/2015 02:47 PM, Jeff Burdges wrote:
> >
> >
On Mon, 2015-09-28 at 00:05 +0200, Tom van der Woerdt wrote:
> Questions :
> * are those directives handled on the relay or the client? If relay,
> how will the client know which node to talk to?
They route name resolution requests on the client to another piece of
software on the client. That
On Sun, 2015-09-27 at 22:31 +, Jeremy Rand wrote:
> On 09/27/2015 05:47 PM, Jeff Burdges wrote:
> >
> > This is the first of two torspec proposals to help Tor work with
> > Sepcial-Use TLDs, like the GNU Name system or NameCoin. The second
> > part will be an
On Sun, 2015-09-27 at 23:32 +0200, Tim Wilson-Brown - teor wrote:
> I have some questions about how NameSubstitution rules work in some
> edge cases:
In truth, I originally wrote the NameSubstitution rules bit for the
.gnu TLD. In the end, Christian explained why that doesn't work,
mostly that th
This is the first of two torspec proposals to help Tor work with Sepcial-Use
TLDs, like the GNU Name system or NameCoin. The second part will be an anycast
facility. - Jeff
Filename: xxx-special-use-tld-support.txt
Title: Special-Use TLD Support
Author: Jeffrey Burdges
Created: 20 Sept 2
As an aside, we chatted briefly about the naming options for single
onion services or whatever at CCC camp. Amongst those present, there
was no strong love for any existing naming proposal. An interesting
naming idea surfaced however :
We do not want people using these anyways unless they know
A per browser salt is a wonderful idea. It's basically impossible to
fake even small key poems or whatever if you cannot guess their salt.
Just some thoughts :
- The salt should be a text field users can interact with easily. It
could be displayed prominently in the extensions config, or eve
| = *S. |
> | o |
> | |
> | |
> | |
> ---
>
> The idea came up during a discussion with Jeff Burdges in CCC camp.
> This is a heavily experimental idea and there are various unresolved research
> and UX issues here, but we hope that we will motivate furt
On Sun, 2015-08-09 at 07:26 +, Jeremy Rand wrote:
> > Isn't the 51% attack down to a 20ish% attack now?
>
> The estimate I did was based on Namecoin hashrate, not Bitcoin
> hashrate. I assume that's the distinction you're referring to, though
> you're not really making it clear.
No. I haven
> I did a
> rough calculation about a year ago of how much it would cost to buy
> ASIC miners that could 51%-attack Namecoin, and it came out to just
> under a billion USD.
Isn't the 51% attack down to a 20ish% attack now?
> Of course, a real-world attacker would (in my
> estimate) probably
> On Sat, Aug 08, 2015 at 11:36:35AM +, Alec Muffett wrote:
> > 4) from Proposal 244, the next generation addresses will probably be
> > about this long:
> >
> > a1uik0w1gmfq3i5ievxdm9ceu27e88g6o7pe0rffdw9jmntwkdsd.onion
> >
> > 5) taking a cue from World War Two cryptography, bre
On Thu, 2015-07-16 at 14:37 -0400, grarpamp wrote:
> On Thu, Jul 16, 2015 at 1:22 PM, Tom van der Woerdt wrote:
> > https://en.wikipedia.org/wiki/If_and_only_if
>
> Aha, documentation, use presumed consistent, carry on, thanks.
Actually the "use it freely" reference there describes iff as a
bord
On 28 May 2015, at 12:59, Michael Rogers wrote:
>
> I wasn't thinking about the sizes of the sets so much as the probability
> of overlap. If the client picks n HSDirs or IPs from the 1:00 consensus
> and the service picks n HSDirs or IPs from the 2:00 consensus, and the
> set of candidates is f
On 28 May 2015, at 11:45, Michael Rogers wrote:
> On 12/05/15 20:41, Jeff Burdges wrote:
>> Alright, what if we collaboratively select the RP as follows :
>>
>> Drop the HSDirs and select IPs the way 224 selects HSDirs, like John
>> Brooks suggests. Protect HSs from
On 12 May 2015, at 10:39, Michael Rogers wrote:
> Something like this was suggested last May, and a concern was raised
> about a malicious IP repeatedly killing the long-term circuit in order
> to cause the HS to rebuild it. If the HS were ever to rebuild the
> circuit through a malicious middle
Interesting idea!
I was toying with another unrelated idea which seems worth asking about now :
Can we shorten the circuits used for hidden services any? At present, both
the introduction point (IP) connection and the rendezvous point (RP) connection
have seven (interior) hops, right?
I
On 20 Mar 2015, at 12:33, Jeff Burdges wrote:
> I could imagine an “onion token” variant of ephemeral hidden services in
> which the person who initiates the connection does not know what they’re
> connecting to, like sending a message to a mailbox. Example :
>
> Alice wants
I could imagine an “onion token” variant of ephemeral hidden services in which
the person who initiates the connection does not know what they’re connecting
to, like sending a message to a mailbox. Example :
Alice wants Bob to send her a message asynchronously by anonymously dropping it
into
This little session at 31c3 may be of interest to anyone working on Tor
Messenger. -Jeff
> From: Ximin Luo
> Subject: [messaging] Session at 31C3
> Date: 22 December 2014 at 7:13:22 EST
> To: Messaging
>
> For those of you going to 31C3, we are going to meet up and find a side room
> to hav
I’m interested in helping out with this, mostly because we’ll want it for Pond
: https://pond.imperialviolet.org/
I’ve read the alpha-mixing paper, but not the others, so I’ll check em’ out.
Jeff
On 9 Dec 2014, at 16:40, Michael Rogers wrote:
> Signed PGP part
> On 25/11/14 12:45, George
67 matches
Mail list logo
