Tor Relays wrote:
David Goulet:
However, I'm not sure we should always let 1 authority dictate that flag
regardless of what the others think.
I think we need to enforce majority here and not have one
single authority dictate it.
Thoughts?
+1
I can compromise one authorit
Neel Chauhan wrote:
I believe it shouldn't affect these scenarios, but have mentioned we
should look out for them.
P.S. Rendezvous point is NOT a less powerful position (at least from
an onion service server/operator point of view), unless you are using
vanguards plugin by Mike with rendguar
Neel Chauhan wrote:
Hi,
As asked in the torspec MR [1] (42) for ticket [2] (40448), I propose a
MiddleOnly dirauth flag for relays.
The proposal, #334, is attached to this email, and is titled "A dirauth
flag to mark Relays as Middle-only".
Please comment and review it.
Best,
Neel Chauha
Patrick Schleizer wrote:
> Would it be useful to run multiple Tor instances and onionbalance on the
> very same server? Or does that totally defeat the purpose of onionbalance?
>
> In my case, it's not a location hidden service. Just an alternative way
> to connect to a server which is available o
Nick Mathewson wrote:
> ```
> Filename: 320-tap-out-again.md
> Title: Removing TAP usage from v2 onion services
> Author: Nick Mathewson
> Created: 11 May 2020
> Status: Open
> ```
>
> (This proposal is part of the Walking Onions spec project. It updates
> proposal 245.)
>
> # Removing TAP from
Mirimir wrote:
> On 02/03/2020 02:17 PM, s7r wrote:
>
>
>
>> In the current form of this proposal, it looks kind of optional ("We
>> propose this optional change, to improve..."). I propose removing the
>> line which contains "this optional change&q
juanjo wrote:
> Since no one is posting it here and talking about it, I will post it.
>
> https://nvd.nist.gov/vuln/detail/CVE-2020-8516
>
> The guy:
> http://www.hackerfactor.com/blog/index.php?/archives/868-Deanonymizing-Tor-Circuits.html
>
>
> Is this real?
>
> Are we actually not verifying
Hi teor,
teor wrote:
> Hi s7r,
>
> Thanks for bringing up IPv6 address privacy extensions.
>
>> On 30 Jan 2020, at 02:19, s7r wrote:
>>
>
> I read RFCs 4941 and 3041, looked at the tor directory spec, and did some
> analysis:
> * tor clients get new relay
relay descriptor.
s7r wrote:
> Hi teor,
>
> Thanks for this epic work, some lecture for me to deeply go over this
> weekend.
>
> By briefly reviewing I've noticed something important is missing that
> should be a part of this proposal.
>
> I am not sure under
Hi teor,
Thanks for this epic work, some lecture for me to deeply go over this
weekend.
By briefly reviewing I've noticed something important is missing that
should be a part of this proposal.
I am not sure under which section it should go under. I guess `3.2.2.
Use the Advertised ORPort IPv4 an
proc...@riseup.net wrote:
> Hi I was wondering what the mathematical probability of guessing an
> onion v3 address that is kept secret.
>
> Or asked differently: what is the entropy of v3 addresses if an
> adversary decides to bruteforce the entire keyspace?
>
> I am struggling to come up with a
> Hi Tor-Dev,
>
> I'm curious what the timing is of Tor's opening of preemptive circuits.
> Specifically, consider the following attack:
>
> 1. A new stream is assigned to a clean circuit.
> 2. Because of the above, that clean circuit is now a dirty circuit.
> 3. Because of the above, the number
Roger Dingledine wrote:
> On Fri, Jun 28, 2019 at 07:53:54AM +1000, teor wrote:
>> And you're right, Tor Browser can use lots more than 8 circuits, so
>> I wouldn't worry about it.
>>
>> Do you know how much load Bitcoin places on the Tor network?
>>
>> If it's a lot, one good answer is to encourag
Hello
Florentin Rochet wrote:
> Hello,
>
>
> On 2018-03-07 14:31, Aaron Johnson wrote:
>> Hello friends,
>>
>>> 1) The cost of IPs vs. bandwidth is definitely a function of market
>>> offers. Your $500/Gbps/month seems quite expensive compared to what
>>> can be found on OVH (which is hosting a
Hi,
teor wrote:
>
> On 11 Dec 2017, at 09:25, nusenu wrote:
>
>>> And I think we should focus our efforts on expanding the pool of exits,
>>> and improving bandwidth measurement, rather than limiting operators
>>> who are helping the network. (New automatic limits will likely be seen
>>> as a r
Hello,
Fernando Fernández Mancera wrote:
[...]
> Motivation:
>
> Currently Tor users are reusing a given circuit for ten minutes (by default)
> after it's first used. This time is too long because a malicious Exit relay
> can
> trace a user's pseudonymous profile, especially if connections from
Hi George,
George Kadianakis wrote:
> Hello s7r,
>
> and thanks for helping with this and approaching it from a different
> direction.
>
> Personally, I'd be really surprised if any solution that statistically
> marks relays or paths as "suspicious" will eve
Hello Tim,
Thank you very much for the comments. Please see my inline answers as I
think I didn't explain good enough, most of the issues are not actually
a problem.
teor wrote:
>> ...
>>
>> A rendezvous relay is considered suspicious when the number of
>> successfully established circuits in the
George Kadianakis wrote:
> Hello,
>
> here is some background information and summarizing of proposal 247
> "Defending Against Guard Discovery Attacks using Vanguards" for people
> who plan to work on this in the short-term future.
>
Hello,
I have discussed in Amsterdam briefly with David about
Hi,
David Goulet wrote:
> On 30 Jan (16:16:07), George Kadianakis wrote:
>> David Goulet writes:
>>
>>> On 26 Jan (15:05:26), George Kadianakis wrote:
Hey list,
>>>
>>> Hi!
>>>
>>> First, big thanks for this write up!
>>>
with service-side prop224 implementation moving forward, we
Hello,
George Kadianakis wrote:
> grarpamp writes:
>
>> Skimming thread...
>>
>> Version or not is fine, provided if you want versions you
>> know you must store the bits somewhere, or ensure regex
>> parser rules to recognize and match an intrinsic version
>> represented by entire address forma
Hello,
David Goulet wrote:
>
>>
>> OK thanks for the useful discussion. I identified at least three feedback
>> points:
>>
>> + Screw base58 it's not gonna work. We stick to base32. Usability will
>> be "restored" with a proper name system.
>>
>> + Move version byte to the end of the address t
Hello George,
George Kadianakis wrote:
> Hello list,
>
> we've had discussions over the past years about how to encode prop224 onion
> addresses. Here is the latest thread:
> https://lists.torproject.org/pipermail/tor-dev/2016-December/011734.html
>
> Bikeshedding is over; it's time to finally
hat will
>> make the life of our users harder if we can avoid it.
>
> I believe it can be addressed by a good UI in TBB mostly to fit this client
> authorization proposal. Answers below.
>
>>
>> s7r:
>>> George Kadianakis wrote:
>>>> I ha
George Kadianakis wrote:
> Hello,
>
> I was in a train yesterday and decided to do some torspec
> housekeeping. So I updated the proposals/proposal-status.txt file which
> includes a summary of every proposal.
>
> You can find my changes here:
>
> https://gitweb.torproject.org/user/asn/torsp
Hi,
David Goulet wrote:
> On 24 Nov (11:13:06), 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" t
Hello,
George Kadianakis wrote:
> Nick Mathewson writes:
>
>> [ text/plain ]
>> Hi! I thought I'd write this up while it was fresh in my mind. It
>> could be used as an alternative method to the current proposed client
>> authentication mechanism. We could implement both, or just this, or
>>
On 11/24/2016 2:24 AM, Jesse V wrote:
> On 11/23/2016 07:04 PM, Yawning Angel wrote:
>> Our fix: "Add another command, that does essentially the same thing,
>> because people picked the wrong options, then later deal with the
>> fallout from people getting used to the temporary command, and crying
teor wrote:
> No-one is proposing we abolish ADD_ONION with v2 services straight away.
>
> What we will do is make BEST mean v3, rather than v2.
> RSA1024 will continue to mean v2, as it always has.
>
> ADD_ONION has always had an explicit BEST option, if clients don't want
> the BEST type of key
teor wrote:
>
>>
>> Very good. We can add a new torrc option for ed25519 key based
>> authentication for clients (v3) so the current
>> HiddenServiceAuthorizeClient (v2) will not break old torrc's until
>> everyone upgrades.
>>
>> However, we could just add an auth-type value after
>> HiddenServi
teor wrote:
>>>
>>> How does ADD_ONION fit in?
>>
>> It's forward compatible by design, since you have to specify a key type
>> when you handle key management, and Tor gets to do whatever it wants if
>> you ask it to generate a key with the `BEST` algorithm.
>>
>> Assuming people who use it aren't
Hello David,
David Goulet wrote:
> Hi everyone!
>
> We are soon at the stage of implementing the service part of proposal 224
> (next gen. hidden service.). Parent ticket is #20657 but I'll be discussing
> here ticket #18054.
>
> In a nutshell, we need to figure out the interface for the torrc f
teor wrote:
>
>> On 3 Nov. 2016, at 10:37, s7r wrote:
>>
>> I am very happy with the torspec patch.
>>
>> Not quoting entirely, only want to add something wrt randomizing the
>> value for fake clients based on David's and teor's comments:
>
I am very happy with the torspec patch.
Not quoting entirely, only want to add something wrt randomizing the
value for fake clients based on David's and teor's comments:
David Goulet wrote:
[SNIP]
>
> - I think "superencrypted" -> "super-encrypted" would be nicer as everything
> in the descrip
Hello George,
Inline comments:
> Hello again,
>
> I read the feedback on the thread and thought some more about this. Here
> are some thoughts based on received feedback. A torspec branch coming
> soon if people agree with my points below.
>
> I'd also like to introduce a new topic of discussio
teor wrote:
>
>> On 7 Oct 2016, at 00:22, s7r wrote:
>>
>> I don't care about location anonymity because my
>> website is clearnet public anyway and I want my website to handle many
>> Tor users, just setup a bridge Tor instance on localhost (127.0.0.1) no
Hi David,
David Goulet wrote:
>
> Personally, I would really like to be able to hide the fact that a service is
> using client authorization. Both could hide that but not that trivially.
>
> I would pick double encryption for the simple fact that I really want to us to
> expose as little as we c
Hi,
George Kadianakis wrote:
[SNIP]
>
>Some further questions here:
>
>i) Should we fake the client-auth-desc-key blob in case client
> authorization
> is not enabled? Otherwise, we leak to the HSDir whether client auth is
> enabled. The drawback here is the desc size increa
Won't comment on the entire content because I have one big comment which
refers to the entire proposal or better say the concept of the proposal.
I would reject this proposal's concept, because we have o excuse to
over-engineer and complicate things in this manner. This is just too
complicated for
Hello,
On 9/19/2016 4:14 PM, René Mayrhofer wrote:
[SNIP]
> Problem: This worked nicely with Tor 0.2.5.12-1 on Debian Jessie. We
> upgraded about two weeks ago to 0.2.8.7-1 from the Tor apt repositories
> (mostly in response to
> https://blog.torproject.org/blog/tor-0287-released-important-fixes a
On 9/13/2016 6:13 PM, Razvan Dragomirescu wrote:
> I disagree with your approach, for comparison's sake, let's say v2 is
> IPv4 and v3 is IPv6. When IPV6 was introduced, IPv4 was kept around (and
> still is to this day, although IPv6 is arguably a much better solution
> in a lot of areas). Expecti
On 9/13/2016 3:27 PM, David Goulet wrote:
[SNIP]
> Hello!
>
> So I 100% share Ivan's concerns. The Hidden Service subsytem of Tor is quite
> complex, lots of pieces need to be glued together and prop224 will add a lot
> of new code (in the 10 of thousand+).
>
> We decided a while back to have the
Hello again,
I am sorry, too tired and written something wrong:
On 6/26/2016 1:29 AM, s7r wrote:
> Very soon Tor will include an unique random value we call "Consensus
> Shared Randomness [SRVALUE]" in every consensus, you can just use that.
> This is proposal 250. This
Hello,
If you hash the consensus entirely, yes that should produce unique
hashes every time that are unpredictable until the consensus is available.
However, you cannot guarantee it will be the same value for everyone at
a given time, because consensus documents overlap and two clients/relays
mig
Razvan,
Your email is confusing. To host a Hidden Service you do not need to be
a Tor node - we call them relays in the common terminology.
So, a relay relays traffic for Tor clients. This will consume as much as
you give. You can throttle the relay bandwidth rate / burst or limit the
traffic con
Hello,
On 4/16/2016 4:11 PM, David Goulet wrote:
[snip]
>>
>>
>> A third alternative is that we can iterate through each time period:
>> Set K to the oldest expected descriptor age in hours, minus 1 hour
>> Deallocate all entries from Cache A that are older than K hours
>> Deallocate all entries
Hi,
On 3/27/2016 1:00 PM, George Kadianakis wrote:
>>[snip]
>>
>> https://lists.torproject.org/pipermail/tor-dev/2015-November/009871.html
>>
>
> Hmm, this seems like something worth considering.
>
> IIUC you are basically suggesting using a single guardlist instead of having
> two. And then al
Hello,
teor, asn, see comments inline.
On 3/24/2016 5:00 PM, Tim Wilson-Brown - teor wrote:
[snip]
>>> The number of directory guards will increase when 0.2.8-stable is
>>> released and relays and clients upgrade.
>>> In 0.2.8, relays accept tunnelled directory connections even if they
>>> do not
Hello,
I haven't measured that, but maybe this is helpful: I have measured some
time ago was the latency in a hidden service (rendezvous) circuit:
Client - guard - middle - rendezvous -- middle - middle - guard - HS
[6 hops]
I did the test by installing an OpenVPN TCP server on the hidden servi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi teor,
On 1/24/2016 6:33 AM, Tim Wilson-Brown - teor wrote:
> Please read the tor man page documentation for the option
> Tor2webRendezvousPoints. It's implemented in the function
> pick_tor2web_rendezvous_node().
>
> Under this proposal, what i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Sorry for posting 2 times, want to highlight something which doesn't
read clear.
On 1/24/2016 4:44 AM, s7r wrote:
> Consider this. We set the REND_FILTER_TOLERANCE to 4. This means
> that any relay, regardless of its middle probabili
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hello Mike,
Answers inline.
On 1/24/2016 1:56 AM, Mike Perry wrote:
>>> A) Can I deny service to a hidden service by methodically
>>> pretending to attack it from each honest relay, one at a time,
>>> causing it to become upset at each of these r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 1/24/2016 1:51 AM, Tim Wilson-Brown - teor wrote:
>
>> On 24 Jan 2016, at 09:28, s7r > <mailto:s...@sky-ip.org>> wrote:
>>
>>> * This will break some Tor2Web installations, which
>>> deliberately c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi teor,
On 1/24/2016 12:11 AM, Tim Wilson-Brown - teor wrote:
> Hi s7r,
>
> Great proposal, I really like it - I think it targets the actual
> behaviour we want to prevent in a less complex manner than the HS
> 3rd-hop alt
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 1/24/2016 12:10 AM, Roger Dingledine wrote:
>
> A few more details about "this is not always enough" would be
> helpful here. In particular, is it not always enough because
> sometimes even 3 hops is not safe enough, or not always enough
> besi
- will
do better next time.
Filename: xxx-malicious-rendezvous-point-filter.txt
Title: Filtering malicious rendezvous points at hidden service server side
Authors: s7r [ 0x837FA52C81265B11 ]
Created: 23 January 2016
Status: Draft
0. Definitions
client = an user running Tor as a client, which con
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hello,
I think the solution to change the consensus format - section 3.3 is
by far superior vs changing the ports on directory authorities or
disabling old link protocols at relays side.
Changing the consensus format is the cleanest way to do it an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hello,
I am not a big fan of prop 246. I don't have a mindblowing counter
argument that it's bad in some way, but I don't like the tradeoffs vs
benefits ratio so much. It is a small performance improvement indeed,
so clients will not cache descripto
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 1/3/2016 11:24 PM, Ryan Carboni wrote:
>
> Given the slow time it takes to roll things out, a timeline which
> begins with trusted directory keys include post-quantum crypto
> first, and which ends in enabling clients to use post-quantum
> crypt
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 11/28/2015 2:26 PM, nusenu wrote:
> The important info for me here is: How is "about to expire"
> defined? x days before expiry or
I think 24 hours before expiry.
> 80% of its lifetime is over?
No.
> Can it be configured?
No. This would not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 11/28/2015 1:48 PM, nusenu wrote:
> (thread split from [1])
>
> reproducer: mkdir tdata tor --PublishServerDescriptor 0 --orport
> 1234 --datadirectory tdata --list-fingerprint --quiet
>
> (new signing key with default expiry created)
>
> atte
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
I have actually tried this in practice to see what happens.
If you replace the ed25519 medium term singing key and certificate in
$datadirectory/keys, Tor will re-read keys from disk even if you don't
send a SIGHUP when it outputs:
[notice] It
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 11/19/2015 6:02 PM, nusenu wrote:
>
> thanks for the feedback!
>
> Are secret_onion_* files required at all when restoring a relay?
> (it doesn't look like it)
>
> If you confirm that I would simply remove them from the list and
> never copy
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 11/19/2015 3:57 PM, George Kadianakis wrote:
> s7r writes:
>
> I'm not sure exactly what you are suggesting here. That the
> participation flag should not simply be 0 or 1, and that it should
> have more purposes?
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 11/19/2015 12:19 AM, nusenu wrote:
>> background: I might want to integrate offline master key
>> functionality into ansible-relayor [1].
>
> I added (preliminary) OfflineMasterKey support to ansible-relayor
> [1] - in fact it will become the on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hello,
Saw the content of this section in master was corrected, yet the
subtitle is little confusing:
4.1.6. Including the ed25519 shared randomness key in votes [SRKEY]
- From the content of this section I understand that we are going to
include
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Oh, right - sorry, misunderstood.
In this case not using --keygen might be a workaround. I do understand
the use of --nopass, I'll include it in the ticket and maybe we can
have it along with --master-key and --out.
On 11/15/2015 5:36 PM, nusenu wr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 11/13/2015 8:51 PM, nusenu wrote:
> Hi,
>
> since tor 0.2.7.5 is apparently not very far [1] from being
> released I was wondering whether there is any documentation about
> the new offline master key functionality? (or is this undocumented
> be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
The "Enter passphrase" request when manually calling --keygen is
optional, not mandatory. If you just leave it blank and proceed it
will just create an unencrypted master identity key.
On 11/14/2015 10:18 AM, nusenu wrote:
> Hi,
>
> is there a way
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi teor,
I like RSOS more and it removes 2 hops from a circuit which is quite A
LOT. This is a significant step for operators that require latency.
RSOS combined with OnionBalance or rendezvous approval feature which
will allow scaling beyond what's
PM, George Kadianakis wrote:
> George Kadianakis writes:
>
>> s7r writes:
>>
>>> Hello,
>>>
>>>
>>>
>>> 4.1.1. Computing commitments and reveals [COMMITREVEAL] "The
>>> value REVEAL is computed as follows:
>&g
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi isis,
I am also not sure if we should have DYSTOPIC_GUARDS and UTOPIC_GUARDS
sets disjoint. It hurts the already fragile load balancing for Guards
and will cause lighter load on FascistFirewall Guards (ports 80/443).
I think usually users behind
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
asn,
Is it possible to add a field called 'NOTARY' in the COMMIT and REVEAL
values where we include the SR pubkey + certificates and everything we
need so that we can validate each COMMIT / REVEAL value and tie it to
the identity of a directory auth
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hello,
Epic work. I agree that the code enforcing commit majority was not
making a difference in the partition attack. I also agree that the
partition attack is (almost) useless, expensive and very noisy. An
attacker can get the same result if, inst
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hello Razvan,
What you try to achieve is possible. It can be done, but requires code
to be written. If you are really interested about this feature you can
either sponsor someone to write the code for it either code it yourself.
The 1024 bit RSA pr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hello,
I have an idea which I want to put into a proposal, but need a
clarification first so I won't be working on something which doesn't
make a big difference.
I am describing something like a Sybil attack where the adversary runs
relays, gets lu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hello,
I like the idea of having a secure way for the non Tor users to browse
hidden service content. Given the design presented, someone who wants
to do it will need to rely on third parties: domain name registers,
DNS providers, hosting providers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
I like this very much. See comments inline.
On 9/14/2015 2:07 AM, Mike Perry wrote:
> I spent some time trying to clean up proposal 247 based on
> everyone's comments, as well as based on my own thoughts. Please
> have a look if you commented o
a
> specific authority and a specific timestamp, without requiring the
> whole vote signature. This is required to do shared-rand-conflict
> and might be useful in any case in the future.
>
> I made a patch that implements this for prop250 at:
>
> https://gitweb.torproject.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I disagree. can you describe how exactly? What exactly can be gamed,
if we use the protection described by me? It will provide the same
security as directory authorities already have for voting about
relays. It's true that ultimately anything can be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
Sending the comments from #tor-dev here as well.
This is related to the attack where exactly half of the directory
authorities commit to some values, and the last directory authority
can send different values to both camps, and have the ultimat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
Worth mentioning, after #15745 we rotate the introduction points after
between 16384 and 32768 (random) introductions and/or a lifetime of 18
to 24 hours (random).
If we merge introduction points with HSDirs, we have no option but to
use the sa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
Thanks for the input!
On 8/20/2015 4:59 PM, l.m wrote:
>
>> "b) ..."
>
> Retrying guards is the crux of the problem. If you blindly retry
> guards, even to prevent rotation, you eventually come to a hard
> place where this will backfire badly
20/2015 3:27 PM, s7r wrote:
> Hi,
>
> On 8/20/2015 2:28 PM, George Kadianakis wrote:
>> Hello there,
>
>> recently we've been busy specifying various important
>> improvements to entry guard security. For instance see proposals
>> 250, 241 and ticket #1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
On 8/20/2015 2:28 PM, George Kadianakis wrote:
> Hello there,
>
> recently we've been busy specifying various important improvements
> to entry guard security. For instance see proposals 250, 241 and
> ticket #16861.
>
> Unfortunately, the c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
Things look good in ed25519_keygen - git-018082ef88b688e2.
I can confirm the last defect was fixed (now it saves to disk
ed25519_master_id_public_key if it only has ed25519_signing_cert -
valid and ed25519_signing_secret_key).
Log messages are
sh
descriptors, relay traffic, save the world.
On 8/7/2015 12:18 AM, s7r wrote:
>>> Thanks; this is incredibly helpful!
>
>>> I've started a branch to do a test case to demonstrate all
>>> these bugs ; it's called "ed25519_keygen" in my public
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
>> Thanks; this is incredibly helpful!
>
>> I've started a branch to do a test case to demonstrate all these
>> bugs ; it's called "ed25519_keygen" in my public repository. It
>> also adds a couple more features to '--keygen'. It does cases
>>
_cert and signing_secret_key and/or even if it
has the ed25519_master_id_secret_key unencrypted).
These commands would be useful as well: --getpubkey; --encryptkey;
- --decryptkey; --newpass; --gensignkey.
On 8/6/2015 4:14 AM, Nick Mathewson wrote:
> On Tue, Aug 4, 2015 at 8:24 PM, s7
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 8/4/2015 5:42 PM, Nick Mathewson wrote:
> Hi, s7r!
>
> This is an impressive writeup; thanks!
>
> One thing that makes it hard for me to follow this document is
> that I'm not sure which parts are describing how things
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
Tor 0.2.7.x will support Ed25519 router identities along with the
traditional 1024-bit RSA ones which will be used simultaneously for
some time, until we will completely deprecate RSA router identities.
I would like to document what Tor needs t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 7/19/2015 9:26 AM, Roger Dingledine wrote:
> On Sat, Jul 18, 2015 at 03:11:26AM +0300, s7r wrote:
>> I still see the third hop (speaking from hidden service server
>> start point) is the weak part here. An attacker can connect
ed third guards would be a reasonable solution, in my
> opinion. I would not be part of that consensus, but figuring out
> the speed and size of the adversaries we care about is
> unfortunately educated guessing at this point.
>
> Best, Aaron
>
>
>> On Jul 17, 2015, at 8:11 PM, s7r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 7/18/2015 12:49 AM, A. Johnson wrote:
>
> Not having the third guards be selected by every second guard makes
> sense when you consider that the adversary may not be able to
> compromise all relays equally. That was not a consideration I had
> in
Comments inline.
On 7/16/2015 7:26 AM, Mike Perry wrote:
> George Kadianakis:
>> Hello,
>>
>> I'm attaching a proposal draft that should help us defend against
>> guard discovery attacks.
>>
>> There are a few pieces left unfinished (see the XXXs) but I decided to
>> release early and release ofte
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
arma - isn't prop 246 already taken?
Filename: 246-hs-guard-discovery.txt
Title: Defending Against Guard Discovery Attacks using Vanguards
Author: George Kadianakis
Created: 2015-07-10
Status: Draft
On 7/13/2015 1:12 AM, Roger Dingledine wrote:
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I find it better to add a new consensus flag called 'Vanguard' which
will be assigned to relays with lower requirements than the 'Guard'
(less bandwidth, just the Stable flag). We will then select
second_guard_set and third_guard_set from relays havi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hello,
Estimations look good.
I think second_guard_set & third_guard_set should not have the same
requirements like how any Tor client chooses the guard (first hop). We
can select second guards and third guards by requiring for example
just Stable
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
An update is needed in
http:// deb.torproject.org/torproject.org obfs4proxy main
to version 0.0.5 (we currently have 0.0.4). armel and amrhf packages
for obfs4proxy would be nice too, for mobiles/tablets/raspberrys etc.
Also, why do we have
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
That would be invalid. I know there are some families which do it. You
are free to enter a nickname at MyFamily parameter in your torrc, but
it won't actually work for clients. Tor will still start on relay side
and go on with it.
It used to wo
1 - 100 of 106 matches
Mail list logo
