.
- Bump the version of the utls fork.
Regards,
--
Yawning Angel
signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
As of 0.0.10 it no longer does.
Odd. None of that code, both in obfs4proxy and goptlib, has changed for
years. I'll look at it when I have a moment.
Regards,
--
Yawning Angel
signature.asc
Description: OpenPGP digital signature
___
tor-d
/obfs4proxy/obfs4proxy-0.0.10.tar.xz
https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.10.tar.xz.asc
Changes in version 0.0.10 - 2019-04-12:
- Disable behavior distinctive to crypto/tls when using utls.
- Bump the version of the utls fork.
Regards,
--
Yawning Angel
flage (meek_lite).
- More fixes to HTTP Basic auth.
- (meek_lite) Pin the certificate chain public keys for the default
Tor Browser Azure bridge (meek_lite).
Regards,
--
Yawning Angel
[0]: obfs4proxy WILL NOT build with the upstream version of the library,
and the Firefox fingerprint will not fun
't see much
reason to over engineer it.
Regards,
--
Yawning Angel
signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
arantee that the connection used to
create the inner `http.RoundTripper` instance will be passed to the
correct thread.
Regards,
--
Yawning Angel
signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev
ost` header (depending on how you want to treat TLS).
Regards,
--
Yawning Angel
signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
eek_lite) and would increase compatibility a good amount.
That said HelloChrome_Auto and HelloIOS_Auto both work fine against the
Azure bridge, so it might not be worth the effort.
Regards,
--
Yawning Angel
signature.asc
Description: OpenPGP digital signature
___
tag.
Questions, comments, feedback appreciated,
--
Yawning Angel
signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
gitlab.
Regards,
--
Yawning Angel
signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
AGPL3
network interaction requirement, though there is an exception for
bridges distributed via BridgeDB and those shipped with Tor Browser.
Regards,
--
Yawning Angel
signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
t
h things, focus on such things, rather than being forced to
re-implement large parts of Tor Browser.
Regards,
--
Yawning Angel
[0]: https://lists.torproject.org/pipermail/tbb-dev/2018-January/000743.html
pgp4CNrRmOJJf.pgp
Description: OpenPGP digital signature
_
agenda to allow LEA/governments to exploit Tor
> Browser users easily? Because I don't think maintaining the sandboxed
> version is that much work and it is a great protection for many users.
LOL.
> So please, make Sandboxed Tor Browser an official thing.
Fuck you, pay me.
Reg
ify files elsewhere on the system.
>
> Example:
>
> TOR_PT_STATE_LOCATION=/var/lib/tor/pt_state/
Regards,
--
Yawning Angel
pgpmVyAiuBs22.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproje
of
Covert Channel Censorship Circumvention".
https://www-users.cs.umn.edu/~hoppernj/ccs13-cya.pdf
Regards,
--
Yawning Angel
pgpzXR9N4Leyb.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
commend a bit of a wait for tor to open the AF_UNIX socket.
While it usually is nearly instantaneous on modern systems, I had
intermittent problems with "the socket isn't there" related to trying
too fast.
Regards,
--
Yawning Angel
pg
deal with
this is via using `ControlPortWriteToFile` since the file gets
created after the control port listener is created. You could also use
something like inotify on Linux, but that's non-portable.
Regards,
--
Yawning Angel
pgpbZpZhxZdpl.pgp
Description: OpenPGP digital s
On Mon, 1 Jan 2018 08:45:57 +
nullius wrote:
> On 2017-12-31 at 10:48:52 +0000, Yawning Angel
> wrote:
> >This is pointless because internationalized domain names are
> >standardized around Punycode encoding (Unicode<->ASCII), and said
> >standard is supporte
of homograph attacks either.
> Given appropriate prop-279 changes, I won’t need to draw a proposal.
> I’ll simply write code!
It's worth keeping in mind that no one to my knowledge has implemented
prop 279 in the tor code itself, though there is (IIRC) a python kludge
that kind of
PTs, or someone needs to design an out of band IPC
mechanism between tor and PTs that can signal hibernation status.
The current approach to this problem involves toggling `DisableNetwork`.
See: https://trac.torproject.org/projects/tor/ticket/13213
Regards,
--
Yawning Angel
pgpNsBQxLDZgm.
be something like:
>
> $ tail -c+33 hs_ed25519_secret_key | base64 -w 0
>
> Considering the current situation with the encoded file on disk of
> the key, I think this is kind of the simplest approach?
Yeah. Just the Base64ed private key (excluding that header and things)
tains the ed25519 private key.
If it were up to me, I'd spec the blob as opaque, and then actually use
something that's sensible and consistent with the torrc and on disk
files for easy interoperability like Base64 of the private key (I
haven't check to see what encoding is used for
; because only clients and exits do the SHA1 step.)
I wonder how many of the relays have support for hardware assisted
SHA. (nb: I don't have access to ARMv8, Ryzen or a sufficiently new
Intel system, so I don't know how good the implementations are)
Regards,
--
Yawning Angel
[0]: And d
On Tue, 22 Aug 2017 20:47:06 +0200
Peter Schwabe wrote:
> Yawning Angel wrote:
>
> Hi Yawning, hi all,
>
> > Ultimately none of this matters because Prop. 261 is dead in the
> > water. Assuming people want the new cell crypto to be both fragile
> > and to resist
in the
water. Assuming people want the new cell crypto to be both fragile and
to resist tagging attacks, Farfalle may be a better choice, assuming
there's a Keccak-p parameterization such that it gives adequate
performance.
Regards,
--
Yawning Angel
pgp8RMxKugm9s.pgp
Description:
wasn't
thought to be quantum resistant in anyway shape or form, and providing
quantum resistance wasn't part of the design goals of the primitive, or
really why it was being considered at one point for use in Tor.
Regards,
--
Yawning Angel
pgpKHB9bVRRUJ.pgp
Descript
3
> [snip]
Why are you sending PGP encrypted e-mail to a public mailing list.
--
Yawning Angel
pgpqOKwG4UPWF.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
econd sense of
> pluggability.
I still don't understand what was so hard about implementing the old
API, on anything but iOS.
The "2.0" spec still doesn't have any provisions for using AF_LOCAL
instead of the loopback interface, go figure. It's not as if I brin
ho
drafted the original document don't care as much as I do. I find
the attribution in the acknowledgments section entirely inadequate. I
explicitly credited all previous authors when I last rewrote the
specification for a reason.
Regards,
--
Yawning Angel
pgpgdLflv6ASe.pgp
Descripti
running on
ESR52 + e10s builds, *unless* bubblewrap is version 0.1.8 or newer.
Exiting firefox normally works as intended.
Regards,
--
Yawning Angel
pgpHTTlzoNyE4.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@
correct sandbox functionality to a minimum, and something
that's part of the bundle it downloads/auto updates doesn't feel great
to me.
> Maybe this would be a good target for "experiment with Rust" if
> anyone's excited about writing control-port code in Rus
that to me is orthogonal to "there should be a flexible way to
offload name resolution" (a matter of implementation).
In practical terms the tor code would need modifications to allow
anything super exotic anyway, and I doubt anything will actually get
shipped with Tor Browser[0] till lon
are a usability disaster. It
should be easy for researchers to experiment with designs to solve the
problem *now* before prop224 addresses make a bad situation worse.
There's also a world of difference between implementing/shipping the
capability to override the name resolution
therwise, all it can do is repeatedly NEWNYM" is what I think I ended
up with.
Though I have the benefit of being able to force all application network
traffic through code I control, which makes life easier.
Regards,
--
Yawning Angel
pgptOXuQ3TKU8.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
permail/tor-dev/2015-September/009432.html
https://trac.torproject.org/projects/tor/ticket/21261
https://trac.torproject.org/projects/tor/ticket/11211
Regards,
--
Yawning Angel
pgp_mZKMWdACY.pgp
Description: OpenPGP digital signature
___
tor-de
in a new spec"
has been and apparently still is different from what other people
considers important in a new spec. But if you're going to revise the
spec, at least fix the dual stack problem for fuck's sake.)
Regards,
--
Yawning Angel
[0]: Or &q
.
I spoke with some people and got filled in. I'm not going to look at
the claim, because that's something for a legal department somewhere to
sort out, and not my problem.
Since the Simple variant is easier for others to implement, and
sidesteps the random asshats issue, I don't
the vanilla
NewHope algorithm (and the NewHope-Simple paper does not mention this
at all either).
That said, implementing NewHope-Simple is trivial given NewHope (an
afternoon if that), so it's not something that worries me much.
Regards,
--
Ya
in a project I'm working on anyways.
This sort of tooling should (IMO) ideally be written in C, like
`tor-gencert`. Don't let my opinion here stop you or anything, and
it's just my opinion and does not reflect that of anyone else.
Regards,
--
Yawning Angel
pgpyUrdmhe0TU.pgp
Descri
-browser/sandboxed-tor-browser.git/
Regards,
--
Yawning Angel
[0]: If people are encountering this, particularly with the Debian
package, either upgrade `sandboxed-tor-browser` to the new release, or
update bubblewrap to 0.1.7 or later.
pgpvVzcP1lEqo.pgp
Description: OpenPGP digital signature
s the reason why archive.org is not used? I hear they are almost
> done setting up an onion service for the Internet Archive.
Because, out of all the similar services that are available, I like
archive.is the most.
Regards,
--
Yawning Angel
pgpsmCmx8FO59.pgp
Description: OpenPGP di
rm that this kills clock skew extraction [3] and
> fingerprinting [4] described in Steven Murdoch's papers?
The issue isn't the choice of the hash algorithm, and the patch
doesn't change net/core/secure_seq.c:seq_scale() at all, nor how/when
it's called.
So no, it doesn'
l not work if there is a SOCKS port configured. Basically,
unless you are launching your own copy of the tor daemon, just for
non-anonymous HSes, it's a terrible idea to use these options in
general.
Regards,
--
Yawning Angel
pgpA9Ze34XqQF.pgp
Description: O
point since client access requires a priori
knowledge of the server's public key. I probably won't merge changes,
but as long as you comply with the license I don't care.
Regards,
--
Yawning Angel
pgpGoi22epWzS.pgp
Description: OpenPGP digital signature
_
the only place (by design) that the
sandbox code checks for the `bwrap` binary is `/usr/bin/bwrap` because
people should be getting their bubblewrap from a trusted source, and I
am envisioning a bright future when it's available as a package for all
distributions.
Regards,
--
Yawning Angel
wser/sandboxed-tor-browser.git/
Regards,
--
Yawning Angel
pgpOyKIkmUfTt.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
is at all.
So the answer is, don't use the Linux sandboxing stuff until this sort
of thing is supported, if you have a really exotic config that you want
to have work[0].
Regards,
--
Yawning Angel
[0]: The version number is going to be "0.0.1", and as of now I'm far
more conce
On Thu, 24 Nov 2016 11:13:06 +1100
teor wrote:
> > On 24 Nov. 2016, at 11:04, Yawning Angel
> > wrote:
> >
> > On Thu, 24 Nov 2016 01:43:15 +0200
> > s7r wrote:
> >> I agree that this would be "the technical way" to do it, but real
> >
don't think it's productive to ask users to already support a new
> feature upon our first release providing the said feature.
If they aren't using existing interfaces correctly, when correct
behavior has been part of the interface since support for
1 code and we're all set.
What. Why. Anyone right now, that explicitly wants a v2 service
going forward, should use `ADD_ONION` correctly. It takes the type of
key for a reason.
Regards,
--
Yawning Angel
pgp2wVUuKfIgH.pgp
Description: OpenPGP digital signature
__
o expect `NEW:BEST` ADD_ONION-ed services to always give
RSA1024 based HSes, should fix their code since the spec makes no
guarantee that `BEST` will be RSA1024.)
Regards,
--
Yawning Angel
pgpM1AZw5zcVy.pgp
Description: OpenPGP digital signature
server obfs4
ntor handshake response to be more tollerant of clock skew.
- Reuse the read buffer when consuming obfs4 frames over the network to
reduce memory consumption. Patch by oxtoacart.
Thanks to the Lantern people for the memory consumption fix.
Regards,
--
Yawning Angel
On Sun, 30 Oct 2016 15:19:59 -0500
Tom Ritter wrote:
> On Oct 29, 2016 12:52 PM, "Yawning Angel"
> wrote:
> >
> > On Sat, 29 Oct 2016 11:51:03 -0200
> > Daniel Simon wrote:
> > > > Solution proposed - Static link the Tor Browser Bundle with musl
well.
> > What is Tor developers' opinion about this? I personally don't see
> > any drawbacks and would be interested in discussing this further.
There, opinions.
Regards,
--
Yawning Angel
pgpxDkrgsynV0.pgp
Description: OpenPGP digital signature
the way of the future.
Regards,
--
Yawning Angel
pgpqs3v89ZtsZ.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
ecause it is slow and superseded by ntor.
`src/test/bench` will give concrete numbers (~140 usec on a modern
Intel processor).
Regards,
--
Yawning Angel
pgpXVP7Ehjree.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists
ps://github.com/NullHypothesis/exit-pinning>
Seems reasonable, but
How is this better than "Tor Browser will honor and aggressively
utilize onion addresses in Alt-Svc headers[0]".
Eg: Alt-Svc: onion="onionsarelongandsilly.onion:443"; ma=86400
Regards,
--
Yawning Angel
[0
On Wed, 21 Sep 2016 21:51:10 +
Yawning Angel wrote:
> There shouldn't be anything stopping people from using a nested X
> solution with sandboxed-tor-browser, since it honors DISPLAY and
> writes out a new ~/.Xauthority in the sandbox tmpfs, as long as the
> secondary
h
things correctly.
* Doing things this way gave me more control over the sandbox
environment.
--
Yawning Angel
pgp3SdAZl2YPc.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
rowser patch or two
to fix, but it appears to work fairly well.
The README.md file has more detailed documentation on how it works, the
sandbox environment, and the various caveats.
--
Yawning Angel
pgp9rUAnxRERr.pgp
Description: OpenPGP digital signature
__
ions/permanent" would be safest...?
Adding a third option would probably be the best, followed by extending
the response syntax. As I said, the `GETINFO` stuff was added
explicitly along and for the `ADD_ONION` command, with semantics to
match.
Regards,
--
Yawning Angel
stuff.
> Anyone who wants to open a ticket here, or has a counter argument? :)
Beyond the usual concerns of "the control port allows access to too
much, and has no concept of isolation or ACLs, and this would be a step
towards the worse", not really.
Regards,
--
Yawning Angel
ess is closed
after the ClientHello is sent.
> * statefully track which tickets servers have issued, and block
>connections that use an unknown ticket.
This is probably feasible, particularly by the sort of people that have
been looking at ClientHello already anyway.
Regards
ider it, but I want the onion service to be relatively
> permanent. It would best if the hostname didn't change every time tor
> restarted.
You realize that ADD_ONION supports using an existing private key right?
Like this: ADD_ONION RSA1024:[Blob Redacted] Port=80,192.168.1.1:8080
t;no one has cared enough to write
what should be a simple branch".
Regards,
--
Yawning Angel
pgp6r8Yi9bwDg.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
he sandbox would be a horrible idea.
* Assuming Tor Browser works as advertised, the only reason it needs
control port access for this sort of use case is the circuit display
(as of torbutton commit 36d849291ec0b20a582cd846fcd2540c9bbe,
sending NEWNYM should be unnecessary if domain
overing this (though 6.0a5 did):
> We plan to post instructions for removing the code signing parts on
> our website soon. This should make it easier to compare the bundles
> we build with the actual bundles we ship.
The instructions don't exist yet, see #18925.
Regards,
--
Yawning
ous forms of overhead for breavity. Both types
of documents will be compressed.)
Regards,
--
Yawning Angel
pgptObzOnWY3O.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Fri, 20 May 2016 12:03:59 -0400
Tim Wilson-Brown - teor wrote:
> > On 20 May 2016, at 11:59, Yawning Angel
> > wrote:
> >
> > What's strange about it. The client does the path selection. To
> > build a circuit, the client must know the public keys/ip/p
ut the
microdescriptor list to non-volatile storage either, because
flash is garbage.
* Carry on keeping the working set in RAM under the assumption that
manufacturers will ship more RAM in their routers as time goes on.
Regards,
--
Yawning Angel
pgpZj0Moo4rgo.pg
ChaCha20 or CTR-AES256.
I don't find these changes to be particularly interesting. Any
system where using AES-CTR like this makes sense will benefit more
from using a vectorized NTT/reconciliation.
Regards,
--
Yawning Angel
pgpUYdc4K8BFG.pgp
Descri
itweb.torproject.org/torspec.git/tree/proposals/264-subprotocol-versions.txt
https://gitweb.torproject.org/torspec.git/tree/proposals/249-large-create-cells.txt
With emphasis on the 264, since that's probably how link handshake
crypto support will be signified.
Regards,
--
Yawning Angel
p
really
quickly, but then again, it's VC monopoly money that's paying for it
anyway, and it's not like they ever need to turn a profit right?
(*cough* Twitter *cough*).
Regards,
--
Yawning Angel
pgpH0I4BeIbQd.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
hat at
this moment.
> If not then what is the best way to ensure the custom script survives
> TBB upgrades?
I use diff and patch.
Regards,
--
Yawning Angel
pgpnaMgPYA2Ql.pgp
Description: OpenPGP digital signature
___
tor-dev mailing
eally
win (only `X` and say... `SHA3-256(Z)` (for disambiguation) available
to the attacker means that we win, period regardless of space aliens),
but alas we need to distribute `Z` somehow, so this is somewhat moot
(so ephemeral/static in the forward direction, ephemeral/ephemeral
in the reverse is bett
On Thu, 12 May 2016 14:18:41 +0200
Jeff Burdges wrote:
> On Thu, 2016-05-12 at 11:17 +0000, 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
On Thu, 12 May 2016 11:58:56 +0200
Jeff Burdges wrote:
> On Thu, 2016-05-12 at 05:29 +0000, 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 gu
ething like this is in the
works, and is approaching alpha state, though DID I MENTION NOT TO USE
IT YET?
Questions/Comments/Feedback welcome as always.
Regards,
--
Yawning Angel
pgpJd9awd19ii.pgp
Description: OpenPGP digital signature
___
tor-dev mailing
t have a
quantum computer and calculate `z` to figure out which post quantum
algorithm we are using).
Regards,
--
Yawning Angel
pgpVs_RIBcjGB.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
ch direction in terms of extra network overhead, both
which I think are relatively cheap.
Regards,
--
Yawning Angel
[0]: Along with "I do this for basket2 for other reasons[1], and I think
it's a good idea even for tor".
[1]: newhope public keys are "blatantly obviou
nvironment, gettor in general isn't unblockable because
there is no privacy/security for the request/response messages.
Regards,
--
Yawning Angel
pgpAcHbYWXvYq.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Sun, 08 May 2016 02:00:51 +0200
Jeff Burdges wrote:
> On Sat, 2016-05-07 at 22:01 +0000, 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
n.
So. the evil observer on Alice's side gets:
* The total number of samples (N).
Bob (or Eve) gets:
* The seed, which may correspond to something that required N samples.
I don't think there's much pattern information available to the
attacker on Alice's side, but I may be
related reasons, with something time
based being tossed around, but requiring a global clock isn't that
great, and leaks clock skew information (Though I would use something
like H(tweak | unixTime / 3600), which is rather coarse...), and as a
peace of mind thing, I do prefer randomizing `a` on a per
the key
derivation) might lead to subtle vulnerabilities.
Regards,
--
Yawning Angel
pgpwL77iPpQGl.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
t ntor
implementation does here.
Regards,
--
Yawning Angel
pgplgD63yqxD3.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Fri, 29 Apr 2016 20:54:18 +0200
Jeff Burdges wrote:
> On Sun, 2016-04-03 at 15:36 +0000, Yawning Angel wrote:
> > http://cacr.uwaterloo.ca/techreports/2014/cacr2014-20.pdf
> >
> > Is "optimized" in that, it is C with performance critical parts in
> > assem
rts such a server, as the change is backward
> incompatible.
Neat. I think the header value sounds reasonable (let me know when
this is finalized so I can update `meek_lite`).
Regards,
--
Yawning Angel
[0]: Specifically a non-terrible GCM-AES. The old code didn't use
PCLMULQDQ when calculatin
On Fri, 22 Apr 2016 14:58:45 +0200
Jeff Burdges wrote:
> On Fri, 2016-04-22 at 11:10 +0000, 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
> > >
's favor).
nb: I'm not totally dismissing SIDH, and I do think it has potential.
That said, engineering efforts to protect against "giant datacenters
in Utah" is something that should have been started a decade ago, and
getting something that is adequ
well defined implementations well before
SIDH is a realistic option.
Regards,
--
Yawning Angel
pgplNCEOAyDgG.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
me/yawning/cfc
XPI: https://people.torproject.org/~yawning/volatile/cfc-20160418/
Regards,
--
Yawning Angel
pgpGzQ4vqk3ED.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
wise, with the move to make all relays be dir caches, we already
are increasing memory pressure on "things that are comically undersized
that shouldn't ever be HSDirs or DirCaches in the first place")
Regards,
--
Yawning Angel
pgptbYKlfcCFk.pgp
Description: OpenPGP digital sign
pular, while keeping operators protected
from as much fallout as possible.
Something that sits on top of Tahoe-LAFS perhaps... I have a sense
that the problem space overlaps.
I'm probably just dreaming, and some random person is probably going to
tell me why I'm wrong to want
On Sat, 2 Apr 2016 18:14:26 -0400
Ian Goldberg wrote:
> On Sat, Apr 02, 2016 at 07:19:30PM +0000, 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 w
On Sun, 03 Apr 2016 16:37:45 +0200
Jeff Burdges wrote:
> On Sun, 2016-04-03 at 06:52 +0000, Yawning Angel wrote:
> > Your definition of "reasonably fast" doesn't match mine. The
> > number for SIDH (key exchange, when the thread was going off on a
> >
uits. An
anonymity system where the Exit possesses linkable client identifiers
between circuits/sessions is also a poor anonymity system.
*plonk*
--
Yawning Angel
pgpMTdGCtT5sV.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
ving a few cells is not a good
reason to use a key exchange mechanism that is 1000x slower
(NTRUEncrypt is also fast enough to be competitive).
nb: Numbers are rough, and I don't have SIDH code to benchmark.
newhope in particular vectorizes really well and the AVX2 code is even
faster.
--
Yawning
on's
Razor applies (as opposed to the people that seem to think that Exits
should actively combat abuse by having the capability for censorship).
Regards,
--
Yawning Angel
pgpej7J0FtsRN.pgp
Description: OpenPGP digital signature
___
t
give me warm and happy feelings), so
unless things become unworkable, I'm likely to leave it as the default
for the foreseeable future.
Regards,
--
Yawning Angel
[0]: cfc is FOSS, patches accepted.
pgp2mzv5_3mJW.pgp
Description: OpenPGP digital signature
1 - 100 of 277 matches
Mail list logo
