t somebody
could do if they could access your socksport, so long as you are using
circuit isolation properly -- and it would be great to hear some if they
do exist.
But that said, Michael, you said you *aren't* using circuit isolation
yet? For that case here's my attack: as a neighboring
Thanks so much for the thorough answer Nick. Looks like there are
several potential solutions here. Responses inline below...
On 11/09/2024 14:12, Nick Mathewson wrote:
On Wed, Sep 11, 2024 at 7:02 AM Michael Rogers wrote:
Hi Nick,
It would be useful to have a way of controlling access to
t more
difficult, and if it's going to be possible to support SOCKS credentials
in future, it might make sense to plan for it now.
I'm not asking for username/password auth to be added to this proposal,
just for the proposal to leave room for it to be added in the future.
Can you see
ard to say how often that's representative of what's happening on real
devices.
Strongly agree that it would be good to think about what Tor would look
like if built for mobile first!
Cheers,
Michael
On 13/01/2024 15:19, Holmes Wilson wrote:
Michael, what kind of reduction in batt
arm was
needed, or the controller could just assume this whenever hidden
services were published, and wake the device every fifteen minutes
without explicitly communicating with Tor about alarms.
Cheers,
Michael
___
tor-dev mailing
p the circuits alive, but avoid network-visible changes in behaviour
compared with a device that's not sleeping.
Cheers,
Michael
On 09/01/2024 17:57, Micah Elizabeth Scott wrote:
Ah. If you want to run an onion service you'll need to keep at least a
couple circuits open conti
ptors published and the consensus fresh, although
hopefully the timing requirements for those are a bit looser due to the
longer timescales involved.
Cheers,
Michael
On 08/01/2024 21:01, Micah Elizabeth Scott wrote:
A variety of timers are needed on the relay side; on the client side
though, a
give me an overview of how these local timers are handled in Arti, or
any information about what's likely to happen if the timers are
arbitrarily delayed?
Thanks,
Michael
OpenPGP_0x11044FD19FC527CC.asc
Description: OpenPGP public key
OpenPGP_signatu
so it would be
interesting to find out what's different between your scenario and ours.
When you say newly-online, do you mean that the HS has never been
published before, or that it's been published and has then spent some
time offline? Is the Tor process still running when the app is offli
Hi all,
The latest releases (0.4.7.10, 0.4.6.12 and 0.4.5.14) seem to be missing
from the changelog:
https://gitlab.torproject.org/tpo/core/tor/-/raw/main/ChangeLog
Is this file still the right place to look?
Cheers,
Michael
OpenPGP_0x11044FD19FC527CC.asc
Description: OpenPGP public key
upload the descriptor to after
restarting? In particular, are there any situations where Tor might
decide that it doesn't need to upload any copies at all after
restarting, because the previously uploaded copies are still good?
Thanks,
Michael
On 09/08/2022 14:01, David Goulet wrote:
On 2
ding bridges from sources like
Telegram bots, where the provenance isn't always clear.
However, including these signatures in a bridge URI might make the URI
quite long, which in turn might cause issues with scanning QR codes. So
there might be tradeoffs here.
Cheers,
Michael
OpenPGP
Is there any way for Tor to tell, during bootstrapping, that the system
clock appears to be far ahead of real time?
Thanks,
Michael
OpenPGP_0x11044FD19FC527CC.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
__
ugh copies were previously uploaded, and
still contain up-to-date information about introduction points etc, so
no new copies need to be uploaded?
Thanks,
Michael
OpenPGP_0x11044FD19FC527CC.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital
r some definition of broken remains
hard, but fortunately we don't need to solve that to handle the common
cases of switching between wifi and mobile data, and losing mobile
signal, which the OS can tell us about.)
My one-sided two cents. ;-)
Cheers,
Michael
__
://code.briarproject.org/briar/tor-reproducer
https://code.briarproject.org/briar/go-reproducer
https://bintray.com/briarproject/org.briarproject
Cheers,
Michael
On 13/09/2019 16:24, Santiago Torres-Arias wrote:
> On Fri, Sep 13, 2019 at 12:32:06PM +0200, Nicolas Vigier wrote:
>> On Thu, 12 Sep 2019, Hans-
on to make sure that's true?
I may have missed parts of the discussion, so apologies if this has
already been discussed and ruled out.
Cheers,
Michael
0x11044FD19FC527CC.asc
Description: application/pgp-keys
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
Argh, I'm really sorry, I thought I'd reached the end of the proposal
but my questions were addressed further down. Sorry for the noise.
Cheers,
Michael
On 05/02/2019 17:42, Michael Rogers wrote:
> I'm very happy to see this proposal! Two quick questions about relay
> se
sensus on disk would indicate that the client
had unusual exit/guard requirements at some point, however.)
Cheers,
Michael
On 05/02/2019 17:02, Nick Mathewson wrote:
> Filename: 300-walking-onions.txt
> Title: Walking Onions: Scaling and Saving Bandwidth
> Author: Nick Mathewson
> Cre
Sorry, I have one more follow-up question.
On 02/01/2019 21:00, Nick Mathewson wrote:
> On Fri, Dec 21, 2018 at 6:34 AM Michael Rogers
> wrote:
>>
>> Hi Nick,
>>
>> Is the guard connection closed when becoming dormant?
>
> No; it times out independently.
I
Hi Nick,
Thanks very much for the reply. Follow-ups inline below.
On 02/01/2019 21:00, Nick Mathewson wrote:
> On Fri, Dec 21, 2018 at 6:34 AM Michael Rogers
> wrote:
>>
>> Hi Nick,
>>
>> Is the guard connection closed when becoming dormant?
>
> No; it t
NAL DORMANT?
If Tor doesn't close client connections when becoming dormant, will it
become active again (or send an event that the controller can use to
trigger SIGNAL ACTIVE) if there's activity on an open client stream?
Cheers,
Michael
0x11044FD19FC527CC.asc
Description: application/pgp-ke
On 26/11/2018 21:46, Nick Mathewson wrote:
> On Wed, Nov 21, 2018 at 5:10 PM Michael Rogers
> wrote:
>>
>> On 20/11/2018 19:28, Nick Mathewson wrote:
>>> Hi! I don't know if this will be useful or not, but I'm wondering if
>>> you've seen this
ant mode occasionally to fetch diffs before
they expire, so we can avoid fetching a fresh consensus later.
Cheers,
Michael
0x11044FD19FC527CC.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
___
tor-dev mailin
On 07/11/2018 09:04, teor wrote:
>
>
>> On 7 Nov 2018, at 04:10, Michael Rogers wrote:
>>
>> On 06/11/2018 01:58, Roger Dingledine wrote:
>>> On Tue, Nov 06, 2018 at 11:38:33AM +1000, teor wrote:
>>>>> so if we could ask the guard for
>>&g
re interesting for the Briar case, since it
> comes way way more often than keepalives: so if you're trying for deep
> sleep but you wake up for network activity every several seconds, you'll
> probably end up sad.
Unfortunately we've disabled netflo
some of the time, for sleeping to be worthwhile. And finally,
even if all those conditions are met, we run up against the 15-minute
limit on alarms again.
None of these options are good. I'm not even sure if the first and third
are feasible. But I don't know enough about Tor or libe
ecome possible with encrypted SNI, which is now
supported by Cloudflare.
If anyone on the list knows whether/when we're likely to see a pluggable
transport based on encrypted SNI I'd love to hear about it.
Cheers,
Michael
0x11044FD19FC527CC.asc
Description: application/pgp-keys
si
On 19/10/2018 16:05, Leif Ryge wrote:
> On Wed, Oct 17, 2018 at 07:27:32PM +0100, Michael Rogers wrote:
> [...]
>> If we decided not to use the key blinding trick, and just allowed both
>> parties to know the private key, do you see any attacks?
> [...]
>
> If I&#x
On 19/10/2018 14:01, George Kadianakis wrote:
> Michael Rogers writes:
>> A given user's temporary hidden service addresses would all be related
>> to each other in the sense of being derived from the same root Ed25519
>> key pair. If I understand right, the security
On 18/10/2018 13:26, George Kadianakis wrote:
> Michael Rogers writes:
>
>> Hi George,
>>
>> On 15/10/2018 19:11, George Kadianakis wrote:
>>> Nick's trick seems like a reasonable way to avoid the issue with both
>>> parties
>>> knowing t
protocol for doing that yet). I guess
that may help to deter adversaries who don't want to reveal that they
can read and modify the channel.
Cheers,
Michael
0x11044FD19FC527CC.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
On 28/09/2018 02:40, Nick Mathewson wrote:
> On Thu, Sep 27, 2018 at 9:26 AM Michael Rogers
> wrote:
>>
>> Hi all,
>>
>> The Briar team is working on a way for users to add each other as
>> contacts by exchanging links without having to meet in person.
>&g
r confidence that they've received your
authentic link.
On the other hand, time-limited or single-use links are less likely to
become surveillance selectors in their own right, and the "key
fingerprints on business cards" pattern has never really caught on. So
there are pros and c
this question? Or is this way of using
hidden services too disgusting to even discuss? :-)
Thanks,
Michael
0x11044FD19FC527CC.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@li
On 11/07/18 14:22, George Kadianakis wrote:
> Michael Rogers writes:
>
>> On 10/07/18 19:58, George Kadianakis wrote:
>>> here is a patch with an alternative directory format for v3 client auth
>>> crypto key bookkeeping as discussed yesterday on IRC:
>>&g
;client_authorized_privkeys" if
it might contain private keys, public keys, or a mixture of the two?
Cheers,
Michael
0x11044FD19FC527CC.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing
On 05/12/17 22:18, teor wrote:
>
>> On 6 Dec 2017, at 05:12, Michael Rogers wrote:
>>
>> If the service needs to fetch a consensus and microdescs before it can
>> respond to a rendezvous cell, the delay could be far longer than the
>> difference in latency betwee
On 01/12/17 12:16, teor wrote:
>
>> On 1 Dec 2017, at 21:56, Michael Rogers wrote:
>>
>>> On 30/11/17 12:55, Nick Mathewson wrote:
>>>
>>> When a Tor instance that is running an onion service is IDLE, it
>>> does the minimum to try to rem
until we get client
> activity. Has no effect if not in sleep or idle.
>
> "WAKEUP" -- If in sleep, sleep-update, idle, idle-update, or
> shutdown:sleep state, enter the live state. Has no effect
> in any other state.
How does the co
not in the
blinded key derivation, can a service publish descriptors for multiple
protocol versions? Would there be a conflict if the HS directories store
the descriptors under the same blinded key?
Cheers,
Michael
0x9FC527CC.asc
Description: application/pgp-keys
signature.asc
Descripti
descriptor, but a v4 descriptor and a v5 descriptor
could point to the same hidden service, which would be compatible with
both descriptors?
3. The version of the *entire protocol* - meaning that a v4 address must
point to a v4 descriptor, which must point to a v4 hidden service?
Cheers,
Michael
On 02/12/16 16:56, Nick Mathewson wrote:
> On Thu, Dec 1, 2016 at 9:54 AM, Michael Rogers
> wrote:
>> Hi,
>>
>> When running hidden services on Android I've found it's necessary to
>> hold a wake lock to keep the CPU awake. Otherwise Tor's
>> se
y sane?
Another possibility would be to look into how Libevent's timers work.
Perhaps we can ensure that the timers wake the CPU on Android, so
second_elapsed_callback() and any other timer-based functions get called
without keeping the CPU permanently awake?
Thanks,
Michael
0x9FC527CC.asc
Likewise DANGEROUS_PORT leaks information about
ports, HS_DESC about HS descriptor lookups.
I'm not sure if covert channels between two VMs (e.g. for exfiltration)
are part of your threat model, but events would be a rich source of
those too.
Cheers,
Michael
0x9FC527CC.asc
Description:
erial shouldn't be included in the salt?
Again, probably just a failure on my part to understand the context, but
I thought I should ask just in case.
Cheers,
Michael
0x9FC527CC.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
erved over plain HTTP, and apply the
same trusted certificate rules to the connection that supplies the
header as the connection that supplies the policy (sites that want
pinning can use HSTS to upgrade HTTP to HTTPS before serving the pin header)
Cheers,
Michael
d the client are both running on mobile
devices, the relative skew can be twice as much.
Cheers,
Michael
0x9FC527CC.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
to
filters would be applied to the underlying list, resulting in more
candidates without repeating any sampling.
Cheers,
Michael
0x9FC527CC.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
___
tor-dev
"It might not have been me,
anyone could be an exit node".
Cheers,
Michael
On 25/02/16 22:06, blacklight . wrote:
> About the issue of exit nodes needing to know to which bridge they need
> to connect to, could we not make a system that similair to hidden
> services, so that the
relay failures and internet connection
failures. On Android the OS broadcasts connectivity events that could be
used to reset the retry counter via the control port, but I don't know
about other platforms.
Cheers,
Michael
0x9FC527CC.asc
Description: application/pgp-keys
signature
On 13/01/16 16:04, Nathan Freitas wrote:
> On Tue, Jan 12, 2016, at 11:52 AM, Michael Rogers wrote:
>> On 12/01/16 16:16, Nathan Freitas wrote:
>>> The broader idea is to determine which Tor torrc settings are relevant
>>> to the mobile environment, and that coul
mobile data,
feel free to backport it to Orbot. Likewise for the plugin as a whole,
if it would be a suitable basis for LibOrbot. We've benefitted a lot
from your work and I'd love to send some contributions back upstream!
Cheers,
Michael
0x9FC527CC.asc
Description: application/pgp-keys
ences.
When the failed dirauths come back online they should accept the
consensus that was generated in their absence. So in the following
round, all dirauths will vote for an SRV based on the one that was
agreed while the failed dirauths were offline.
Cheers,
Michael
> I wonder what's
RV they
know about, right? It doesn't have to be yesterday's SRV - if the last
fresh SRV was produced a week ago, they keep hashing based on that
(which is not ideal of course). As above, using the consensus seems like
a good idea because it allows the network to converge on the same v
ratio exceeds the limit and the relay stops padding, will the
client know that the circuit's no longer protected? Perhaps the safe
thing would be to kill the circuit?
Cheers,
Michael
0x9FC527CC.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP dig
tordev...@safe-mail.net wrote:
> > > I'm not talking about those providers hosting exit nodes. I'm
> > > talking about general web sites and resources hosted by them and
> > > the traffic that goes there.
> >
> > I'm confused. You're worried about people hosting clearnet websites
> > with cloud hos
tordev...@safe-mail.net wrote:
> > I don't think banning GCE, AWS and MS Azure is an efficient method
> > to significantly increase the cost of attacks because it is trivial
> > for an attacker to quickly spin up "a large number of disposable
> > machines" at other ISPs as well.
>
> It has other b
Mansour Moufid wrote:
> Michael McConville wrote:
> > free() is specified to be NULL-safe, and I don't know of any
> > implementations that violate this.
>
> I think those NULL checks are meant to avoid double-free bugs. If you
> assign NULL to a pointer after you f
free() is specified to be NULL-safe, and I don't know of any
implementations that violate this. Tor's *_free() functions conform,
although relaycache_free() prints a warning (which I remove in the below
diff).
I checked every *_free() function for NULL-safety before removing
conditions for it. Thi
rd by repeatedly breaking the circuit until it was rebuilt
through the corrupt middle node. Would it make sense to use vanguards
here, as well as on rendezvous circuits?
Cheers,
Michael
0x9FC527CC.asc
Description: application/pgp-keys
signature.asc
Descripti
ensive.
A quick thought: to select IPs by bandwidth weight, divide each IP into
one or more slices depending on its bandwidth, then select slices
instead of selecting IPs directly.
Cheers,
Michael
0x9FC527CC.asc
Description: application/pgp-keys
signature.asc
Description: O
consensus the client is using, the
service may not have a copy of that consensus (and may not ever have had
one).
Cheers,
Michael
0x9FC527CC.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
___
tor-dev mailin
) similarly to how 224 selects HSDirs.
One small problem with this suggestion (hopefully fixable) is that
there's no single "current consensus" that the client and IP are
guaranteed to share:
https://lists.torproject.org/pipermail/tor-dev/2014-September/007571.html
Cheers,
Michael
f music,
one for unanonymised traffic and the other for the same traffic passed
through Tor? Then we'd know what privacy sounds like. :-)
Cheers,
Michael
0x9FC527CC.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
__
ing the Tor source code and not sure how to best
>> fix them.
>
> Thanks for bringing this up. I know Michael from Briar has definitely
> focused on solving this at some point, and Yaron from the Thali Project
> (who build this library:
> https://github.com/thaliproject/Tor_Onion_
alicious middle node, the adversary would learn the
identity of the HS's guard.
I don't know whether that's a serious enough threat to outweigh the
benefits of this idea, but I thought it should be mentioned.
Cheers,
Michael
signature.asc
Description: OpenPGP digital signature
_
USENIX Security.
>
> [1] http://en.wikipedia.org/wiki/Rabbit
That's a plaintext rabbit - surely you meant [2]?
Cheers,
Michael
[2] https://en.wikipedia.org/wiki/File:Hare_Tonic.jpg
signature.asc
Description: OpenPGP digital signature
___
to
test our download logic, it would be helpful to have a way
> to drop items from our caches.
This too. (I have a patch for purging entries from the HS descriptor
cache that I'll bring to the patch workshop one of these weeks...)
Cheers,
Michael
signature.asc
Descri
gh information to manage their own
risks. Is that true of all users? If not, perhaps the only responsible
course of action is to disable risky features by default and give any
users who want to manage their own risks enough information to decide
whether to overrid
process running
> just to keep the HS alive.
Dormant processes are essentially free, so does this matter?
Cheers,
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAEBCAAGBQJU4kaeAAoJEBEET9GfxSfMP/oH/Aoel3gyOAtn5NrgKh6WRcFf
5TwPOElP/vL+XI5XrPRYJYczilQ2st/ZLu6nu
ve padding, if a relay detects a gap in the incoming traffic
along a circuit, it doesn't try to assign blame for the existence of
the gap - it just fills it. Likewise for the single-hop padding scheme
I suggested: each relay is responsible for normalising its out
he
client and the hidden service are cooperating - for example, a Pond
client and server that want unlinkability rather than mutual anonymity.
For that use case we may be able to find a relatively simple,
low-overhead solution that doesn't depend on datagram transports, new
flow control algo
ics:
http://pdos.csail.mit.edu/tarzan/docs/tarzan-ccs02.pdf
http://pdos.csail.mit.edu/tarzan/docs/tarzan-thesis.pdf
George Danezis looked at the anonymity properties of paths chosen from
a restricted graph rather than a complete graph (this was in the
context of mix networks, but the findings may also be
saying that wheat can only be sent over links that have been
chosen to carry chaff?
Cheers,
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAEBCAAGBQJUquNZAAoJEBEET9GfxSfMO3MIAIVQ0nlcHjNjudOKMGpG6pyI
wDcq9GfFIp1h9WDYh0c+d398XEfAp+TlDAKNsGK3d7tFQHyM5JgtbaK/FGzXxcSj
hBeynFQ
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Resurrecting a thread from last year...
On 11/12/14 16:05, grarpamp wrote:
> On Thu, Dec 11, 2014 at 8:26 AM, Michael Rogers
> wrote:
>> * Which links should carry chaff?
>
> First you need it to cover the communicating end
/psiphon/ploggy/TorWrapper.java
https://github.com/thaliproject/Tor_Onion_Proxy_Library
All of the above are based on Orbot by the Guardian Project:
https://gitweb.torproject.org/orbot.git
Cheers,
Michael
On 15/12/14 15:51, Hollow Quincy wrote:
> Hi all,
>
> I would like to write a C# applic
u.edu/cs6461/www/Reading/08/Wang-ccs08.pdf
https://www.cosic.esat.kuleuven.be/publications/article-1230.pdf
Cheers,
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAEBCAAGBQJUiZt+AAoJEBEET9GfxSfMYsQH/iMCSvmQYxjGFZC5lzvpT06Z
Ggjk+mflVkEDCKPt8e8ucQ7dp1URi9BS0wgxv
the
exponential, we also have to consider the pause time at each hop while
building circuits and the 'hangover time' at each hop while tearing
them down. But I think we can mine the mix literature for some ideas
to apply - and probably some attacks against this first attempt at a
design as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 29/11/14 00:35, Yawning Angel wrote:
> On Fri, 28 Nov 2014 17:57:26 +0000 Michael Rogers
> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>
>> On 28/11/14 15:50, Yawning Angel wrote:
>>> A one
doesn't derive the authentication key from the
nonce) you can include the nonce in the AAD, so it's explicitly
authenticated. With crypto_secretbox it seems like the nonce is
implicitly authenticated, but I just wanted to be sure.
Cheers,
Michael
-BEGIN PGP SIGNATUR
Interesting, thanks. Would SHA-256 be too slow for obfuscation? It
just seems like a lot of dependencies for a simple protocol.
For what it's worth, we're using the two-box approach for the next
version of the Briar transport protocol. I'm concerned about the
possibility of an attack co
esigned to ensure this.
Any particular reason for using two different MACs (HMAC-SHA256-128
for the handshake, Poly1305 for the frames) and two different hashes
(SHA-256 for the handshake, SipHash-2-4 for obfuscation)?
Cheers,
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12
gt; starting points. I would love to participate, and encourage
> everyone to start in this direction (in your copious free time ;).
This issue has just come up on the guardian-dev list, so we're moving
the conversation over here. Context quoted below.
On Thu, Nov 20, 2014, at 09:46 AM, Michae
the auth
cookies itself and supply the relevant cookie when making a SOCKS
connection. The SOCKS password field seems like a natural fit, but I
think perhaps Tor's already using the username and password for some
other purpose?
Cheers,
Michael
-BEGIN PGP SIGNATURE
is never guaranteed to happen, because each client may skip
a consensus each time it downloads a fresh one. That would need to be
addressed before implementing the 5-hop proposal.
https://lists.torproject.org/pipermail/tor-dev/2014-September/007571.html
Cheers,
Michael
-BEGIN PGP SIGNATURE
projects/tor/ticket/3521
Thanks! The patch only supports purging a single descriptor at
present, but it would be easy enough to make the hostname optional and
purge all descriptors if it's absent.
Cheers,
Michael
-BEGIN PGP SIGNAT
to make the retention
time of the HS descriptor cache configurable. Then clients connecting
to mobile hidden services could set a shorter retention time than the
default. But that would affect all hidden services used by the client.
What I'm trying to achieve
oject's repo, which is ahead of the upstream
repo (n8fr8 needs commit privileges for upstream, I think).
https://github.com/guardianproject/jtorctl
I've only done small-scale testing of these patches so far. If they
seems like they might be useful I'll create a trac ticket to mer
interval between the time 3/4 into the first interval after the
consensus is no longer fresh, and the time one consensus interval
after that, there would be no gap or overlap between replacement
intervals.
This wouldn't affect the third observation, however - there would
still be no guarantee of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 13/09/14 15:34, George Kadianakis wrote:
> Michael Rogers writes:
>> Hi George,
>>
>> Could you explain what it means to say that HS traffic isn't
>> counted in the load balancing equations? Why is that so,
isn't counted
in the load balancing equations? Why is that so, and can it be changed
if that would allow a more secure HS design?
Cheers,
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAEBCAAGBQJUFEODAAoJEBEET9GfxSfMkicH/RJFaXcI2fmgq9Qm9xV5C3H
list here:
https://fulpool.org/cgi-bin/mailman/listinfo/hidden-services
Cheers,
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAEBCAAGBQJTy9lOAAoJEBEET9GfxSfMZMIH/jHmO6/RlLUDSaEcxtgSsO1W
rlxW9oPCmwoFg258+1FRAVmfpqmUxmr0RTMiG4yb2Go23mM7HmnNVJ
ormance (judging that
the newer boxes run a dual core ARM Cortex A7 1GHz and 1 Go RAM.
Don't know about networking, as these boards integrate Allwinner
A2 SoCs.
A third (and most powerful of all) option would be to port to the
Intel Galileo. That would be cheapest as well as exposing a IA32
i
for writing
> controllers here: https://stem.torproject.org/
A related question: is it possible to build introduction/rendezvous
circuits via the controller protocol?
Cheers,
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
i
a difference in this regards?
Sorry for so many questions, I'm not in the 'difficult' category
so have no idea.
>In the meanwhile we'll keep considering HTTPS links only.
>
Good choice, I hope you get the answer you're looking for.
Cheers,
Michael
smime.p7s
Desc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 29/05/14 19:36, Nick Mathewson wrote:
>> So what's the effect of REND_HID_SERV_DIR_REQUERY_PERIOD?
>
>
> Hello, Michael!
>
> This looks like a possible bug to me. Could you open a ticket at
> trac.torproject.
ories have been tried for
the descriptor, allowing the same directories to be tried again before
REND_HID_SERV_DIR_REQUERY_PERIOD elapses.
So what's the effect of REND_HID_SERV_DIR_REQUERY_PERIOD?
Thanks for any guidance,
Michael
-BEGIN PGP SIGNATURE-
Ver
fixed-length frames, or using the decrypted length
field before checking whether it's been tampered with.
Cheers,
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAEBCAAGBQJTf2xRAAoJEBEET9GfxSfMdPIH/0YQ+9d0HBl2Nj4imSKwe6tz
6OWKqgL5Vqd/Qvq7/vSwtHVY+yY/+C1dmHGLFAO+6W
ould be necessary to test on the actual OS as long as the feature
>can be exercised on the test rig. If the feature is not covered by
>a test case it wouldn't help to run it on the actual OS.
>
I don't know of a test rig that middle clicks, but I'm kind of new
here. So you don&
1 - 100 of 118 matches
Mail list logo
