[tor-talk] torproject forum hosted by 3rd party, not least of problems

[grarpamp]

On 1/13/22, nusenu  wrote:
> Since tor-talk is apparently going to be closed down soon [1],
> here are a few suggestions:
>
> [1] https://gitlab.torproject.org/tpo/community/support/-/issues/40057
>
> let us know whether/when you will be closing tor-relays as well

https://lists.torproject.org/pipermail/tor-talk/2021-October/045779.html
"
I was surprised to learn that the forum is _not_ self-hosted on
torproject infrastructure.
It is hosted by "Civilized Discourse Construction Kit, Inc." the
company behind discourse.org.
That means the torproject does not have full control over the
infrastructure and its security and logging practices.
The forum privacy policy mentions that IPs get logged and stored over
an extensive amount of time
https://forum.torproject.net/privacy
As Jérôme pointed out [5] the forum is also subject to discourse's
privacy policy
"

Lol. Not to mention that hosted and "web" based means that
users can, unlike distributed standalone email, now be more
central exploited on attack surface from server side in browser/JS/etc
by rogue, bought, mole'd staff, corp changeup, court order, etc
at these companies.

And who cares what the channel is when every single Tor Project
communication channel has been intentionally "bricked up"
and 100% fully and completely censored for *years* by the
Tor Project Inc to avoid embarassement, avoid being called out,
preserve their personal cashflows, keep users from learning all
of tor's weaknesses and then forking or developing better, more
variety, and or more resistant anon overlay projects etc. After all,
Tor's monetary captured people rake in multiple millions of dollars
every year, including by problematic fundraising nft drops,
off a conveniently Govt funded design that's well over 20+ years old,
that even the NSA was quoted well over 10+ years ago saying that
the NSA could exploit tor. NSA GCHQ FVEY and myriad private
and GovCorp adversaries have all since then advanced their attacks
and technology light years ahead of tor's baked design. While Tor
adds irrelavant non-design trappings and periphery and social-activism,
decides to cancel users free concious choice to use
v2 Onioncat IPv6+UDP transport for whatever they want and
terminates that entire good class of usage, innovation, and app
development within onionland, censors user and operator knowledge
of same, ejects people who like code but refuse to apologize
for Tor or/play its socio-politic, game, monoculture, and more,
Tor's Government funded social marketing engine also consumes
and starves out a lot of funding from and steers messaging in
a space that needs a distributed nature in all things.

If the world knew how the Tor Project Incorporated has become
total hypocrites of the Freedom of Speech they claim to support,
Tor Project would be defunded, users would leave in disgust,
and the crypto overlay network space would flourish anew
generation again.

The fact of Tor Project's secret censorship agenda alone is enough.

Add in refusing to routinely acknowledge and publicly disclose for
users in exceedingly prominent places that Traffic Analysis and Sybil
are in operation, actually removing warnings from their website,
pasting over them with safe sounding phrases, putting users at
risk that way, among many other problems... makes things
even more serious.

https://www.hackerfactor.com/blog/index.php?/categories/19-Tor
"
Today, the Tor Project seems to be more focused on fund raising
than actual privacy, anonymity, or anti-censorship.
"

"Tor Stinks  -- NSA"
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Jitsi Meet over Tor

[grarpamp]

> Yes, VoIP via UDP works very well through Tor with OnionCat. However,
> both endpoints must be running Tor and OnionCat. Basically, all devices
> running Tor and OnionCat have IPv6 addresses in the same /48 subnet. So
> any such device can connect with any other.
> But _not_ with any other IPv6 (or IPv4) address.

It's entirely possible to have some comms peers on clearnet
in same chatscreen panel mashup at the same time with peers
on onioncat/48, i2p.etc. It all depends on the routing horizons,
and or hub selections, users setup and maintain in such conferences.

> Yes, you can route VPNs through Tor. However, I don't recommend doing
> that except in Whonix.

Whonix is quite reasonable interesting isolation idea over Tails.
Be sure to evaluate the two in own usage models.

> You could use a commercial VPN service, or run your own VPN server in a
> VPS. But either way, you'd need to do everything ~anonymously through
> Tor. Or in other words, your anonymity using the VPN via Tor will be
> limited by how anonymously you paid for the VPN service or VPS. So that
> means well-mixed Bitcoin, or better perhaps Monero.

Imagine an overlay network that offered VPN termination
services to clearnet from the overlay... even cryptocurrency
supported ones, such as cryptocurrency data storage networks
do today... the models exist, explore them.

Note also, Zcash style zero-knowledge is still quite equally
valid to this day, among other competing privacy crypto models
such as Monero. Explore the entirety of onchain privacy,
it is evolving nicely, early days.

> All things considered, it'd be simpler, and arguably more anonymous, if
> you can force Jitsi to use TCP via plain Tor.

Not against State Associated Agents, such as say LE conjoined with
Top Secret entities Parallel Constructing, or other generic Sybil trolls,
perhaps, as in the subject Snowden and other slides and public docs,
this hardly in fact true, tor being no exception, witness myriad published
tor network exploits, same as any other current overlay network.
Against random wannabe's, such as say an employer, or some
website, sure, reasonably well. Those two, and others, are still a
good thing, accomplished by any fairly rudimentary overlay measures.
That covers many users, but not all those rightfully, justly,
and naturally, freedom and privacy oriented.

Also, Tor Project Inc snowflakes are censoring this post by
forcing it to go to mandatory "moderation" first, while others are
free to post entirely unmoderated, including, shamefully, said self
appointed TPIs. Think of the ramifications before you accept
such censorship regimes in your life.

Move to distributed messaging, social, and multimedia to ensure
your freedom of speech and consumption against such censors
like TPO, Youtube, Reddit, Facebook, Instagram, etc... ASAP!
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Jitsi Meet over Tor

[grarpamp]

Voice and video conferencing apps can and do
work over I2P, Tor, Phantom, etc.
Use the lowest quality, bandwidth, window size,
frame rate, etc settings possible.

UDP and IPv6 can and do work over all three of the above networks.
With .onion (.i2p) use OnionCat (GarliCat) to enable UDP and IPv6.
Search this list for all the cool things you can do with OnionCat.
Get it here...

https://www.onioncat.org/
https://github.com/rahra/onioncat

Tor exits still don't offer any IP VPN termination services
to tor circuits. So for UDP over tor exit, use your own or
a third party VPN, shell, proxychain etc that offers UDP.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] Onion PPE

[grarpamp]

https://i.imgur.com/WGothto.jpg
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Revisiting youtube blocking TBB, virtually all 1st attempts to load YT

[grarpamp]

https://trac.torproject.org/projects/tor/ticket/6256
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] How secure is a hidden service?

[grarpamp]

On 2/20/20, Robin Lee  wrote:
> I'm wondering how hidden a hidden service actually is?
> ...
> Is it just a function of time and amount of traffic, i.e. the longer
> you are online and the more traffic you generate, the more probable it
> is to discover the true ip-address?

Time and traffic are elements of some known research exploits.

One form of general answer might also be...

Given the number of proven research exploits against such
services in the public literature, and the presumed attention
to high security that at least some of the fallen services
must have given, it's probably worth assuming that...

- Public research exploits are being used in the wild.
- Private research exploits do exist and are being used in the wild.
- Adversaries using such public exploits, and most assuredly
such private ones, are unwilling to let those respective facts
of advantage become known, particularly when parallel construction
and various [il]legal processes around the world effectively allow
those trump cards to remain secret, thus not triggering defensive
moves and arms races to their disadvantage.

This isn't specific to tor, it's the nature of the entire netsec game,
the history of such games showing that many such preposterous
ideas not always as far fetched as their prior critiques presumed.

While searching the web for the exploit papers is easy, the
difficulty comes in showing the actual usage of any exploit.

There's probably a wide range of honorary awards and nice paychecks
available to whoever breaks any big news or research regarding the topic.
And certainly many thanks from rights workers, journalists, etc
whose very lives and work depend on it.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] Mix, stream, VPN, traffic analysis, overlays, bandwidth buys (re: relay weighting)

[grarpamp]

On 2/17/20, Mirimir  wrote:
> On 02/17/2020 05:16 AM, Roger Dingledine wrote:
>> But I'll turn it around, and point out that many systems (e.g. most VPNs)
>> are centralized, that is, the number is 100 percent.
>
> Yes, a VPN service is for sure 100% centralized, regarding ownership and
> management. And more generally, VPN services generally are probably
> about as centralized at the AS level as Tor is, for basically the same
> reasons. For some VPN services, I've found that most servers are
> actually located in a few cities (Nuland, Los Angeles, Prague and
> Vancouver) 
>
>> (You might turn it back around and say that VPNs are companies and you
>> have an agreement with them so nothing will go wrong. That's a good
>> point too, though that trust should only go so far. It's not clear to
>> me which one is the shakier argument. :)

A good contract against logging, retaining, sharing,
that is actually upheld, can be quite valuable.
The problem comes in verifying the implementation
of those statements, and in divining when any upholding
will be thrown out the window for higher priorities.

> Well, that's too iffy for me. Which is why I use nested VPN chains. It's
> a crude parody of Tor, for sure. But I can do 6-7 hops with decent
> latency and throughput, using a different VPN service for each hop. Paid
> with multiply mixed Bitcoin, and using dynamically changing paths.

VPN chains provide the same fundamental as tor does...
circuit based, tunneled, client-to-exit crypto.
In fact, people were chaining things around the net well
before both tor and rise of vpn services. Tor just made it
easy by wrapping a management engine over a bunch of
nodes. With enhancements coming from also being the
node software itself.

https://www.vpngate.net/
VPNgate makes things easy too. With a new influx of help
from various communities, vpngate could be greatly expanded...
dynamic tunnel pathing, more nodes, even hosted along with
tor, i2p, etc, paid with crypto. Added bonus of UDP and binding
inbound, providing termination from other networks.
Things begin to get interesting at that point as another choice
that has fairly well known properties.
Like tor, surely not a next generation design, but an alternative.

> And then there's
> https://www.orchid.com/
> which is a real thing.
> Although, sadly enough, for now limited to Android and iOS.

It's opensource, so it can get to native Linux and BSD before long.
Might even be able to run it in droid emulator and push traffic through
it that way.

There's a lot of crazy things coming from blockchain land :)

>> It's times like this where I wish the world knew how to do mixing with
>> streams. That is, there is a whole field out there on how to build
>> stronger anonymity designs, based on mix-nets, but nobody knows how to
>> do that safely when users generate flows of messages rather than just
>> a single message.

Can you or anyone link to papers that make a general proof of that?

ie: Not to papers that merely present weaknesses in some specific
proposed approach to date, but to something that proves "doing that"
is not possible. Proof of negative can steer work in other areas.


Safely... against traffic analysis bugaboo.
Stream... generally, not a single packet, but two or more generated
under and belonging to some user app context in a line.

While likely not impossible to carve up a transfer,
spray it across some magic random routing cloud,
and reassemble it on the other side in as near as real time as
some torrent sequence reassembly buffer mechanism will allow...
definitely not going to be happily "stream" it like YouTube
unless cloud has zero packet loss, which it won't,
leading to segment re-quest or falls back to store-forward.

Whether "stream" or "message" or otherwise, a mix still
needs to generate fill so that *PA's cannot simply match
up two endpoint usage patterns.

Given a fill that can defeat that, then ride such happy
stream circuits on top within and part of it as needed
up to your bandwidth commitment.


> What about Garlic routing? I know that I2P doesn't yet implement actual
> content mixing. But I've seen the claim that using unidirectional
> connections should allow that. Maybe the key point is that they've been
> saying that for years. Or maybe it's just that they're a small team.



>> Making sure that people
>> who want to contribute a lot of bandwidth can actually do it is really
>> important.

What percent of relays, relative to both node and operator counts,
pay by the Byte actually transferred, vs for an unmetered bitrate contract?

Same question for end user client non-relay nodes?

Answers even potentially gathered from among all the overlay networks.
Any actual studies there?




"
declare that no relay family should get more than 10% of the total
consensus weight for any relay role (guard, exit, etc). By adopting a
policy like that, we could accidentally *increase* the total weight that

Re: [tor-talk] [tor-relays] Would you place your secrets or in worst case make your life

[grarpamp]

>> On 13 Feb 2020, at 22:05, zwiebeln  wrote:
>> Would you place your secrets or in worst case make your life
>> depended on a network that is 21 percent controlled by a single person
>> that you don't know?
>>
>> https://nusenu.github.io/OrNetStats/allexitfamilies
>>
>> I think we should start an open debate on that fact, best ending up with
>> giving some recommendations. I am sure that question is relevant to
>> torproject.org as well.

Given an overlay network offering certain degrees of
say security / bandwidth / latency can be comparatively
inverse degree to clearnet...

> "Let's encourage people to run more relays."

Depending what is sought, that can be of limited help. See
traffic analysis of gravity wells, the voids and densities between.
Nor are people validating "people", so Sybil abounds.

> Or ask for help improving your consensus weight?

Manual central / "decentral" manipulation, over unknowns,
by unknowns, can be of of limited trust... compare to
distributed random chance.

> It's also important to keep network risks in perspective:
> * 99% of relays run Linux, and a significant number of those are Debian
>   https://metrics.torproject.org/platforms.html

If an overlay wants to steer diversity there, its community
should be working ports to other non-Linux OS kernels,
and informing selection for that via notes in highly user
visible places about it.

There was a BSD group that grew and reported success
some years ago. It is a great platform that could easily
be ramped up.

> * there is 1 bridge authority (100%), 6 bandwidth authorities (17%),
>   and 9 directory authorities (11%)

Users don't see them, so they have no oppurtunity to consider
trust them over say distributed design that transforms
most central management into selectable subscriptions model
users can choose from and contribute to. A lot of potential
models there aren't really explored by projects due to central
being default think, easier, cheaper, faster, and distributed
often being roughly equivalent in similar areas.

>   * the consensus algorithm tries to limit the risks of one directory
> authority influencing large parts of the tor network, and manual
> bridge distribution limits the impact of the bridge authority

> * the largest ASes have:

Physical control of machines and traffic data.
Overlay communities must effort to shop for hosts if they want
to diversify that, and run nodes at home where comfortable.

And beware of Tier-1 default path rollup. Interesting approach
would be overlays deploying peering path aware modular router
into nodes, integration of radio and physical mesh networks, etc.

Global telecoms are not your friends. At least not hardly until
they start encrypting their links, publicly fighting "requests"
and lobbying vocally for you.

Better off to start building physical p2p networks around them.
Same idea as cryptocurrency.

>   https://metrics.torproject.org/

Yes things like this are not only handy and interesting
good work and research areas, but offer food for thought
to the entire network overlay space as it pursues whatever
current work and future designs may come.
Hopefully all projects in the space can contribute their own
research and find and take each others into consideration
where useful.

> There are all kinds of risks that happen when a large part of the
> network has a similar setup:

...

> I'll also ask our new Network Health team to consider the risk of
> large operators and large ASes.

Not a new problem, been analysed by the space since years.

> But ultimately, if we doubled tor's exit bandwidth, this issue would
> go away. That's the best solution to this problem.

Not necessarily. OP generally alluded to selection gravity wells
and the way that relates to trust, adversary, analysis aspects.
More nodes of particular bandwidth could flatten distribution
and performance, while affecting network analysis properties
in some not so good ways.
Simply adding more bandwidth and or relays under the
current design and operation will not much change those
elements and interactions.
Weighting for "busy nodes good" also a bit of assumptive
dance bet around *PA traffic analysis and Sybil problems.
It's fine to chase diminishing returns there if desired.

Yet also perhaps time for at least a good portion of the researchers
and projects in overlay space to form and renew efforts around both
dormant old and novel new work towards attacking those
two problems directly in new design and operation models.



[Moving to tor-talk as not strictly relay topic]
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] How to build circuits manually to request a different Tor exit IP address?

[grarpamp]

Try reading through the control spec for mapaddress here...

https://gitweb.torproject.org/torspec.git/tree/

Can also search for cached descriptors or consensus
in that whole doc set, and in the torproject site and
lists for exitlist, tordnsel, relay fingerprints, etc.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] Tor Speculated Broken by FBI Etc - Freedom Hosting, MITTechReview

[grarpamp]

https://www.technologyreview.com/s/615163/a-dark-web-tycoon-pleads-guilty-but-how-was-he-caught
https://twitter.com/techreview/status/1226212530856611840
https://www.courtlistener.com/recap/gov.uscourts.mdd.451238/gov.uscourts.mdd.451238.57.0.pdf
https://www.courtlistener.com/recap/gov.uscourts.mdd.247657/gov.uscourts.mdd.247657.13.1.pdf
https://arstechnica.com/tech-policy/2017/03/doj-drops-case-against-child-porn-suspect-rather-than-disclose-fbi-hack/
http://darknetq7skv7hgo.onion/

Given the variety of known weaknesses, exploits, categories
of papers, and increasing research efforts against tor and
overlay networks in general, and the large number of these
"mystery gaps" type of articles (some court cases leaving hardly
any other conclusion with fishy case secrecy, dismissals, etc)...
the area of speculative brokeness and parallel construction
seems to deserve serious investigative fact finding project of
global case collation, interview, analysis to better characterize.


Feb 8, 2020
A dark web tycoon pleads guilty. But how was he caught?
The FBI found Eric Marques by breaking the famed anonymity service
Tor, and officials won’t reveal if a vulnerability was used. That has
activists and lawyers concerned.

When the enterprising cybercriminal Eric Eoin Marques pleaded guilty
in an American court this week, it was meant to bring closure to a
seven-year-long international legal struggle centered on his dark web
empire.

In the end, it did anything but.

Marques faces up to 30 years in jail for running Freedom Hosting,
which temporarily existed beyond reach of the law and ended up being
used to host drug markets, money-laundering operations, hacking
groups, and millions of images of child abuse. But there is still one
question that police have yet to answer: How exactly were they able to
catch him? Investigators were somehow able to break the layers of
anonymity that Marques had constructed, leading them to locate a
crucial server in France. This discovery eventually led them to
Marques himself, who was arrested in Ireland in 2013.

Marques was the first in a line of famous cybercriminals to be caught
despite believing that using the privacy-shielding anonymity network
Tor would make them safe behind their keyboards. The case demonstrates
that government agencies can trace suspects through networks that were
designed to be impenetrable.

Marques has blamed the American NSA’s world-class hackers, but the FBI
has also been building up its efforts since 2002. And, some observers
say, they often withhold key details of their investigations from
defendants and judges alike—secrecy that could have wide-ranging
cybersecurity implications across the internet.

“The overarching question is when are criminal defendants entitled to
information about how law enforcement located them?” asks Mark Rumold,
a staff attorney at the Electronic Frontier Foundation, an
organization that promotes online civil liberties. “It does a
disservice to our criminal justice system when the government hides
techniques of investigation from public and criminal defendants.
Oftentimes the reason they do this kind of obscuring is because the
technique they use is questionable legally or might raise questions in
the public’s mind about why they were doing it. While it’s common for
them to do this, I don’t think it benefits anyone.”

Freedom Hosting was an anonymous and illicit cloud computing company
running what some estimated to be up to half of all dark web sites in
2013. The operation existed entirely on the anonymity network Tor and
was used for a wide range of illegal activity, including the hacking
and fraud forum HackBB and money-laundering operations including the
Onion Bank. It also maintained servers for the legal email service Tor
Mail and the singularly strange encyclopedia Hidden Wiki.

But it was the hosting of sites used for photos and videos of child
exploitation that attracted the most hostile government attention.
When Marques was arrested in 2013, the FBI called him the “largest
facilitator” of such images “on the planet.”

Early on August 2 or 3, 2013, some of the users noticed “unknown
Javascript” hidden in websites running on Freedom Hosting. Hours
later, as panicked chatter about the new code began to spread, the
sites all went down simultaneously. The code had attacked a Firefox
vulnerability that could target and unmask Tor users—even those using
it for legal purposes such as visiting Tor Mail—if they failed to
update their software fast enough.

While in control of Freedom Hosting, the agency then used malware that
probably touched thousands of computers. The ACLU criticized the FBI
for indiscriminately using the code like a “grenade.”

The FBI had found a way to break Tor’s anonymity protections, but the
technical details of how it happened remain a mystery.

“Perhaps the greatest overarching question related to the
investigation of this case is how the government was able to pierce
Tor’s veil of anonymity and 

Re: [tor-talk] How to build circuits manually to request a different Tor exit IP address?

[grarpamp]

Just grab all the exit fingerprints from consensus and
MAPADDRESS them via controller however and whenever you want.
There were some exitlist parsers you can search for to do that,
or deal with bigger frameworks like stem.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] A security concern about Tor.

[grarpamp]

On 12/16/19, Jason Long  wrote:
> Hello Tor Team,
> I read some articles about Tor security and some of them said that if the
> governments see your real IP address then they can't see
> the Tor traffic or websites that visited by Tor and if they can sniff Tor
> traffic then they can't see your real IP.
> Is it true?
> How Tor team members are sure about it? If the governments use any special
> devices for sniffing Tor traffics then why
> they should reveal it?
> If a user use the Telegram messenger with Sock5(Tor) proxy, then is it
> secure?

That 'secure' is an absolute word, there are no absolute
yes or no answer in security, only relative, except for
proverbial cutting the cable or never using one.

These questions are not specific enough for anyone
to answer. Links to the articles would be needed if
you want people to comment on those.

Governments won't reveal or stop using secret devices
unless the entire world's people demand them to.
Governments do use parallel construction.
It's not too difficult to come up with plausible and even
very likely estimates of what tools global governments,
spy entities, corporations and others are using.
If you can create devices in your mind, so can they.
Snowden and others already revealed parts of the spying.
For examples of what governments and other attackers
can and are doing since many decades...
search: Tor Stinks slides, read some of the network
traffic analysis, Sybil, and design whitepapers mentioned
in the "anonbib", some books "No place to hide",
"Permanent Record", "Puzzle Palace", etc.

There are lots of uses, and ways of using, where people
might be wise to consider not only Tor but all of todays
overlay networks to be unsafe and not suitable for
their needs.


https://en.wikipedia.org/wiki/Telegram_(software)

Can users plug all sorts of messengers, browsers,
filesharing, cryptocurrencies, applications into tor... yes.
(If you need UDP or IPv6, then add in OnionCat or VPN.)

Do some use cases for tor and other overlays provide a
layer of some level of additional protection against some
adversary attacks, beyond just raw clearnet... yes.

Should users panic about simply chatting with friends and
surfing the web over tor... no of course not, unless tor itself
is illegal for them to be using. If it's fine, then use it for that
and have fun :)

Is Telegram over tor 'secure'... that's a blanket absolute
statement, no one would say it like that, or really speculate
or analyze on it without details on usage and threat model.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] facebookcorewwwi on brief hiatus

[grarpamp]

> Facebook has started hosting and linking images and media on a clearnet

If true, this split horizoning should be quit,
not least for breaking security and access
expectations about onions.

> This is not necessarily the case.  There exist threat models (e.g.

Cert fingerprint pinning, onionland ca's...
these can also help onion surfers against
mitm onion proxies polluting the linkfarms,
provided they do the config and don't click
through the warnings.

Each of pinning, ca, and tls do have some
utility.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Onioncat and Tor Hidden Services V3

[grarpamp]

On 12/10/19, George Kadianakis  wrote:
> As a final note and as my personal opinion, I don't think onioncat
> support is gonna stop v2 deprecation. v2 addresses are 80-bit and can be
> literally brute-forced and impersonated with the current human
> technology, so their deprecation is already too late.

To be clear for users...

"deprecation" = arbitrary permanent forced shutdown and removal
of all v2 onions, use cases, applications, user preferences, etc therein.

As to "80-bit" and other v2 vs v3 differences not denoted above
(see "table" below), those aren't actually sufficient reasons
to kill v2, when, again, ...

From the perspective of users who select to use v2 pursuant
to evaluation of its features, tradeoffs, security, etc... v2 is
NOT a problem for them.

For example...

Bittorrent file distribution clouds operating entirely within
onionland (no exit).
BT protocol already rejects bad nodes, data that doesn't match
infohash, etc. Also such evaluation will have obviously noted that
BT over any overlay network, is far more resistant to censorship,
even say to MAFIAA for those demonstrating the pointlessness of
Copyright Regimes), etc... than over clearnet. Comparatively speaking,
tor+OnionCat offers a huge win for BT users in some of those areas.
Other P2P protocols may have similar semantics, and enjoy similar
benefits... cryptocurrency, distributed filesystems, YouTube replacements,
etc.

VoIP... users already know the voice of their peer, the context
of convo, and other authentication keys. For general non-critical
casual usage... social convos among friends over tor using existing
softphone apps (utilizing: IPv6/UDP)... no one really cares. Being
able to run whatever apps they want over the general protections
afforded by any overlay network is more important.

There are many use cases in which any tradeoffs between
v2 and v3 regarding "80-bit" "presence" "harvesting" etc
are either 100% superceded by the need for IPv6/UDP
in the users particular use case, or are further offset due
to the users use case not needing such levels of security.
That choice is up to the users to make, not Tor.

Rather than arbitrarily killing v2, a better way to go is...

Set v3 to be the default and promoted version.
Bring v2 up to date as close as possible to v3 in
both code diffs and security design semantics.
Split out and modularize v2 wherever it may be entangled
with and holding up other code and design areas.
Provide an unbiased and complete comparison table of
all the v2 vs v3 tradeoffs, features, design, use cases.
Point v2 client and HSDir manpage sections to the table,
ship the table in the docs, onsite, etc.
Relay nodes can participate in supporting the onion
community via their role in v2 HSDir function as always.
Community of v2 could maintain v2 as a module if desired.

Alternatively, create a v4 that can integrate with or provide
what OnionCat does (network interface for raw IPv6 transport
including UDP support over tor onionland).

> work

Tor has a multi-$Million dollar budget, so that's
not much argument against v2 or anything else.
Especially compared to other similar and sized
projects with far less or no funds.

A side layer may develop.
Another overlay network may also do things.

Use cases and acceptable tradeoffs do exist for both v2 and v3.
While that remains the case, killing off either of them would
seem questionable.


Here are some fun use cases for tor, and other overlay networks,
that users are free to build, some of which may require OnionCat...

https://www.torproject.org/
https://www.onioncat.org/
git://erdgeist.org/opentracker
https://transmissionbt.com/

https://ceph.io/
https://en.wikipedia.org/wiki/LizardFS
https://bitcoin.com/
https://en.wikipedia.org/wiki/Tox_(protocol)
https://en.wikipedia.org/wiki/Comparison_of_VoIP_software
https://en.wikipedia.org/wiki/Comparison_of_instant_messaging_clients
https://en.wikipedia.org/wiki/Comparison_of_instant_messaging_protocols
https://en.wikipedia.org/wiki/List_of_SIP_software
https://en.wikipedia.org/wiki/Clustered_file_system#Distributed_file_systems
https://en.wikipedia.org/wiki/List_of_file_systems#Distributed_parallel_fault-tolerant_file_systems

Have fun :)
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Onioncat and Tor Hidden Services V3

[grarpamp]

On 9/16/19, s7r  wrote:
>> P2P type of applications start to break down

> What do you mean here? I guess you mean P2P type of applications s tart
> to break down when the host / user count grows beyond 10 or so _only
> when OnionCat is used with HSv3_, right? Why is that exactly?

No, provided you can get them talking bidirectionally,
users apps run just as well on v2 as they do on v3.
But v3 breaks 1:1 mapping between ipv6 and onion,
and onioncat doesn't yet integrate with hashring or use
some other layer to do addressing lookups. The documented
example is to configure a mesh of static maps... that works
for small numbers of users / services that already
know each other, up until you have to start maintaining
many tens to hundreds in onioncat config. And
P2P apps that interop with random peers don't work.
As an example, try setting up both ping, and then bittorrent
or any other P2P app, over both v2 vs v3 onions, then you
will see what breaks and how painful and limiting
the v3 onioncat hack is to use with P2P.
Actually installing OnionCat and setting up some apps
to run over it will help show better than any words here could.

Either HSv2 support must not be allowed to go away,
or onioncat must be made to work with HSv3.
Otherwise tor permanently loses a major onionland capability.


https://en.wikipedia.org/wiki/Peer-to-peer
Including some filesystems, storage coins, VoIP calling,
mail / messaging, news, etc where setting up piles of
static maps is not an option.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] Virgil Griffith - Crypto Advocate and Educator Arrested at LAX from DPRK

[grarpamp]

https://virgil.gr/
https://twitter.com/virgilgr

#FreeVirgil
Adopt Distributed Privacy Cryptocurrencies

https://www.justice.gov/usao-sdny/pr/manhattan-us-attorney-announces-arrest-united-states-citizen-assisting-north-korea
https://www.justice.gov/usao-sdny/press-release/file/1222646/download

https://twitter.com/SDNYnews/status/1200478952520859648
10:17 AM - 29 Nov 2019
USA Berman: As alleged, Virgil Griffith provided highly technical
information to North Korea, knowing that this information could be
used to help North Korea launder money and evade sanctions.

"GRIFFITH was arrested at Los Angeles International Airport yesterday
and will be presented in federal court in Los Angeles later today.
U.S. Attorney Geoffrey S. Berman stated: "As alleged, Virgil Griffith
provided highly technical information to North Korea, knowing that
this information could be used to help North Korea launder money and
evade sanctions. In allegedly doing so, Griffith jeopardized the
sanctions that both Congress and the president have enacted to place
maximum pressure on North Korea's dangerous regime." Assistant
Attorney General John Demers said: "Despite receiving warnings not to
go, Griffith allegedly traveled to one of the United States' foremost
adversaries, North Korea, where he taught his audience how to use
blockchain technology to evade sanctions. By this complaint, we begin
the process of seeking justice for such conduct."
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] YouTube Censored Tor

[grarpamp]

> Try running "torsocks --isolate youtube-dl", it will select different
> circuit on each run.

That is often not as useful for this class of problem
as users may think. One enhanced option to address
this was ticketed over 7 years ago in #6256.

ytdl is command line, however it is not too hard to
imagine handy gui widgets for the controller or tbb,
see proof of concept pictures below...

https://lists.torproject.org/pipermail/tor-dev/2019-November/014081.html
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Brave Review Mentions Tor

[grarpamp]

On 11/15/19, d...@foundingdocuments.org  wrote:
>> …seeing ads start popping up in the Tor sites I visited

> The author is not clear enough if “Tor sites” means .onion sites or sites
> accessed through an exit node.

Both onionland and the Internet are full of advertising.
At least part of onionland still has a nostalgic feel to it :)

> 1) VPN
>
> 2) Tor

Keep in mind that both entites are essentially in the
business of selling their own sort of reasonably
good yet well caveated products, they both receive
sizable compensation streams in return.

When evaluating the claims of each,
it is best to consider not only them,
but also independant analysis as well.

And integrate into your own use case and
threat models whichever of one, both, or
none of them, that may serve you best.

Just like old BBS and telnet jump hosts and
all sorts of proxies including http, VPN's
and even other services and overlay networks
can provide good levels of protection for the
cases in which they apply.

Tor is not universally applicable or safe, neither
are any of them. Tools just don't work that way.

> expense

Any opensource software and its services that appear "free",
their users should consider ways to give something back,
particularly to those they use every week but that
receive little to nothing, in part due to the higher friction
barriers smaller and unincorporated projects have.

That's part of what Brave, BAT, and cryptocurrency
in general is about.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] Wake Up [re: YouTube Censored Tor]

[grarpamp]

On 11/8/19, Joe  wrote:
> I'm sure it's a moving target trying to figure out what some sites are
> doing wrt Tor.
> Google changes its yt coding constantly so "youtube browsers /
> downloaders" don't work.

For most services there is some workaround.

And chances are if there isn't, the services often suck
so bad as to be of no interest to many population
anyway.

> I assume they get most of the content free

CDN's aren't free, VEVO etc are surely paying nice sums
to have their junk hosted on YouTube.

> then try to serve ads or
> grab as much data about users' browsers.
> It's nice when a company gets its raw materials or wholesale products
> for free.
> That way, they have more money left to continually develop tracking
> methods & personal data accumulation. :)

Models are beginning out there where you can actually
host your own for free...

When encrypted anon p2p overlay networks and meshnets exist,
combined with decentralized distributed content browsing
applications, and privacy cryptocurrencies for monetizing your own,
all the garbage services like YouTube and Facebook disappear.

Only thing you have to pay on for is your internet connection.
Even that is free if you built your own meshnet guerrilla net.

Look at DTube for an early and incomplete example.

> Of course now, more & more people are using VPNs

Tools are still handy... encrypt, hop, obfuscate all the things.

> I wonder what the average person signing up for Google acct & giving
> their real phone #, just because "they asked for it?"

Given the choice most people would not do that.

They did not fight, so they have no choice or negotiation.

> Unless they're using burner phones.

Useful if the account is worth the $ to people,
but that option is going away fast, because
people are not fighting enough to keep it.

Many many countries require privacy invading ID to buy a SIM,
invasive shipping ID to get SIM shipped cross border,
and invasive passport ID to travel to countries that don't.
https://papersplease.org/

Much better if Google YouTube and all other online services
accepted privacy cryptocurrencies, a roughly SIM cost amount,
as forfeitable deposit on account behaviour. Or even a plain
old deposit / payment mailed in via the post. Or deployed
various community and algorithm methods.

But they don't, because behaviour isn't the issue,
their goal is to enslave you, for which making behaviour
enforcing as growing accepted norm is but one way.


>  I'm fairly certain people have no idea how far or
> fast their phone #  can travel & all the personal data that will be tied
> to it, when they the phone # to (many) companies like Google.

Nor how easily their phone # can be SimJacking attacked
and SDR Stingray OpenBTS intercepted.

Nothing really wrong with privacy preserving TOTP RFC 6238
and other two-factor schemes, even dating back to s/key opie.

But no, they want the phone # to datamine crosslink your ass,
while lievertising you that phone # is secure, private, etc.

So many examples in news of what these GovCorp
really doing on backend with all the data.


> I just give the nosy businesses the same number (like for warranty purposes)
> w/ an area code that doesn't exist.

Last N digits of many ID systems are enough to correlate
with other data, lots of whitepapers on that. Number ranges
are known and throw exceptions, facial ID checkout register
cameras linked to doorway IMEI recorders, to receipts,
to paycards, etc.

When opponents have all the data, tech, "laws", and control,
hiding is not a win, it is not a fight, it is a decreasingly effective
temporary feelgood substitute for fighting the policy itself.

Did you read the latest news on USA DNA Biometric Facial
mandatory databases creation and abuse, inside country,
and at borders, and around the world. All interlinked with
secret backend vendors databases.

Amazon Ring secret partnering with "law" enforcement.
Mailing shipping services new ID and size policies.
Social credit scores in your own country.
0-days against your systems sold off to the highest Gov bidder.

On and on the list goes, the chains closing around everyones
ankles faster than you can break them off with your neato tools.

Yet tools are nothing without instructions.

> They're as happy as little clams.

Except then most chances to educate the clerk are gone,
for at least on that visit you totally reconfirmed their brainwashing
for them by demonstrating sheepledom as being ok.

Helping people be sheeple is not helpful.

Sure, create and give them nice crypto tools.

But first help them wake up and fight.

That is the shift that needs to happen.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] Node Selection Parameters [re: YouTube Censored Tor]

[grarpamp]

On 11/7/19, Joe  wrote:
> Often the new exit circuits countries are the same as the one they
> complained about
> getting a lot of requests from certain exits

Well tor tends to focus weight on some exits,
so NEWNYM circuit not always work to avoid
"Too Many Requests" type of braindead censoring.

Exit country restriction still subject to weighting
within that, so might not often help.

Users can search and MAPADDRESS to an exit,
but they are then parked the service to that one exit.

So tor needs MAPADDRESS function to handle across
multiple specified exits, in order to maintain tor's
auto hopping around exits every so often.

Tor doesn't make it easy for users to manage their exits.
Tor doesn't know best for all.

There are no configurable parameters to make general
algorithm choices, such as true random, optional recycling,
subscriptions API, etc as needed.

Pentesters cannot even mapaddress their own CIDR blocks yet.
And nobody has even made Sybil hunting and or
whitelist node projects yet.

> lot of requests at a given time

Google YouTube is corporate colossus, it's tubes
and systems are the top 10 fattest of the planet.
They could whitelist all of tor and be perfectly fine,
not even a percent compared to global clearnet traffic.
Yet they feel need to beat up and block little tor?
For what? Some comparative amount of pithy "fuck you / Google"
comments on their social credit scoring platform.


Anyway, YouTube downloaders exist, and they have options
to reduce the downloads to useful and exit friendly sizes :)

Have fun.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] YouTube Censored Tor

[grarpamp]

On 11/7/19, bo0od  wrote:
> use invidio.us or invidious instances.

https://github.com/omarroth/invidious
https://github.com/omarroth/invidious/wiki/Invidious-Instances

Cool, but don't want to soak up some nice volunteers
proxy bandwidth/$ on unimportant cat videos, so will
wait for Google's YouTube to stop being retarded assholes.

Google won't even let you watch that stupid "Dua Lipa"
popvertising mindnumbing brainwashing programming
"music" video they've been artificially promoting and ranking
on their front page for a week. 20 Million drooling idiots already
did that, and 120M did last weeks pump, no wonder, lol.

"
WARNING: unable to download video info webpage: HTTP Error 429: Too
Many Requests
Sorry for the interruption. We have been receiving a large volume of
requests from your network. To continue with your YouTube experience,
please fill out the form below.
"

It's a global access block, not dependant upon busy popularity
or content, even fun niche are being censored from you...

https://www.youtube.com/watch?v=Lqu_6qJAIGw
https://www.youtube.com/watch?v=wge0rMHcP2Y
https://www.youtube.com/watch?v=WnuFIFU4l3M

The YouTube "experience" sucks.
There is no reason such centralized legacy services need exist.

If people wake up and just create and use them, overlay
video sharing services will be decentralized and distributed,
encrypted, uncensorable, not-demonetized, not-deranked, etc.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] YouTube Censored Tor

[grarpamp]

WARNING: unable to download video info webpage: HTTP Error 429: Too
Many Requests
"Sorry for the interruption. We have been receiving a large volume of
requests from your network.
To continue with your YouTube experience, please fill out the
impossible to complete and broken form below, and terminate all use of
non-browser-based tools. Thanks, Google User Tracking, Reporting,
Advertising, Datamining and Sharing Team"
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] Cryptocurrency: Overlay Networks, Privacy Coins

[grarpamp]

https://www.youtube.com/watch?v=MrqiYCOvoHs

Generally speaking...

There's more big picture for tor, for all overlays...
than just as tools to surf the web, lots more
you can plug into them than just a downloader,
much more to discover than on the surface TV.

And with cryptocurrencies being overlay networks
themselves, some now riding over I2P / Tor / Etc,
and or developing privacy protocols themselves,
there is certainly some tech that can be shared
and developed and interfaces made between them.

Be one step ahead.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Onioncat and Tor Hidden Services V3

[grarpamp]

On 8/20/19, Bernhard R. Fischer  wrote:
> I finally wrote a HOWTO on using OnionCat with v3 hidden services. I
> also did some patches to OnionCat to have a better integration.
>
> https://www.onioncat.org/2019/08/onioncat-and-tor-hidden-services-v3/

Thanks.

Rather than tor killing off v2 onions and HSDirs from the
codebase, thus ending all the good useful carefully chosen
and even required reasons people still use v2 and onioncat
(some of which can be found by searching list archives
for onioncat, P2P, VoIP, add more uses here)...

tor could update the default to create v3 onions,
and to require manual config of v2 onions, and to emit
nanny warnings pointing to a v2 vs v3 comparison table
on the wiki, update v2 to be as small a diff as possible
from v3, modularize v2 support and HSDir operations.
That way v2 and v3 users remain happy.

It also seems possible that a solution to what
onioncat provides via v2 onions (IPv6, UDP, IP transport
services in the host stack out across onionland, some
crazy routes between I2P, metrics ping, etc) could be
designed for v3 onions. Perhaps some form of time
expired or first come served 1:1 registration to HSDir hashring
for lookups, a NameCoin like sidechain, or using one of the
existing Tor / I2P native addressing enabled privacy cryptocurrency
blockchains as lookup index, or some new and open network
overlay DHT layer for everyone, or AF_WIDE, IPFS or
other hash based storage network, etc.

Even some tradeoffs in a solution to achieve a v3 onioncat
might be acceptable... in the same way that some v2 "security risk"
issues are accepted today by those needing what onioncat offers
thus overriding that, or are not relavant because their application
use model is not affected by such risk.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Launched: Next Generation OONI Explorer!

[grarpamp]

On 9/12/19, Maria Xynou  wrote:
> https://ooni.org/
> OONI Explorer is an open data resource on internet censorship around the
> world.

This has always been an interesting project in
the general field of network observatories. Thanks.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] PaperDump: Mirai, Tor, Darknet, TLA, I2P Censorship, PETs in Sidechains, and more

[grarpamp]

On 8/28/19, Florentin Rochet  LAZILY
TOP POSTED AND BLOCK QUOTED:
> This list is mixing good papers with several dubious ones.

Failed to denote which, and why in detail such
labels may or may not apply to them.

> I find important to mention that it would be better looking here instead
> for non-expert readers: https://www.freehaven.net/anonbib/ to find
> quality peer-reviewed works, and keep the ones that intersect both lists
> for now.

Such intersection (logical AND) will of course yield only those
papers approved and posted there by TPO / principals... any entity
doing such self curation is prone to variety of selection biases.
And peer review is somewhat often an ivory tower circle jerk
among an exclusive peer group... equally often any supposed
reviewers are not denoted anywhere. Novel papers are surely
free as any to come from anywhere with zero association,
consultation, editorial priviledge, consideration, etc given.

If you really want to know what is good vs marginal vs rubbish,
read and validate them yourselves, consult independants,
study the knowledge areas, actually discuss them in detail
in whatever communities you wish, including as desired in
those that are their subject, try writing your own papers, etc.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] PaperDump: Mirai, Tor, Darknet, TLA, I2P Censorship, PETs in Sidechains, and more

[grarpamp]

https://news.softpedia.com/news/mozilla-firefox-could-soon-get-a-tor-mode-add-on-526774.shtml
https://www.zdnet.com/article/new-mirai-botnet-lurks-in-the-tor-network-to-stay-under-the-radar/


OSINT Analysis of the TOR Foundation
https://arxiv.org/pdf/1803.05201.pdf

Tempest: Temporal Dynamics in Anonymity Systems
https://arxiv.org/pdf/1801.01932.pdf

Adversaries monitoring Tor traffic crossing their jurisdictional
border and reconstructing Tor circuits
https://arxiv.org/pdf/1808.09237.pdf

DeepCorr: Strong Flow Correlation Attacks on Tor Using Deep Learning
https://arxiv.org/pdf/1808.07285.pdf

Onions in the Crosshairs: When The Man really is out to get you
https://arxiv.org/pdf/1706.10292.pdf

Shedding Light on the Dark Corners of the Internet: A Survey of Tor Research
https://arxiv.org/pdf/1803.02816.pdf

Adaptive Traffic Fingerprinting for Darknet Threat Intelligence
https://arxiv.org/pdf/1808.01155.pdf

Counter-RAPTOR: Safeguarding Tor Against Active Routing Attacks
https://arxiv.org/pdf/1704.00843.pdf

Peel the onion: Recognition of Android apps behind the Tor Network
https://arxiv.org/pdf/1901.04434.pdf

Tik-Tok: The Utility of Packet Timing in Website Fingerprinting Attacks
https://arxiv.org/pdf/1902.06421.pdf

Mockingbird: Defending Against Deep-Learning-Based Website
Fingerprinting Attacks with Adversarial Traces
https://arxiv.org/pdf/1902.06626.pdf

A Forensic Audit of the Tor Browser Bundle
https://arxiv.org/pdf/1907.10279.pdf

Anomalous keys in Tor relays
https://arxiv.org/pdf/1704.00792.pdf

Mitigating Censorship with Multi-Circuit Tor and Linear Network Coding
https://arxiv.org/pdf/1907.03473.pdf

DNS-Morph: UDP-Based Bootstrapping Protocol For Tor
https://arxiv.org/pdf/1904.01240.pdf

Towards Predicting Efficient and Anonymous Tor Circuits
https://arxiv.org/pdf/1805.01977.pdf

TorPolice: Towards Enforcing Service-Defined Access Policies in
Anonymous Systems
https://arxiv.org/pdf/1708.08162.pdf

DROPWAT: an Invisible Network Flow Watermark for Data Exfiltration Traceback
https://arxiv.org/pdf/1705.09460.pdf


Deanonymizing Tor hidden service users through Bitcoin transactions analysis
https://arxiv.org/pdf/1801.07501.pdf

Tor Users Contributing to Wikipedia: Just Like Everybody Else?
https://arxiv.org/pdf/1904.04324.pdf

Open Dataset of Phishing and Tor Hidden Services Screen-captures
https://arxiv.org/pdf/1908.02449.pdf

A Broad Evaluation of the Tor English Content Ecosystem
https://arxiv.org/pdf/1902.06680.pdf

Structure and Content of the Visible Darknet
https://arxiv.org/pdf/1811.01348.pdf

On the Complexity of Anonymous Communication Through Public Networks
https://arxiv.org/pdf/1902.06306.pdf

A Survey of Privacy Infrastructures and Their Vulnerabilities
https://arxiv.org/pdf/1812.06226.pdf

The Effectiveness of Privacy Enhancing Technologies against Fingerprinting
https://arxiv.org/pdf/1812.03920.pdf

Where The Light Gets In: Analyzing Web Censorship Mechanisms in India
https://arxiv.org/pdf/1808.01708.pdf

An Extensive Evaluation of the Internet's Open Proxies
https://arxiv.org/pdf/1806.10258.pdf



Measuring I2P Censorship at a Global Scale
https://arxiv.org/pdf/1907.07120.pdf

An Empirical Study of the I2P Anonymity Network and its Censorship Resistance
https://arxiv.org/pdf/1809.09086.pdf


Integrating Privacy Enhancing Techniques into Blockchains Using Sidechains
https://arxiv.org/pdf/1906.04953.pdf

BlockTag: Design and applications of a tagging system for blockchain analysis
https://arxiv.org/pdf/1809.06044.pdf


Interesting that many attacks on overlay networks
seem to depend on lack of fulltime 100% capacity fill
and reclocking, and that no overlay [or underlying physical]
networks currently deploy it, nor do many nets
of other design seem to make extensive impact
upon that class of GPA. Even 14.4-56k rates could
could have interesting uses at secure levels.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] Privacy, Censorship, Freedom

[grarpamp]

Lot of talk on tor tech itself, but little on tech as
enabling a range of potential futures for history that
encrypted censorship resistant overlay communication,
social and transaction networks as a whole can
help liberate in conversation... without those
spanning from Zimmerman to overlays to now Satoshi,
all sorts of discussion on new models, regardless
of what any may favor or take up among them
or may create of their own, these free exchanges
around the world would not be happening in real time
today without such tools serving both sci-fi like inspiration,
as iterative building blocks, and now in use in the world.
That such new crypto things and convo are now in politics,
that one can even find any uncurated uncensored convo,
or create or take part in any, globally, in a few keystrokes,
is testament to the good of such agnostic tools re the subject.

https://www.youtube.com/watch?v=FDffZ7PwbBY

Those interested in tor as applied technology
should definitely take time not only with tor itself,
but to survey and try all the new overlay tech, many now exist...
from transports, to distributed storage, messaging,
cryptocurrency, text, audio, video, and social comms platforms...
but perhaps even more importantly, the range of
new conversations occuring over them, and what
convo and tools you might add out there in the new
decentralized world.

World is changing fast, have fun :)
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] [tor-onions] Presentation on Onion Networking at the BCS

[grarpamp]

On 7/22/19, Alec Muffett  wrote:
> "Why & How you should start using Onion Networking"
> https://www.youtube.com/watch?v=pebRZyg_bh8

A fine introduction.

Yet how do people, including those involved with or using other
projects in the space, compare contrast and evaluate this with
"Why and how start using" and writing for... Onion, I2P, CJDNS,
MaidSafe, IPFS and all the other overlay networks out there
and forthcoming, all in their respective "non-exit" modes?

Whether it be for protocol layer capabilities HTTPS/TCP/UDP/IPv6,
or to achieve application layer... messaging, storage, web-ish, etc.

And how does each's lack or presence of whatever API
interfaces, UDP, broadcast, name layers, or other potential
transport and programming models, lend themselves to app
development and widespread eventual adoption and use?

And how, without offering IPv6 or the ultimately better all
encompassingly wide and modular, even cryptographic,
AF_OVERLAY interface that all networks could plug into,
does anyone expect to get everything interoperable and
working together?


[Note that comparing "traction" re all other nets
accessing facebook is false since those nets simply
do not offer a simple exit mode to do so as tor does.
What would be fair is if facebook had CJDNS, I2P, Onion,
etc interfaces, and then comparing those access stats,
scaled relative to each respective project estimates of
number of users, project advertising funding impact,
project *Browser availability, etc.]
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] [OrNetRadar] >25 new relays in AS "DigitalOcean, LLC" (2019-06-21)

[grarpamp]

Dumb Sybil comes in noisy all at once, Smart Sybil sneaks in
1/week until you're 0wn3d. Tor's been around for over 15y.
No one's ever analyzed for that...

Anyhow, send this comedian to bad relays until
they at least emit MyFamily.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] [tor-dev] Cryptocurrency: Total Energy Analysis - Crypto Uses Less Than Fiat

[grarpamp]

Expanding from...
https://lists.torproject.org/pipermail/tor-dev/2019-June/013890.html

On 6/17/19, Hans-Christoph Steiner  wrote:
> I was an early proponent of crypto currencies, but now it is clear to me
> that they do more harm than good by a long shot.

Lacks specifics.

> And this is really off topic for this list.

Energy hardly off topic for Tor in general though...

If people suggest PoW to solve some Tor thing, and others
then claim something or some generic about its applicability,
others are free to further qualify what they introduced.

Cryptocurrency is actually quite green, renewable, clean
and efficient.. it must be in order to compete long term, it is
also naturally incentivized to do so, Fiat has no such care at all.

Media is well known to spew biased FUD and anti about energy,
and they link to non-comparative non-visionary research as the
whole gospel when it's clearly not.

DYOR: Even the crudest of Fermi Estimates, and lowest of
effort searches will start to turn up info therein leading to
searching out a more complete picture...

https://twitter.com/C_Bendiksen/status/1136641061298876417

PoW can take many forms, from mechanical turk captcha brainwork,
to protein folding and other research computing, to serving dual role
as heating etc, yes even to simplistic brute force where needed.

There are many potential PoW choices and libraries out there
and coming in the future. Some hardly "damaging" or rendering
of all land, sea, and civilization to dust.

To just say "PoW bad for Tor" is a bit off, though yes if it
could be a solve, then indeed survey the choices therein.

BTW, you know there are now [PoW] cryptocurrencies and blockchains
that use operate and transport over Tor in various modes... some
exclusively within onions, others split horizon, others well documented
on how to use exits. Same with I2P and other overlay networks.

Is Tor to censor block the "non green" uses?
What about the "illicit" "harmful" uses that are in fact
less volume and incidence than even Fiat sees?

One must also know that Tor nodes and all its infrastructures from
physical to human... consumes many tanker loads of power too.
Yet who has given any open redpill non hypocritical or at least equal
finger pointing thought to analysis on any solar renewable green or
even nextgen nuke sensibility therein?

Where is the Tor relay node selection screen that lets users
select their personal choice to path only through "green" nodes?
How do users even identify and fund those nodes?
Where are the "I run / support green relay" t-shirts for those wishing
to virtue signal?
The onions used to be green, now they're purple,
purple is a strange color in nature, some hesitate on it.

Green pathing would fit right in with the overall "Anti-Sybil relay metadata,
operator WoT, badexit, and DA" research projects, choice and subscription
tool for users that has yet to be explored.

What about Tor declining money from non green, non brutal force,
and even non Proof of Bad Stake... sources and forms? Such as those
from Governments and Banks creating their Fiats for their tax inflation
theft murder war lies ops corruption and manipulation.

Given tor nodes splay across global DC's, biz, and home instead
of some of the more focused, even intentionally green, placement
of cryptocurrency nodes... an actual net analysis of an averaged 1MW
of tor versus 1MW of cryptocurrency, is likely to show Tor as "worse"...
such that betting some cyptocurrency on that would be a win.

Things, ways to create solve and live, all use energy.
Tor uses energy... watts... buildings, cars, food, services, money.

One really needs to start breaking it down to understand it all.

Thankfully cryptocurrency is forcing humanity to break it down,
and to think about and change many of the hardest walls, forces
and energies ever built and expended against them... from physical
to monetary to philosophical to political to mind control and more.

And distributed strong privacy cryptocurrency coins and
privacy networks are helping to make that happen.

Don't be afraid to burn a few watts therein.
And to design out, save, and recycle some where you can.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] DA Under Control, Sybil... Surge of Random Threats Upon Users?

[grarpamp]

On 6/9/19, Roger Dingledine  wrote:
> On Fri, Jun 07, 2019 at 01:01:38PM +, iwanle...@cock.li wrote:
>> Can Directory Authorities analyze hostnames of relay users and publish
>> them?

Yes. Lots of interesting and "safe" analysis can be done.

As to a different question... being too few and centralized, risks
are concentrated there versus being spread across distributed models.

>> So DAs may
>> be under control of torproject.
>
> No, the directory authorities are run by nine individuals who are part
> of the Tor community but are not 'under the control of torproject'. They
> make decisions on their own, and for most security choices a majority or
> threshold of them need to decide on something before it becomes so.

And yes, the DA's are controlled under threat of arbitrary removal from
the hardcoded list by Tor Project Inc (a US Corporation thus also
under US Govt jurisdiction and control) and its paid employees (both
TPI and its associated payees subject to financial capture by US
and other Government and Entity funding sources)... among others
still having access to the repo, release, and upgrade mechanisms.
Then more externalities... the community infiltrators and agents, the hosting
companies, the network feeds, the other countries, the mysterious
DoS attacks, black ops, etc. Be influenced, have churn imparted, do what they
want, follow their arbitrary whim, that of their secret Boards, their "Laws",
courts, thugs, etc... or else. DA's have already been arbitrarily shutdown via
weaponized social attacks. Thus one must now always expect that too.
Which many might find absurd. Then look to censorship of freedom of speech,
proposals to ban onions, and other curiosities from around the world.
And must of course expect weaponized legal and extrajudicial attacks
from around the globe. Odds are one or more DA's will fall to such
various means of control before any sort of utopia is reached.
Adversaries are most definitely working to draft the context, even events.

Avoid some of that by distributing away from such centralized control
and threat mechanisms, raise the costs to the adversaries. Have it
in the bag, tested, and ready for users to enable. Majority of static 9...
cat's play. A DHT, blockchain, or otherwise distributed set of 90...
much harder. Integrate both at once. Let users decide and configure.

"Control" is not so simple a word, one must think about what it
means.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Open tickets

[grarpamp]

>>> why are there so many tickets which are open since years without any
>>> visible progress? Will they ever be solved or were they forgotten by
>>> its owner?
>>
>> no activity generally means no one wants to fix it as of now or there
>> are more important issues to look after.
>
> For example, it seems that many tickets about v2 onion services are
> ~dead. Because v2 is being phased out, having been replaced by v3.

Ticketing systems of both open and closed source
systems all look like this... piles of unfixed issues and
unresolved directions. That's not necessarily bad,
just nature.

The right thing to do is for everyone to exert concerted
effort to process them until cleared, a regular banner
month of triage sport, and dedicating new time
percentage ongoing.

Retest and mark current, reopen or reexamine
arbitrary closures, flesh out proposals, add
steps and patches.

As to v2 onions, they provide the only and thus vital
way, in conjunction with OnionCat [1], to support both
UDP and IPv6 transport entirely within onionland services [2]
for the people and applications that need that, and they
obviously accept the v3 vs v2 tradeoffs to achieve that capability.
Until some means for end-to-end P2P 1:1 UDP and IPv6
within v3 onionland is developed, v2 onions remain entirely
valid and should not be removed. Create a maintainer and
HSDIR group just for v2 module if need be. Search this
list for OnionCat or v2 to learn more on this subject.

[1] And OnionVPN
[2] Plus whatever other overlays and networks users
like to securely link up with using IPv6, such as CJDNS.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] VPNs and Ports

[grarpamp]

On 05/23/2019 02:39 AM, Wallichii wrote:
> On Thu, 23 May 2019 04:15:36 -0500
> Conrad Rockenhaus  wrote:
>
>> a free VPN service... to allow users that are blocked... to access...
>
> not everyone is going to trust
> someone on the internet giving
> free proxy

So what exactly do people think tor exits are?

Either your TLS certs pass both CA and observatory and are pinned... or not.
As to all non secured protocols, see the above question.

For more info, search talk and relays for: Sybil
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] VPNs and Ports

[grarpamp]

On 05/23/2019 02:39 AM, Wallichii wrote:
> On Thu, 23 May 2019 04:15:36 -0500
> Conrad Rockenhaus  wrote:
>
>> a free VPN service... to allow users that are blocked... to access...
>
> not everyone is going to trust
> someone on the internet giving
> free proxy

So what exactly do people think tor exits are?

Either your TLS certs pass both CA and observatory and are pinned... or not.
As to all non secured protocols, see the above question.

For more info, search talk and relays for: Sybil
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] VPNs and Ports

[grarpamp]

See reply on subject here...

https://lists.torproject.org/pipermail/tor-talk/2019-May/045201.html
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] VPNs and Ports

[grarpamp]

>> On May 23, 2019, at 4:39 AM, Wallichii  wrote:
>>
>> On Thu, 23 May 2019 04:15:36 -0500
>> Conrad Rockenhaus  wrote:
>>
>>> I’ll be starting a free VPN service soon to allow users that are
>>> blocked from using Tor at their location to access Tor. To prevent
>>> abuse of the service, I plan on restricting the ability of the VPN to
>>> only access 53, 80, 443, 8080, 8443, 9001, and 9030. Are there any
>>> other ports I should consider keeping open for the service?
>>
>> IMO setting up a bridge will help more users because not everyone is
>> going to trust someone on the internet giving free proxy, you should
>> run a bridge if you want to help more users.


That would be an input VPN... perhaps useful if DPI was
breaking user's tor access protocols (to bridges or
regular entry guards), but not their VPN traffic.

Output VPN's could also be useful to allow tor users
to bind their stack to it over tor, thus permitting UDP
back and forth from clearnet... typical with voice video
comms and a bunch of other applications that have
been disabled for tor users becase tor only supports TCP.

Operators would have to publish their VPN node info
somewhere for users to use... or getbridges, getvpns.

There are prior exploratory threads on this here before.

Operators can also be running and supporting VPNGate.net
service as both input and output.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] VPNs and Ports

[grarpamp]

>> On May 23, 2019, at 4:39 AM, Wallichii  wrote:
>>
>> On Thu, 23 May 2019 04:15:36 -0500
>> Conrad Rockenhaus  wrote:
>>
>>> I’ll be starting a free VPN service soon to allow users that are
>>> blocked from using Tor at their location to access Tor. To prevent
>>> abuse of the service, I plan on restricting the ability of the VPN to
>>> only access 53, 80, 443, 8080, 8443, 9001, and 9030. Are there any
>>> other ports I should consider keeping open for the service?
>>
>> IMO setting up a bridge will help more users because not everyone is
>> going to trust someone on the internet giving free proxy, you should
>> run a bridge if you want to help more users.


That would be an input VPN... perhaps useful if DPI was
breaking user's tor access protocols (to bridges or
regular entry guards), but not their VPN traffic.

Output VPN's could also be useful to allow tor users
to bind their stack to it over tor, thus permitting UDP
back and forth from clearnet... typical with voice video
comms and a bunch of other applications that have
been disabled for tor users becase tor only supports TCP.

Operators would have to publish their VPN node info
somewhere for users to use... or getbridges, getvpns.

There are prior exploratory threads on this here before.

Operators can also be running and supporting VPNGate.net
service as both input and output.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] VPNs and Ports

[grarpamp]

>> On May 23, 2019, at 4:39 AM, Wallichii  wrote:
>>
>> On Thu, 23 May 2019 04:15:36 -0500
>> Conrad Rockenhaus  wrote:
>>
>>> I’ll be starting a free VPN service soon to allow users that are
>>> blocked from using Tor at their location to access Tor. To prevent
>>> abuse of the service, I plan on restricting the ability of the VPN to
>>> only access 53, 80, 443, 8080, 8443, 9001, and 9030. Are there any
>>> other ports I should consider keeping open for the service?
>>
>> IMO setting up a bridge will help more users because not everyone is
>> going to trust someone on the internet giving free proxy, you should
>> run a bridge if you want to help more users.


That would be an input VPN... perhaps useful if DPI was
breaking user's tor access protocols (to bridges or
regular entry guards), but not their VPN traffic.

Output VPN's could also be useful to allow tor users
to bind their stack to it over tor, thus permitting UDP
back and forth from clearnet... typical with voice video
comms and a bunch of other applications that have
been disabled for tor users becase tor only supports TCP.

Operators would have to publish their VPN node info
somewhere for users to use... or getbridges, getvpns.

There are prior exploratory threads on this here before.

Operators can also be running and supporting VPNGate.net
service as both input and output.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Where is 32bit linux tor?

[grarpamp]

Everything also here...

https://dist.torproject.org/
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] Hidden service persistent connections (Traffic Analysis)

[grarpamp]

On 5/17/19, Memory Vandal  wrote:
> Are client connections to a hidden service .onion address that do not
> disconnect for hours safe?
>
> It may be a big file download or multiple keep-alive transactions that uses
> the established connection over and over for lets say few hours.
>
> If its not safe then what should be the max time a connection to .onion
> service should get disconnected so that it uses a new circuit when it
> reconnects?

GPA and big global and regional network operators
can pull out traffic patterns. NSA's own slide decks
and papers, as well as academic researchers whitepapers
in tor bib and elsewhere have confirmed this.

Here are some degenerate traffic pattern...

while : ; do wget onion ; sleep 5 ; done
ping6 -w 5 

Who thinks those is or is not observable?

Now receive or send your real N-GiB file, plot the packet
timings and bandwidth variations going aross your nic.
Do not forget the circuit creation wavefront either.

Who thinks those are or are not observable at the
other end (and even throughout in some cases)?

Now add in targeted DoS blinking out nodes.
And add in Sybil.

Who disbelieves those tools effective?

Who disbelieves "Op Ivy Bells" "641a" "Bumblehive" and "parallel construction"?


Tor and many other overlay networks fail to
deploy traffic fill and regulation, or try traffic
mix and other various means to lessen or
defeat such analysis.

There are a few papers and overlays and hardware
hopefully trying such and other things for the near future.

You can list all the ones you can find here if you want,
and see about creating, running and supporting them too.


Maybe if you adopt true distributed privacy cryptocurrency
instead of central fiat shitcoins you can start put them
spyings and so many other bad things against
humanity into "max defund time" too.

Wake up.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Solving World's Tor Users Being Blocked by Websites (was: Tor exit bridges)

[grarpamp]

Some other segments often referenced...

https://2019.www.torproject.org/docs/faq.html.en#HideExits
https://2019.www.torproject.org/docs/faq-abuse.html.en#Bans
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Solving World's Tor Users Being Blocked by Websites (was: Tor exit bridges)

[grarpamp]

Adding this to the collation of potential approaches already
posted...

Blinded Tokens for CloudFlare...

https://github.com/cloudflare/challenge-bypass-specification.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] Solving World's Tor Users Being Blocked by Websites (was: Tor exit bridges)

[grarpamp]

On 5/7/19, nusenu  wrote:
>
> juanjo:
>> Tor relays are public and easily blocked by IP. To connect to Tor
>> network users where Tor is censored have to use bridges and even PTs.
>> But, what happens on the exit? Many websites block Tor IPs so using
>> it to access "clearweb" is not possible. Should we allow and start
>> using "exit bridges"? In I2P we have not this problem since there is
>> no central IP list of relays.
>
> there is no need to extend to one more hope to achieve this
>
> https://lists.torproject.org/pipermail/tor-dev/2018-March/013036.html
>
> https://lists.torproject.org/pipermail/tor-relays/2019-May/017273.html

It's possible to augment such outbound
solution offerings even further by running
an OpenVPN termination service so users
can transport UDP between clearnet as well.
VPNGate.net project has an idea there too.
Even large regional IPv6 pools could be bought
and shared by operators and rotated through.

More tor relay operators should consider
some of the above options, whether as a
requested "bridge" service mechanism, or
listed in the consensus "contact" field, or
as more of a standalone VPNGate support,
or "ExitGate" project sort of arrangement.

Using only tor right now, a user needs to use a clearnet service
that does not scrape consensus, or one not fronted by services
doing similar to CloudFlare's spiteful default tor blocking policy,
or find a lucky exit within whatever geolocation game the clearnet
service uses, or get lucky through traditional vpn or proxy.

But those are only fun statistical hacks, not real long term solutions
to the underlying problem.

It's unfortunate that such braindead blocking, stupid policy regimes,
sites refusal to developing creative solutions [1] for so many world's
users legitimate privacy, info risk, anonymity needs... often results
in users accounts being locked out and escalated into forcing disclosure
of users private info and ID to sites to unlock them, thus exposing
users to ongoing long term fraud, cost, and stress when that info
(in most cases truly unnecessary to collect) is eventually shared
misused and stolen by both sites and criminals... or outright auto
deletion of user's valued account, built up social networks, etc...
all for doing nothing wrong, and harming no one or thing.
Death by DriveByExit :(
And really shameful to deny world's users the right to simply read
a website, be it social, commercial, information, etc or even sadly
their own tax-theft funded governmental public sites doing this
blocking too.


There are some related projects, best practice, as well...

https://trac.torproject.org/projects/tor/wiki/org/projects/WeSupportTor
https://trac.torproject.org/projects/tor/wiki/org/projects/DontBlockMe
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-access

Positive outreach and direct engagement by Tor community
is key here, and perhaps not enough of that is happening,
at least not publicly. It's a big enough issue that it really needs
a dedicated, active, allied, and even funded subproject...
a MegaProject that needs to happen.


[1] Such as forfeitable cryptocurrency and mailed-in cash
deposits refundable in time, increasing account priviledges
and features based on account age and activity, community
moderation and behaviour support within the sites, opensource
third party tracking-free local SecurImage style captcha throughout
a sites features, privacy preserving non-SMS non-Google/Apple
pure TOTP authenticator protocols, PGP recovery, letting
users simply *read* websites without any hindrance,
while utilizing these methods only for *write* operations,
etc and so many more ways you can envision...


Cc'd for awareness and inclusion. *Please remove tor-dev
and tor-relays, and move this to tor-talk or tor-access
for ongoing discussion and progress. Thanks.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] How keep the hidden service when changing IP interface?

[grarpamp]

On 5/7/19, Van Gegel  wrote:
> the problem of keeping of a hidden service after periodically changing the
> IP provided by the mobile operator as well as when switching between Wi-Fi
> and a cellular network.

> In such a case Tor should detect that the used circuits have become
> unavailable and build new ones and, possibly,
> possibly, republish rendezvous points for my hidden service.

> onion service becomes unavailable for a very long time (hours)

Tor may not yet have ability to remember and depublish
such descriptors from HSDirs upon IP change, so there
can be some conflicts in the ring for some hours sometimes.


> - What is the algorithm for keeping the life of a hidden service implemented
> in Tor?

https://gitweb.torproject.org/torspec.git/

> - How to force verification / republish without restarting Tor in case the
> own HS is not available in the periodic self-test?

The tor controller interface has some functions to publish descriptors.

And a new onion address will also publish itself right away.

> - What settings in ‘torrc’ can I use to solve the problem?

https://2019.www.torproject.org/docs/tor-manual.html.en

> - What patches of the Tor source code can be applied (as an extreme case)?

https://gitweb.torproject.org/tor.git/
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Is 2019.www.tpo a temporary domain?

[grarpamp]

I posted the major look-and-feel transition dates earlier.
There are some incomplete bits of the website in gitweb.tpo.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Anti-Sybil (re: Explain... all the Nodes)

[grarpamp]

On 5/2/19, grarpamp  wrote:
> Node location, payment, OS, ISP, uptimes, anon / nym / PGP / GovID,
> workplace, politic, blogs, whatever else you can imagine,
> including incorporating what's already in the consensus, contact,
> MyFamily, nickname, both real world and virtual infos,
> operator to operator p2p Web of Trust...


Syverson writes:
> Note that we created a research system for gathering such data,
> reasoning about the trust implications, and applying it to routing
> decisions. we wrote a paper on it that we presented at PETS 2015.
> "20,000 In League Under the Sea: Anonymous Communication, Trust,
> MLATs,and Undersea Cables"
> https://www.petsymposium.org/2015/papers/04_Jaggard.pdf

Its mentioned modularity is a nice feature wherein
here any number of module author groups could collate
data in their areas of interest / knowledge into modules
that then get plugged into the node selection framework.

Usually on the lists people often seek to
avoid or stay with certain countries, so that
leads to a "jurisdiction / MLAT" module.
There could be "seabed fiber owner operator" module.
A human-to-human operator WoT module.
Many more you can think up.

Tor currently offers perhaps only three, they are
in essence the default modules...
- random selection and exit policy
- bandwidth / consensus weights
- DA decisions

Keep the defaults, or go with community assemblings,
or choose whichever modules you want and any
specific configuration each provides, add them
into the node selection engine under any relative
weighting you choose, point the engine at the controller,
or otherwise load it into the overlay daemon.

It would not be difficult to conceive how such
framework could be extended for use with
many of the node based overlay networks.

Is it wise to override the defaults of any such network?
Perhaps until there are networks strongly or completely
resistant to Sybil, Vampires, and any other classes of
attacks... there may be cases and conditions where it is,
and many where it isn't... one size might not fit all.

There would probably be some interest out there in
developing a list of all potential modules. And even coding and
datafeeding the more popular ones, say the "Human WoT",
as a proof of concept exploration.

Note Bittorrent "Here's a bunch of random nodes, good luck"...
for which many communities collate and maintain published lists
of known or suspect nodes to block (MAFIAA networks, LEA, etc)
by plugging them into clients, resolvers, and packet filters, in an
effort to reduce risk of Sybil beyond the defaults.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] Anti-Sybil (re: Explain... all the Nodes)

[grarpamp]

On 5/2/19, Herbert Karl Mathé  wrote:
> I strongly believe certain issues need be brought up into conscious, and
> into presence: into discussion, actually.
>
> Therefore appreciating this as it might fit too well into context
>
> Keeping things below surface, or trying so, has too often proven to be a
> very bad idea as these will come up sooner or later anyway, then with much
> higher magnitude. Even worse, trust is then destroyed.

As said before, the category of Anti Sybil Web of Trust Projects
needs considered, and could even cover such speculative subjects.

It's not about analysing the meta of one node or one operator,
even if a true positive hit, in general the yield is approximately
zero percent of any overlay network's nodes, it's about stepping
back and agnostically analysing them all.

Go investigate and collate all the possible meta informations...

Node location, payment, OS, ISP, uptimes, anon / nym / PGP / GovID,
workplace, politic, blogs, whatever else you can imagine,
including incorporating what's already in the consensus, contact,
MyFamily, nickname, both real world and virtual infos,
operator to operator p2p Web of Trust...

No node has to supply any infos.

Put it all in a db and give users tools to select node sets.

Some users might select State's, or State's workers or
even Statist's nodes, over say anon nodes, as maybe they
feel they have to play by some "rules" that anon nodes don't.
Others might reject operators that post stupid pics on Facebook.
Or all Ubuntu relays. Or nodes that engage in free speech
they don't like, some in Tor Project would love that selector, lol.

It doesn't matter, it's a meta project, with it you can accept or
reject on whatever whim you wish by node fingerprints in your client.

And if the Sybil WoT project ends up discovering some interesting
potential threats classes among the entire node set, you win.
Until then, you are potentially missing all of that, and are not
raising Sybil's costs of doing business by forcing them to
expend much resource into playing real world Web of Trust
against users who might select to use various positive-meta-ranking
and or WoT structures. Right now Sybil's cost is only a little hosting.

If not, you can still report bad exits and other actual technical
node and traffic mangling to tor-relays and or bad-relays,
at least until someone DHT's or otherwise distributes tor
away from the more centralized DA design.

Note that Tor's architecture does not protect much against
Global Passive Adversary of NSA style fiber Vampires,
that threat does not require Sybil nodes, nor do they
have to be Global or Govt, even Tier-N backbones can
tap, analyse, and do nefarious things like and with that,
including sell, give, and partner it all away.
Though they can and do run Sybil nodes to help inject,
manipulate, block, see, etc traffic, nodes, and clients.

On flip perspective, maybe you really don't want to develop
WoT's and such, simply because enabling creeping featureism
of it all can lead to exclusivity and control whereby valuable anon
diversity is selected away from and purged. That would be very bad.

Either way, other than the usual design, protocol, code, and "Lawfare"
exploit space, and the coming Quantum Compute adversary, Sybil and Vampire
are likely todays biggest remaining threats to overlay networks.

None of todays networks seem to be trying to do anything to stop
Sybil, and only a few networks put Vampire as any sort of priority [1].
While Vampire may perhaps be solved with some technical measures,
Sybil may require some sort sort of human based measures.


[1] Curiously, cryptocurrencies do employ Anti-Sybil in various
proofs of work (adversary cost raising), and can help defund Vampires.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Anyone interested in running FreeBSD or Linux Exit Relays on AS19624?

[grarpamp]

On 4/17/19, Seby  wrote:
> Here we go again...

Not really different than all the quasi or non profit
tor node groups posting their news now and then.
Nos onions, torservers, emerald onions, noisebridge, etc.
Hey look at me, join us, give us money, we're doing stuff, etc.
So long as it supports the overlay networks, gets nodes
running on them, etc... some diversity in approach to that
isn't going to kill you, else hit your 'block' button.

Maybe even some new operators-to-be like the offer of
somehow working together with a hosters to get started
funding and running their nodes that they would otherwise
not be so confidant to do right away as a first step.

Worry about MyFamily and good ops instead.

> stop

OMFG yes, please stop top posting, all of you.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Onion website on "usual" server

[grarpamp]

> is it safe so onion IP won't be disclosed?

Whenever someone cuts, dos, or boots the box, it panics,
etc... all sites services on it are correlated together.

Webserver daemon, kernel, and VM exploits exist.

"Safe" means you probably do not want to be running it on
the same box, or account, payment, email, phone, isp line,
anything that is connected to you. Nor managed from your
own location.

"Won't" is bogus because even standalone onion can be
found with some methods. Whitepapers clearly tell people
that some adversaries can and will find an onion IP in time
if they want to. Tor design is unable to prevent that.
Some methods can be offset, others can't.

Those are some answers no one said.

Are whatever ways you choose safe enough for you?
Are some of your adversaries those that can do that?
You'd have to consider things more to know.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] tor project website change

[grarpamp]

> global adversaries
> "they don't likely exist, or if they do, they're our friends"

Highly capable Global Adversaries are well known to exist.

TOP SECRET friends may perhaps be the friends of few, often
end up generally corruptive, less than stellar, an uncertainty, etc...
thus really shouldn't be kept or created. Seek out better ways.


> implementing one of the newer designs seems unlikely.
> Given that potential volunteers are working on Tor.

That's another problem with large projects, like corporate and
government monopolies, they can suck up all the air in the room...
needed and valuable diversity, competition, and evolution gets
starved out, groupthink herd monoculture etc sets in generations.

In the space of critical use case anonymity, privacy, messaging
tools, crypto utility application overlay networks, cryptocurrency,
etc... a space too new to have enough breadth and depth of research
paths dreamed up and exhausted so as to begin to see what works,
to advise with confidence, or not... that would not be good at all.


Tor... circuit based encrypted onion routing tcp with quasi decentral
human roots of authority... is a done architecture model since 20 years,
its wholesale novel development research covered in its early whitepapers.

Researchers hoping for big architecture breakthroughs against
adversaries, should probably investigate other potential and new
solutions elsewhere.  Even if only filling in currently uncovered
use cases, on up to addressing current and expected evolution in
adversaries, there is a lot of fun work to do out there beyond Tor.


As for Tor, there is much left... tickets, UI, Web, Phone, optimization,
obfuscation, their own "community", waging part in the overall pro
privacy freedom speech crypto war, all sorts of research, improvements,
and publication on how its network architecture is doing in vivo, where
it's useful and not, ongoing operations... the long tail of Tor,
same as any project.


Tor gets so much money some said Tor could throw a bunch of
it into an independant overlay competition fund. But since such
parent child separation is not achievable, it is the donors who would
need to start that up on their own, and the newer diverse projects
who can consider accepting it.

Like any other project, Tor is great at what it does well,
yet those areas are *not* unlimited.

This is not Kansas, it's Overlay Land, a land known to be
considered for use by those with more critical / different
needs than say, simply browsing the web. [Even then...]

Tor users should see more disclaimer and fair honest analysis,
and less blanket use case superlative coming from Tor.

Indeed sad to whatever extent that does not happen.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] My experience contributing to any Tor Project projects

[grarpamp]

Various wrote:
> Community Council's

In the world... beware creating, or subjugating oneselves to,
or continuing on with, such things as Governments... history
shows all preserving bias to themselves, and end up failing, in part
or whole, while often screwing you and [mass] others over, in all
manner of subject areas, at times, over course, arbitrarily defining
even by "voting", having no higher or natural ombuds recourse appeal,
from day one to their end... etc. Though not necessarily easy or
apparent, there are often better ways... more should seek them.
Not least since such things can affect interesting contribution.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] AU Parliament LawEnf Committee on Infocom CryptoDarkTech (Infocalypse Game Theory, FVEY, Tarrant, darkweb)

[grarpamp]

On 4/7/19, Paul Templeton  wrote:
> You can now get a report from the AU Government on there assessment of
> 'going dark' They recognize there are legitimate reasons to using Tor...

https://www.aph.gov.au/Parliamentary_Business/Committees/Joint/Law_Enforcement/NewandemergingICT
https://www.aph.gov.au/~/media/Committees/le_ctte/NewandemergingICT/report.pdf

A few positive sentences buried in a wholly negative paper
outlining how governments and agencies are well against
crypto tools, hardware, software, networks... and doing all they
can in that regard... hardly amounts to any such recognition.

Never mind that AU, NZ, UK are all busy right this
very moment signing "laws", which history proves
are but "creepy featurism", against freedom of speech.

In fact, the words "speech" and "journalism"
do not occur at all in their paper. Any words like
"freedom" "privacy" and "rights" were largely mooted
by their desires to instruct you as to what is "legitimate"
or not, and to "balance" and "resolve" those for you in
their final solution to all such things.

There's a full tilt worldwide top secret and surfaceweb
assault going on crypto, freedom, speech, privacy, etc.

It's going to take a LOT more action than armchair submissions
to their committee papers to even begin to fight back against that.

Just like the global surveillance rollout... now that they've censored
the Global Surface Web with the help of their Corporate Friends,
and thereby forcibly pushed the next Christchurch into happening
on Tor... let's see how long Tor and crypto holds up to that.

That's their game. Expect it.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] What is the weirdest/creepiest thing you have found on the dark web?

[grarpamp]

> https://www.youtube.com/watch?v=4DJAWGXkvq8
> https://fosdem.org/2019/schedule/event/tor_project/
> https://news.mit.edu/2015/tor-vulnerability-0729
> https://www.youtube.com/watch?v=g7YCbYe7lO8
> https://en.wikipedia.org/wiki/Dark_web
> https://en.wikipedia.org/wiki/Darknet
> https://www.youtube.com/results?sp=CAM%253D_query=darkweb
> https://duckduckgo.com/?iar=images=images=images=darkweb+OR+deepweb
> https://www.youtube.com/watch?v=XMWj_47WXcs

Were anyone to free themselves and go for a drop
in their own bathyscaphe, they'd find the overlay networks
full of sauce that they will NEVER be able to discuss
with anyone from their IRL surface web, which itself still
has a few of its own gems.

All the youtube channels covering darkweb
haven't so much as got their feet wet,
they can't, they'd get shutdown for free speech.

"Crime?" Like on the nightly TV news?
Is that what you think the darknets are all about?
Lol what a boring waste of time.
Go learn about what is not on the news.

Burn your eyes out. Discover the Mysteries.
Explore the Occult. Move the Data. Chat with Vaihan
over at d9b9bf44c88e088a7c37e3ba3cec94f8654f5915.
Contribute to The Movement. Read ... ..   ... ...
Whatever you do, DO NOT push "the button".

Do you really expect to find the secrets just handed to you on a plate?
The only place you will find them is in the darknets, not up here.
Take the red pill, play the game, if you dare.


On the other hand, darkweb is really just a technical term.
All sorts of cool, useful, everyday things exist on the overlays,
communities, lots of tech, projects, conversations, etc...
Don't let any surface dwellers ever shut the networks down.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Is there a way to use internet in a sandbox environment? (Linux)

[grarpamp]

Bootstraps and kernel must get loaded and executed.
All [writeable] hiers can be either mounted off media,
or ramdisk, or NFS iSCSI darknet etc, and encrypted or not.
Some systems mount the media as rootfs for userland,
others copy it to ramdisk and pivot root to that.
You can still bundle in or append the entire fs to the
kernel and boot the whole single file blob over the
network with your xbox on the big screen if you want.
"Image" historically refers more to the kernel,
which people used to write directly to a single boot floppy.
Many ways to do it. Have fun :)
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] tor project website change

[grarpamp]

> why adversaries should finance tor project and publicly it if they have
> a malicious intent?

Why do adversaries do that to their opponents?
Because it's a simple and effective diversion operation.
Nor is it dependant upon whether any "malicious intent".
Adversaries often fund their opponents to keep them busy and happy
even if opponent only a few steps tangent behind the race to actually
being able to kill the adversary. It can work actively...
"Here's a pile and stream of money to develop some useless
or thing we want in an RFP / contract / grant / employee",
or passively... "Hey, those guys seem to be going down useless
paths, ok here's a bunch of money to keep them happily digging
in those holes, LOL." Usually delivered by false fronts.
See also "regulatory capture" type of concept. Also how nice
salaries and simple weight of self reinforcing mass inertia and
groupthink over time can keep any one or group settled into the
same thing, less dynamism, up to even not abandoning and starting
out elsewhere due to simple risk aversion... "job food friends lifestyle."


Is an entity, product, or network subject to whatever
to some degree or other? Maybe, maybe not, others decide.
Yet without talking about and analysing harder questions
once in a while, especially as generations come and go,
people might have less sense therein.

If a site looks sexy it must be good, right?
That's what at least marketers think, and it's perhaps good enough
for browsing mundane TV news sites. Yet there's no frontpage
splash disclaimer for others with more sensitive, vulnerable,
or different use cases.

Nor mention of Tor people hypocritically trying to censor ban
nodes out of the consensus for, ironically, nothing more than
excercising their right to free speech. Instead of say punting that
out to meta analysis projects that users can choose to subscribe
to as suits their own likes, support, and thinking therein.

To be fair, no different than any other business (say ibm.com)
or opensource project... finding much suitability disclaimer
on anyone's pages, surely not without a good number of clicks,
it's of less interest or natural to cover some potentially
questionable areas, adversarial weaknesses, etc... it doesn't sell.


Anyhow...

The last actual use case warning or disclaimer on torproject.org
was removed by or on October 10 2010. Some historical bisects..

Site v1
first, domain 1998-01-29
http://web.archive.org/web/19981212031609/http://www.onion-router.net/

same content actually to "circa" 2006
http://web.archive.org/web/20061023145713/http://www.onion-router.net/

http://web.archive.org/web/20130120133213/http://www.onion-router.net/
except for the gov diff
http://web.archive.org/web/20130420093515/http://www.onion-router.net/

curr
http://web.archive.org/web/20190228035625/http://www.onion-router.net/

Site v2
first, domain 2006-10-17
http://web.archive.org/web/20071011223019/http://www.torproject.org/
last
http://web.archive.org/web/20101003133226/http://www.torproject.org/

Site v3
first
http://web.archive.org/web/20101010191937/http://www.torproject.org/
last
http://web.archive.org/web/20190326100059/https://www.torproject.org/

Site v4
first
http://web.archive.org/web/20190327033924/https://www.torproject.org/


Misc...
http://web.archive.org/web/20041108031017/http://wiki.noreply.org/noreply/TheOnionRouter
http://web.archive.org/web/20070104070427/http://wiki.noreply.org/noreply/TheOnionRouter
http://web.archive.org/web/20100416102850/http://wiki.noreply.org/noreply/TheOnionRouter
http://web.archive.org/web/20110728115309/https://trac.torproject.org/projects/tor/wiki


> what you said

It's really all junk lately, just delete it.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] Crypto Network HW Links, Anti Vampire and Sybil Nets, Actors Everywhere

[grarpamp]

> If the state is out to get you I'd just assume that everything arround you
> is rooted and a wire tap and act accordingly.

Doesn't have to be anyone doing anything wrong.
Anyone following geopolitics knows that surveillors
can reap just aggregate spying and turn that into
realtime influence messaging to their own purpose.

"Looks like a lot of overlay users are visiting
a node known for artwork. Let's craft on that."
"Cryptocurrency rising... Let's craft that."
"Here's todays daily statistical and Markov report... Craft it."

> assume that everything arround you is rooted and a wire tap

Is this not entirely possible for all users of
technology around the globe today?

Snowden and everyone else before and since told you
that you're all being tapped, datamined, controlled, and used.
But most still don't believe it, or do anything to
directly end it, all you do is drop some tools,
while leaving all the taps, entities, activities, policies,
still in place. Oops.

Recall that you have all still started up exactly ZERO
projects that are combining all these elements...

#OpenFabs , #OpenHW , #OpenSW , #OpenDev , #OpenBiz , #OpenAudits , etc

So you still clearly have zero knowledge of what's
actually in your CPU's, your NIC's, your storage,
your networks, or any reason to explicitly trust them.

You're all April's Fools still stupidly placing faith in secrets [1]
even after endless stream of their lies exposed by exploits,
be they cataloged by CVE or even network TV news.

[1] Be they commercial, [geo]political, etc.

>> Be they overlays on top of the internet,
>> enhancements to the internet,
>> or new guerrilla physical plant...
>>
>> That process of people contributing to
>> original and ongoing development of new
>> strong networks that are not susceptible to such
>> Basic Bitch Adversaries as Global Vampires,
>> is something more should consider.

> Indeed, we'll get there eventually.
> I am just a guy that made a thing because I thought it was cool.

Yes. Hopefully more will see the need to make
cool and different things that can all be
competed, evaluated, merged together,
and even happily and graciously abandoned
and joined up for the next where needed, in
order to help get everyone there. This applies
outside the Tubes as well.

>> Same for likely figuring out how to get
>> the deployment Social aspects right so
>> you can circle the network wagons against Sybil.


> Let the record show that I am not the one making the sybil resistance claims
> it's the coin team that is. I doubt them as well but I am open to being
> surprised. I orignally had another model in mind for mitigating bad actors
> on the network that I still plan on implementing (eventually)
> Effectively it's a f2f mesh connectivity layer to help hide traffic shape.

There's certainly no lack of pure f2f, or p2p dht,
or central, or hybrid tools out there in history.
Models, threats, and use cases all being tested
and mashed together is good, and fun to do :)


Sybil is extremely hard to protect against and root out,
since all Sybil needs is Money, and an Excuse to be there.

As noted in tor lists since years, the solution to Sybil
might not be as complete with only "in network" methods.
It will more likely require at least some in real life Web of Trust,
Humans asserting over the nodes they run, the software
analysing that web, making node selections based on
that metadata.

"I know her, she works at the store, he's at my
meetup group, they're a local company, etc...",
and so on, a mesh of persons to persons, running
nodes and fiber, all around the planet.

You're probably going to need to force Sybil to
become a verifiable IRL Human Being...
because right now all she needs is money,
and her bags are full of it.

In a 1 million node network, if half of the nodes are
from WoT verified humans, each human runs 10 nodes,
and only 50% the users prefer to make exclusive
use of the WoT... that's 25k unique logical nodes now
showing themselves as being more than just a
completely anonymous potentially adversarial
[point] source of money renting out boxes around
the globe.

Can 2.5% of the nodes making up any of todays
transport, cryptocurrency, or application network
overlays be said to be sufficiently trusted?

Do any even need to be?

In addition to signing human WoT data in the network
layers, you could also start pushing analysis of node
metadata into subscribable routing metrics... where
are the nodes located, OS, uptime patterns, spec
conformance, degrees of WoT such as non IRL nyms,
and how strong each asserters verification and assertion
policy framework is, etc.

All of this and more could raise Sybil's cost and
exposure risk qute significantly, perhaps to futility.

Everytime the Sybil WoT subject hits the lists
it's met with abject silence [or "Johnny can't..."]

Is this due to fear of associating with a node
(or trying to protect the node by not associating)
such that if the node is taken down the operator
can walk away or redeploy 

Re: [tor-talk] Syncing bookmarks

[grarpamp]

Most people don't need "bookmarks" if the nets
they're on have search portals they can safely use.

For more sensitive needing non local storage...
people routinely store their own encrypted blobs
on the overlay networks be it web file hosts,
or more exotic stores like IPFS, Tahoe-LAFS,
MaidSafe, blockchains, NNTP, etc...

Other than that, good old local file encryption
is probably your best bet.

If you're trusting any sort of crypto lib supplied
by the "bookmark" or storage provider, you're
doing it wrong.

ie: A webmail provider PGP mail javascript crypto library
loaded from them over https into your browser... not good.
The library must come from disinterested third party project
and be sig verified by you before you load into browser for
execution. If OpenPGP.js was shipped by the browser
vendors for use with third party webmail, that wouldn't
be as bad. But if the browser company is using it to
secure your "pocket" in their system, you're crossing
the trust streams again.

Choose whatever level of trust vs work vs risk suits you.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] GoldBug Messenger, SpotOn Crypto, etc (Re: Syncing bookmarks)

[grarpamp]

On 4/1/19, Tom A.  wrote:
> Hi Grar
> like to help you with questions that one can answer, just ask, trying to
> share some testings and learnings.
> you have a certain view, there is no goal, just telling others who seek
> info about sharing good practice experience.
> Regards and have a great week

Other than your handful of shills, after years there's
still apparently no userbase of users on the internet,
and certainly zero even remotely trusted voices, that
are "sharing their experience" with such supposedly
great things as GoldBug Messenger, etc.

So instead of writing me...

Your gang can "just try" to start by publicly answering
the questions people have repeatedly asked you on
public lists about your fishy projects.

Good luck.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Is there a way to use internet in a sandbox environment? (Linux)

[grarpamp]

> Search "BasUSB"

typo, "BadUSB".
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Is there a way to use internet in a sandbox environment? (Linux)

[grarpamp]

On 3/29/19, npdflr  wrote:
> I am giving a scenario: (Devices: PC Hard Disk having important files for
> offline use, USB Device for data transfer and Mobile Device which has
> internet connection)
>
> 1. I have a hard disk that is offline (Linux OS).
> 2. I use a mobile device for internet, gather some data and transfer that to
> a usb device (via OTG).
> 3. I have to mount the usb device to the hard disk since I need the gathered
> data.
> 4. Give read and write permission to the usb.
> 5. I copy the gathered data from usb to the hard disk. Use/process the data
> as per needs.
> 6. I write some data back to the usb if needed.
> 7. Connect usb to the mobile device if needed.
>
> Data from mobile --> usb --> Hard disk
> Data from Hard disk --> usb --> Mobile
>
> How do I make sure that only the hard disk can read and write to the usb
> device and prevent the usb to read/write any hard disk data so that the
> files on the hard disk are always safe?

Search "BasUSB", "HDDHack", etc.

Excepting the direct hardware to hardware hacks
that bypass the OS entirely, such as read write
address space via hardware interfaces (firewire, pci-usb, etc),
the latest memory and cache exploits etc, perhaps put or left
in the HW by spies since there are no...

#OpenFabs , #OpenHW , #OpenSW , #OpenDev , #OpenBiz , #OpenAudits , etc

to help improve and defeat that...


Today's kernels still don't provide any sort of storage
block device command firmware update opcode filtering
that could help prevent implantation of firmware exploits.

Many OS still allow unpriviledged users raw access
to portable devices.

Then filesystem hierarchy access control schemes,
and install and boot infrastructures, are also cumbersome
or impossible to protect from user, root, or physical level access.

To the extent CD-R, DVD-R, and tape "specifications"
are just blocks with no firmware being plugged across
the gap, and if no "media updates firmware" capabilities,
those, or even serial and parallel port transfers, could be
more secure than USB.

But since it's not open, you never really know.

People need to start doing those #Open*
things above before they can start to have
even the slightest bit of trust in systems.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] tor project website change

[grarpamp]

On 3/28/19, dns1...@riseup.net  wrote:
> I think you are affected by cognitive bias.

Tor is effected by lack of external thought.

> You are blindly looking only for bad things.

Your adversaries are assuredly looking at those things and more.
If you are not looking at them, you're done in mate.

> Of course the network is not perfect, but is the best we have

That's apologist talk to avoid clean slate researching
and creating better architectures, even to the
then at that point possibly legit point of being
able to actually make that declaration.

> and we should make our best to improve it.

Tor is and will always be 20 year old architecture
from time before current adversary models were
say matured if not known. Tor's relatively
simple and effectively static with only marginal
improvements left. And has outright traded off
and/or discarded design models that others
might not today.  (And obviously Tor arch cannot
be substantially changed while still calling itself Tor.)

Before declaring Tor sufficient against today threats
you need to analyse it against today threats
vs new networks being research and deploy
against today threats.

> trying to delegitimate everything.

Those concerned with messengers vs
messages are prone to miss some dead canaries.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] tor project website change

[grarpamp]

"
torproject.org frontpage
"


"
DEFEND AGAINST SURVEILLANCE
Tor Browser prevents someone watching your connection from knowing
what websites you visit. All anyone monitoring your browsing habits
can see is that you're using Tor.
"

This is false [1], and intentionally preloaded
with [use case and definitional] weasel words [2].

[1] See whitepapers, discussion, G and NGO Sybil,
and NSA's own statements.

[2] See Tor Project Incorporated's PR and Legal departments.


"
The network is comprised of thousands of volunteer-run servers known
as Tor relays.
"

And of endless numbers of more funded adversaries.

Yet there is still no social or other analysis
project of node meta information, providing
subscribable trust options, years after routinely
posting on need for same to help reduce that.


"
Your traffic is ... encrypted three times
"

Straight into lucky Sybil's decrypTOR and logfiles.
Sue me for [ab]use of trademarked substrings.


"
Tor aims to make all users look the same
"

s/Tor/Tor Browser/


"
cookies automatically clear
"

Was TLS clearing ever implemented (to be fair, perhaps yes by now)?
Etc for other state machines between restarts.


"
BROWSE FREELY
"

Except services which block tor, most of which
are embarrasingly braindead and/or cheap and/or
drinking their own said departmental, or anti-freedom
geopolitical, coolaid.


"
a 501(c)3 US nonprofit.
"

With rather curious amounts of potentially highly
user adversarial funding sources.


"technologies"

Singular: tor.




But purple onions on phones are more cute
and fun than word parsing disclaimers, right?

Happy browsing ;)
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] Massive Darknet Bust: Global JCODE SaboTor OPs Reap 65ppl $10M, DreamMarket Exits Under Mystery

[grarpamp]

https://www.zdnet.com/article/top-dark-web-marketplace-will-shut-down-next-month/

https://www.europol.europa.eu/newsroom/news/global-law-enforcement-action-against-vendors-and-buyers-dark-web
https://www.fbi.gov/news/stories/j-code-operation-sabotor-032619
https://www.dea.gov/press-releases/2019/03/26/j-code-announces-61-arrests-its-second-coordinated-law-enforcement

"The timing of the four announcements immediately sent most of Dream
Market's users and dark web threat intel analysts into a frenzy of
theories that law enforcement might have already seized the site and
are now running a honeypot operation. Their fears are based on a
similar event from June 2017 when Dutch police took over the Hansa
Market and ran the site for a month while collecting evidence on the
portal's users."

https://yro.slashdot.org/story/17/07/20/2028238/authorities-take-down-hansa-dark-web-market-confirm-alphabay-takedown

https://www.reddit.com/r/darknet/comments/b3qvbq/this_ddos_is_massive_its_gotta_be_multiple/ej1jwzc/

https://www.deepdotweb.com/
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] [OT] Smartphone purchase advice?

[grarpamp]

> Secure laptop advice? / Smartphone purchase advice ?

Obviously buy only unlocked carrier independant phones
cash upfront no financing, fuck the carriers. Bonus is they
won't come preloaded with carrier blingware, only
manufacturer blingware.

Most of the manufacturer warez can be avoided with...

https://en.wikipedia.org/wiki/Android_One
http://www.android.com/one/

You can also customise, compile and emulate test
Android OS. Strip out the entire Google app suite,
search, play, tunes, all the useless apps, spy, network
and battery eaters, background daemons, all gone.
Set your own security defaults in ROM, etc...

https://source.android.com/
https://www.xda-developers.com/

GPS chip / antenna / pwb traces can be physically
disabled, same for camera, microphone.

Learn on freebie recycled phones before hacking
on your Librem, Purisim, or whatever.

Still doesn't solve the baseband HW backdoor issue.
For that today you'd need VOIP number provider via
WiFi via cellular hotspot, or an OpenBTS etc SDR setup.

Intel is a top secret behemoth, so AMD should be preferred
by default just for competition sake while #OpenHW rolls.

There's somewhat more open Power9 platforms...

https://www.raptorcs.com/TALOSII/

Plus all the ARM and random *boards HW out there,
most of which isn't truly open.

At least don't buy WinTel systems.



Today you can also easily startup and adopt...

#OpenFabs , #OpenHW , #OpenSW , #OpenDev , #OpenBiz , #OpenAudits , etc
#CryptoCurrency

So far it seems no one's minds are deprogrammed
redpilled and free enough to actually imagine and
come together to initiate that FTW, so all we still see
for decades is same dumbass questions...

- What untrusted CPU / Laptop / Phone / Gear to buy?
- Give me Fiat

Which is nothing more than kissing your master's ass.
They love that.

The first to market with verifiable trustworthy #OpenHW
made in #OpenFabs will make immense profits from sectors
that need that assurance.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] Chelsea Manning jailed for refusing to testify on Wikileaks

[grarpamp]

Repost from 8 Mar:
> https://twitter.com/xychelsea
> https://twitter.com/resistschelsea
> https://twitter.com/wikileaks
> https://collateralmurder.wikileaks.org/
>
> Free Chelsea.
>
> Wake up.
> End this State of affairs worldwide.

Direct coverage...
https://www.youtube.com/watch?v=DZ_lOXIoFKI
https://www.youtube.com/watch?v=VBE1wxca8eM
https://www.youtube.com/watch?v=aKj_i4lCfs8
https://www.youtube.com/results?search_query=chelsea+manning

RuptlyTV was there too.
Beware mainstream media that does not
let you hear and see her own words and that
of others.

Some of her words...
https://www.youtube.com/watch?v=XAeSJEemjHk
https://www.youtube.com/watch?v=lYFP7-zb6J4
https://www.youtube.com/watch?v=1hC6ojvH9Us
https://www.youtube.com/watch?v=l_g2WjE2Ifo
https://www.youtube.com/watch?v=CBxfyqS8LGM


[Relavant re some leaks are known to use
privacy tools including tor. News for analysis
in ongoing debate.]
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Tor to become illegal in Europe?

[grarpamp]

On 3/11/19, hi...@safe-mail.net  wrote:
> They're basically talking about eliminating criminal activities facilitated
> online by the darknet, by making Tor and the dark web illegal and
> inaccessible
> in Europe. It was also stated that most of those who access the dark web are
> actual or potential criminals who need to be stopped before they harm
> anyone,
> and that the disadvantages of the darknet are much more than the advantages.
>
> https://www.heise.de/newsticker/meldung/Europaeischer-Polizeikongress-Weg-mit-dem-Darknet-4313276.html

> Could this be the beginning of the end?

If you're not running for Political Office in Germany, yes it is.
Same goes for any other country, including the USA.
Until then, they will simply overrule you and not give
a shit about your pithy little sign waving protests, wannabe
online activism, and low dollar lobbying... you're deleted,
you're not really competition they have to care about.
Re-educating the public masses out from under childhood
indoctrination is a decades slow process, infiltrating your self / agenda
into Office is much faster... witness them doing it every election cycle ;)
Or you could try in the open like Free State Project / Pirate Party.
When Facebook, Google, Governments and whatever other
anti-privacy surveillors data brokers/miners, spies, control
force freaks, taxing thieves for war torture murder... go bankrupt,
you win. Win you open multiple fronts, writing and/or vetoing
laws to help do it, it'll happen a bit faster... if you're actually
not, or don't become, one of them... which is rare... as no
revolution in history has ever lasted... yet.


"
European Police Congress: Away with the Darknet

At the European Police Congress in Berlin, a ban on Darknets in free
democratic states was called for.

To start on one's own behalf is supposedly bad style. But this note is
necessary this time: heise online operates since 2016, the hot
tipster, which is accessible, inter alia, via Tor and whistleblowers a
secure contact address in this "Darknet" allows, which was used
several times.

No room for Tor

If the current federal government decides, then this may be a criminal
offense in the future. At the opening of the 22nd European Police
Congress in Berlin, Günter Krings, Parliamentary State Secretary in
the Federal Ministry of the Interior, demanded a radical ban on Tor:
"I understand why the Darknet can be of use in autocratic systems, but
in a free, open democracy, I think for no legitimate benefits, those
who use the Darknet are usually up to no good, and this simple
realization should also be reflected in our legal system. "

The needs of whistleblowers have no place in the world view of Krings,
which demanded a second IT security law, which should be implemented
later this year. In the remainder of his speech, the CDU politician
was primarily concerned with the SPD-led Ministry of Justice, which in
his view, the propagated pact for the rule of law systematically
undermines and delays. It would have long been possible to settle the
question of what should happen to German jihad fighters who want to
get rid of Kurds and Syrians, said the State Secretary. However,
Krings praised the tool RADAR-iTE, which reliably identifies and
classifies Islamists on a three-level scale.

Krings was followed in the opening ceremony by Wolfgang Sobotka,
President of the Austrian National Council. He praised China for not
having any inhibitions and successfully ignoring data protection when
analyzing citizens. His statement that there is a human right to
political asylum, but no human right to asylum for economic or social
reasons, fit into the picture he drew.

European Border Patrol
...
"
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] v3 Onion Services that host Mixmaster SMTP Nodes

[grarpamp]

> Interesting, How could you tell?

Same as any other service, try it.

> What node is this?

Best confirm with them.

bshc44ac76q3kskw.onion
is also up

> This is precisely why we need them because direct clearnet access in
> Whonix is not an option.

Using whonix is a local and reasonable choice, and a separate
factor from the former operational situation of tor or clearnet.

> I'm not interested in webmail or s services where you need to register
> to use. They are also a single point of surveillance/failure.

There are those central kind. And though not public services,
there are also lots of p2p (user to user) smtp onions. Plus a
number of non email messaging systems and protocols,
some distributed. Even this old protocol...
http://top1000.anthologeek.net/

> The point is, many of them have pinger stat pages and I was wondering if
> there are some you know of that list an Onion as alternative access on
> their project sites.

Search and read / inquire of them, maybe more
of them will offer multihoming on the overlay networks.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] v3 Onion Services that host Mixmaster SMTP Nodes

[grarpamp]

On 2/3/19, procmem  wrote:
> Does anyone know of Mixmaster remailers that are hosted on v3 onions?

Search for and survey known remailers.
Maybe some will offer it as result.

> The ones we currently have listed in Whonix are:

> k54ids7luh523dbi.onion

down

> gbhpq7eihle4btsn.onion

up, and exists on clearnet

> v2 will be EOL at some point soon.

The mixmaster nodes that multihome with clearnet all
exist publicly, thus they have no explicit need for v3
anti hsdir trolling feature, or much else of v3, especially
since you're supposd to PGP and crypto over any
clearnet native protocols, such as email, anyways.

Onion for mixmaster, regardless of v2 or v3, is useful
simply for... the direct tor tunnel to server, and since many
exits do not support email ports, and or the clearnet path
is subject to smtp censorship.

There are *many* p2p v2 and v3 onion mail systems.

v2 onions will not be going away or EOL anytime soon.
In part due to needed features and capabilities of v2
not being present in v3 or vN (some of which have
recently again been noted on this list), and other tradeoffs
acceptable to the knowledgeable user, including unwieldy
string length of onion, etc. v3 is good and welcome
improvement for those who need it. Yet it's really and properly
ultimately up to the third party users and service operators as
to which onion versions they elect to use, not Torproject Inc, et al.

> None of these have public pages that can inform users of upcoming
> changes or developments.

They don't have to. Unless you're a statist control freak
who just has to know the human identity # behind every IP
and service on the net.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] [Cryptography] Implementing full Internet IPv6 end-to-end encryption based on Cryptographically Generated Address

[grarpamp]

On 1/24/19, Alec Muffett  wrote:
> On Thu, 24 Jan 2019 at 19:33, grarpamp  wrote:
>
>> As readers may be aware,
>> Tor has an interesting capability via OnionCat and OnionVPN
>> ...
>> There's an open project for anyone who wants it...
>> To bring IPv6 over v3 onions to Tor.

> I'm wondering: could you please expand upon how this compares in importance
> to simply promoting the native adoption of Tor v3 Onion Networking, amongst
> the community of tool-developers and tool-users whom you envision the above
> solution (OnionCat/OnionVPN/IP-routing) benefitting?

As before, yes v3 is a great update, useful for many, even indeed
properly set for users by default. But not for all users, as some may
explicitly choose to trade features of one version, say v3, for long
term capabilities still needed from, or only present for the future
in, another version, say v2.

v3 should be "promoted", yet that shouldn't be at expense
or exclusive to anything else, nor should anything else be
diminishing to it. Modularity works there.

And since v3 is now the default, the low cost work
of "promoting" it is now more or less done.

So perhaps v3 can be set aside on its own for now
to consider what "native" might mean in larger context...

Killing v2, while at the same time not working on porting the
curious IPv6 feature to vN, would be a foot shooting regression
upon the future. While easy way out for some to propose,
it's probably not the right approach.

Maybe yes it's about tool devs and users... about apps...
how to see folks using crypto privacy currency overlays
messaging etc, more or less seamlessly, being protected
from surveillance and censorship and enjoying free speech,
scalable production class networks... do you...

a) Wait forever until some critical number or combination
of overlay networks and new apps, necessarily specifically
exclusively and natively written for those nets alone...
is reached, having mass effect at that point...

or

b) Try to provide extension API's for your overlay of the
year that works with whatever apps people are already using
today, and provide interop API's between overlays, until some
overlays prove resistant enough for general usage tomorrow.
(Recall that tor still emits an adversary warning on startup
and has entire classes of unsolved weaknesses, as
with any other overlay today.)

Or elements of both and add win from both ends.
Or something else or more.

Historically, most overlays have failed at (a) because
native never widely happened, and because of failing
at (b), along with not yet having sufficient attack resistance,
and plain old tunnel vision competition in narrow and
easier fields (say delivering a message)... perhaps are
missing out on some adoption wins in areas where they
are actually suitable enough.

IPv6 is a potential already "native" area here...
Pick any list of "end user" or "server" applications, generally
any IP capable thing out there that people plug into the internet
(these days most everything is becoming IPv6 capable so let's
just forget about IPv4). Well, the millions of apps out there all
speak IP, and do not speak end to end bidirectional onion or i2p
or anything else, let alone ride on or utilize any auth or uniqueness
expectations therein.
Yes, various LD_PRELOAD and packet filter torifying methods
covers some things as a hack.
However the problem is most apparent with apps that include
addressing info in their data not just use it only for binding
the network stack. Or that use anything other than TCP.
Or that need to route, P2P, DHT, etc. Features break or the app
simply won't work. Bittorrent is one such very popular application,
many more exist, or could exist. Many of which might
need to make use of addressing in data to scale, or UDP
for efficiency or mixing.

Further, trying to plug apps into these overlays is complex and
thereby offputting and risky for all but expert users and admins.

Now if you had some simple range of IPv6 for them to bind
to and filter, or even an AF_WIDE, that becomes a lot easier
to adopt and manage as well.

And of course AF_WIDE, or AF_OVERLAY, though it would
require code in all apps, would be a third party supportable
modular library once plugged in as a compile option to the
thousands of popular apps out there.

Engineer something like that and magic starts to happen.

Or since IPv6, crypto, networks, apps, etc are decades old
now, gather todays knowledge for a try at starting from the
top again.

Perhaps a larger aspect is... everyone in the space should probably
be thinking about these things. Are these tools and overlays
just some ad-hoc complex limited usage highly optimized things
for geeks, activists, particular communities, etc? 100k's of users
or less with very limited interop capabilities.
Or is something larger and more important being built?
500M+'s of users, new RFC's and hardware level everywhe

Re: [tor-talk] [Cryptography] Implementing full Internet IPv6 end-to-end encryption based on Cryptographically Generated Address

[grarpamp]

On 1/24/19, Christian Huitema  wrote:
> If you want real integration with IPv6 addressing, the crypto systems
> can really only use 64 bits. The top 64 bits are claimed by the routing
> system, and the network providers just won't let you put something
> arbitrary there. That's a big issue, because if your cryptographic proof
> of ownership relies on matching 64 bits, then it is not much of a proof.

Depends on if and to what extent one needs or wishes to speak
to the clearnet hardware that currently exists...

"
Yes, one cannot rationally overload all 128 bits for that without colliding
upon allocated IPv6 space that may appear in one's host stack.
However the 1:1 key network can be larger than 64 or 80 bit. One could
easily play with up to say 125 bits by squatting on entirely
unallocated space. (Unlike the clear mistake CJDNS made by
squatting on space already allocated for a specific and conflicting
real world in stack purpose.) Obviously the common library widths
of 96 and 112 could be keyed. And request could be made for a
formal allocation if compatibility and compliance was felt needed
by some mental gymnastics.

https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml
https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml
https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml
"

Agreed, going from say 64 to 125 bits is not the huge or
universally strong and ideal leap that could be sought for.

And there is the question of secure levels and offloading
(or onboarding as it may be)... at what level would many
users perhaps choose to share their cat pictures...
64, 80, 120, 512? And their finances, affairs, work, email?
Were a slider to exist, where would offloading bulk traffic,
of any given content or purpose, end up being set, and
start to occur? How would you run each as needed?

Do you need a future 8192-bit IPvN in backbone routers
and host stacks to achieve certain strengths and utility
goals? Or can you do it some other way?


> The CGA specification (RFC 3972) tried to mitigate that by introducing
> the "SEC" field. It tries to make the proof harder by specifying a
> number of matching zeroes. There is a tradeoff there. We wanted to
> encode the number of zeroes in the address itself: we feared that doing
> otherwise would make address spoofing too easy. But we were also worried
> about birthday paradox issues. Each bit allocated to the SEC field is
> one fewer bit available to differentiate the addresses of hosts on the
> same network. The compromise was to pick a 16 bit granularity.
> ...

For reference...
https://tools.ietf.org/html/rfc3972

> ...
> Bottom line, back in 2005 we had high hopes that CGA would enable all
> kinds of security improvements, be it end-to-end IPSEC or secure IP
> Mobility. That did not happen, and hardly anybody uses CGA today. Lots
> of the work was done at Microsoft Research, but Microsoft never found a
> real reason to deploy CGA in Windows. The real reason is that 64 bits is
> too small for crypto.


ORCHIDv2 is also commonly noted...

https://tools.ietf.org/html/rfc7343

An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers
Version 2 (ORCHIDv2)

   This document specifies an updated Overlay Routable Cryptographic
   Hash Identifiers (ORCHID) format that obsoletes that in RFC 4843.
   These identifiers are intended to be used as endpoint identifiers at
   applications and Application Programming Interfaces (APIs) and not as
   identifiers for network location at the IP layer, i.e., locators.
   They are designed to appear as application-layer entities and at the
   existing IPv6 APIs, but they should not appear in actual IPv6
   headers.  To make them more like regular IPv6 addresses, they are
   expected to be routable at an overlay level.  Consequently, while
   they are considered non-routable addresses from the IPv6-layer
   perspective, all existing IPv6 applications are expected to be able
   to use them in a manner compatible with current IPv6 addresses.

   The Overlay Routable Cryptographic Hash Identifiers originally
   defined in RFC 4843 lacked a mechanism for cryptographic algorithm
   agility.  The updated ORCHID format specified in this document
   removes this limitation by encoding, in the identifier itself, an
   index to the suite of cryptographic algorithms in use.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] [Cryptography] Implementing full Internet IPv6 end-to-end encryption based on Cryptographically Generated Address

[grarpamp]

>>> > When we communicate with strangers, we can use the following
>>> > handshaking protocol.
>>>
>>> So here, you only accomplish confidentiality toa stranger. But you
>>> have no idea which stranger.
>
>> This is to achieve end-to-end encryption without CA.
>>
>> Prove a specific identity with a specific IPv6 address.
>
> You miss the point. Talking with confidentiality to an IP address means
> nothing.
> Using null-authentication with any protocol accomplishes the same. You
> left out how binding that IP address to a psuedo identity would work.
>
> If I talk with confidentiality with 2600::c900:9106:adca:dc36 then who
> am I talking to? You ? Your server? Your phone? The NSA?
>
> Besides that, anyone who controls some of the BGP tables or routing
> can be an instance of 2600::c900:9106:adca:dc36 passing identification
> of your crypto scheme. So I don't even know if I am talking to the "real"
> 2600::c900:9106:adca:dc36. And if you meant the IPv6 as a "shared
> secret" then we have better methods like PAKE to go from a weak shared
> secret we exchange at a party, to a strong secret we can use to
> authenticate a private channel.
>
> In other words, your proposal is the equivalent to any kind of
> DiffieHellman key exchange. Now you have confidentiality, you need
> to authenticate the other party.

As readers may be aware,

Tor has an interesting capability via OnionCat and OnionVPN
to join its 80-bits of v2 onion addressing with the IPv6/48
bits provided by the latter tools to yield a self authenticating
128-bit host and internet stack compatible private space.
This brings IPv6 (UDP, ICMP, all its applications, etc) to
the Tor overlay.

Tor breaks that with its v3 onions which are much wider.
As does I2P. And of course CJDNS isn't exctly interop
friendly.

There's an open project for anyone who wants it...

To bring IPv6 over v3 onions to Tor.
The results of which... that being how to provision roughly
approaching 128-bits of stack compatible reasonably E2E
self or otherwise authenticated space out from any wider
space... would be useful to many of the existing and future
overlay networks out there, to bring instant compatibilty
of those nets with all of users IPv6 apps.

Could be anything from a DHT first seen, to an in network
blockchain registry, to an entirely new modular AF_WIDE
compilation library option which could pluggably open up
a lot of overlay networks to general application usage.

See tor-talk list archives and I2P dev for more
talk on the potential project.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Detective Conan Japanese Cartoon Advertising Tor For Criminal Activity

[grarpamp]

> * To watch the Full Movie
> https://kissanime.ac/Anime/Detective-Conan-Movie-22-Zero-The-Enforcer-Sub.77113/Movie?id=148813=oserver

infohash:B0C52F853E125A5C6D793496BF5BAE38798F91C7
infohash:D063F882ABD1DF844102B7336DB13D2A91B639BE
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] [tor-relays] Onion v2 HSDir Support (ref: v3 prop224) [was: fishy fingerprint patterns]

[grarpamp]

On 1/4/19, V  wrote:
> "crypto" "security" "sofware dev" "support" fud re v2

"Hey, here's v2, it uses older crypto and mechanics that
are not as robust etc as v3... However v2 offers useful features
for many users, and those features are not yet available in a
newer design (volunteers to create some designs welcomed).
As such, v2 received a last and final major formal update, and
a backport from v3 concepts, was crafted into a more maintainable
modular form, and has now been set out for community maintenance
(maintainers welcomed). v3 has been set as default.
Users will need to explicitly configure older versions as needed.
Volunteer relay operators offer v2 HSDir flag to support users.
Here is a table that fully compares and contrasts v2 vs v3
so that users may choose which best suits their needs...
And here are roadmaps for v3 and vN ..."

"Please remember before going for a walk... you could trip
up your own laces, your shoes could fall apart, you could
be mugged, it could even rain, thus walk at your own risk,
or stay inside, or just have fun."

This isn't hard, everyone happy.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] [tor-relays] Onion v2 HSDir Support (ref: v3 prop224) [was: fishy fingerprint patterns]

[grarpamp]

On 1/4/19, teor  wrote:
>> Node operators (tor-relays) would continue offering
>> v2 HSDir support module until such time as the reasons
>> for choosing v2 by those above are supported in v3 or vN.
>
> It's not just about feature parity.

Right. Feature parity is nice and excellent goal, till
then, and with *no* plan for same on horizon table,
it's about outright removal and killing of long
standing features instead of rightly letting users
choose from among all features to suit their needs.

Killing "..exit" in URI's raised some questions,
and using MAPADDRESS was the nearly functionally
equivalent alternative existing / provided. All good.

Killing v2... whose 80-bit addressing just so happens
to enable appending to an RFC4193 /48 to create
a 128-bit IPv6 space allocation with its inherent UDP all
provided by way of Onioncat and OnionVPN over v2 onions
and v2 HSDir nodes... would rip out accessibility to
***entire classes of transport protocols*** that users,
and their applications, around the world, need to function
properly, and can and do use.

With the main arguments revolving that users are too
stupid to select which of v2 or v3 best suits their needs,
that v2's benefits have no acceptable tradeoffs for them,
etc.

That argument should be rejected.

As should others...

> Maintaining a reasonable level of security for v2 onion services
> requires a lot of paid and volunteer time. We need to find bad
> relays, and block them on directory authorities.

Not really.

v2 onion in it's current form has been more
or less coded, done and operational for ~20 years,
minus occaisional bug and enhancement phases.

People have already explained in recent threads how,
after the default out of the box mode for all *new* users
is changed to v3 onions, those with need to use v2 onions
can and will happily explicitly choose v2 and it's tradeoffs,
manually in configs, to support their needs. Those tradeoffs
should be documented onsite and in v2 man sections.

Tor could even make some future release flag,
complain about, and not load any current v2 config
it detecs, directing them to such handholding docs
until they specify "V2YesMommyImABigKidNow=true".

As far as money goes, the Tor Project takes in
$4.2 Million a year. Some of it's people are taking
over $178k a piece, with at least 7 of them receiving
over $100k, and the true volunteers eschewing all.
Those numbers don't include all the slush, side and
decentral funding either.

Where's the 210 coders and others receiving $10k
stipends for half the budget? Where's the open budget
and mechanism? People do inquire this from time to time.

People can start another Subject to comparatively
analyse Tor Project alongside other opensource
network overlays and cryptographic comms projects,
and even other opensource projects in general.

Even start Subjects where other projects could include, remove,
or improve on whatever strategy Tor did to reach $4.2M.

There's no lack of funds in Tor Project.

> If we spend a lot of time blocking relays, we can't spend that
> time on improving other areas of the tor network.

Let's define this "blocking" as being of v2 HSDir scraping,
not of all the other forms of bad relays. Community volunteers
run the public opensource automated scrape detection and
reporting tools. The weekly config change volunteer DA's
execute based on that is trivial effort. With a bit of logic
it's even automateable.

Yet as above, v2 users do and will soon *explicitly* choose
and accept those tradeoffs. So that's a non argument too.


> v2 onion services also add a significant amount of load to the
> Tor network. They use older, inefficient crypto, and they are

No. v2 is not some new network tax that just came alone, it's the
first mass version and the entire base of onionland. Load is a ratio.
v2 used to carry 100% of the load since then, and still carries
over 90%. Some crypto is HW accel, some not, in both v2 and v3.
And if that was a metric'd and studied issue, even other 80-bit
algos could be chosen in some long term v2 support release.

> often targeted by scanners.

No again. Let's define what "scanners" might mean...
Land of v2 and v3 are equally web spidered 24x365, it's HTML, no one
can stop that. Known v3 onions are portscanned just as much as
v2 onions are. If "scanning" means "searching for key collisions
by generating offline", both v2 and v3 are reasonably collision proof to
make that nearly moot. And "scanners" testing generated key lists
for HSDir resolve or TCP connect on the live network will learn in
one day that there is absolutely zero hope there. So that's all moot.

For separate topic of v2 HSDir "scraping" see above.

> If we spend a lot of network resources on v2 onion services,
> then we can't use those resources for more efficient, user-focused
> traffic.

No. Users have reasons to use, and do and will continue to
select and use v2, even if they have to fork tor. v2 is "used"
by "users" and is thus "user-focused" traffic by 

Re: [tor-talk] Status of Torrent on Onion in 2019

[grarpamp]

On 1/1/19, Fabio Pietrosanti (naif) - lists  wrote:
> i'm supporting with some technical analysis a volounteer-non-profit
> collaborative torrent forum/site with their future-looking upgrades of
> infrastructure.
>
> I would love them to bring all their public forum

That's just webwork.

> and public tracker on Onion,
> while exporting their +160k releases database as open-data so
> that Torrent Search sites and Torrent Software with incorporated Torrent
> Search could use it.

There are probably lots of ways out there.
Even maybe something like "getstrike" and "strike-search" API.

> My question is about the status of uses of Torrent on Onion,
> not for "content downloading" but for index tracking:

"index tracking" seems a nonsensical mashup.
Though one might say something like "publishing
realtime torrent scrape info from trackers on index sites".

Definitions...

Index - Stupid forums where users publish descriptions for their infohash'es
aka: torrent files, the scene. Rarely do centralized indexes use efficient
plaintext search and insert interfaces instead of blingy forums and risk.

Tracker - Leet tech that clients connect to to find nodes by infohash,
ie: DHT, PEX, OpenTracker

Client - transmission-bt, vuze, etc

Protected - All traffic stays entirely within the overlay network.
Exit - Some or all traffic may "exit" to clearnet

> - Are there stable / long term Torrent Trackers running on Onion Addresses?

Yes, and i2p etc too. Yet trackers are just bittorrent tech.
So there are plenty of indexes as well.
Most of the indexes are multihomed from clearnet,
some exist only in the overlays.

> - How many Torrent Software natively do support
> Tor and Onion Addresses,
> only for Trackers

Assuming you're using tor+onioncat p2p v2 onions with v2 HSDir
support, that yields ability to transport UDP over IPv6 over tor
(many bittorrent protocols use or require UDP)...

Thus all clients that support IPV6 can work
over "Tor and Onion Addresses".

Native .onion support (TCP only, no IP) is not as simple.
Nor is split horizon exit or full exit.
Same for trying to get TOR space to interop with I2P
space or CJDNS space, client multihoming, etc.

> (not for content-download-upload-exchange)?

This is moot as typical users don't run their
clients just look at the scrape, they do it to
seed and leech.

Which of course they can do 24x365 over both
tor and i2p, and other overlay networks.

And due to rampant censorship and loss of free speech
on clearnet they are doing it more and more.

See all the recent bans by Youtube, Facebook, Twitter,
etc etc etc.

The overlays are now the only reasonably safe
spaces for free speech to thrive. That's sad.

Users may also want to look at DTube, IPFS,
Brave Browser, BitChute Webtorrent, lists of p2p
apps and overlay networks, distributed file sharing
and storage, blockchain and cryptocurrency, etc
for other ideas and things to read and try.

Lots of new protected overlay networks and apps are
now online, and more will be coming in the years ahead.
Things are changing fast. Plug in and have fun :)


https://en.wikipedia.org/wiki/Bittorrent
https://en.wikipedia.org/wiki/Vuze
https://en.wikipedia.org/wiki/Transmission_(BitTorrent_client)
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Abuse complaint 418289

[grarpamp]

> Port 22 is ssh, so turning it off would mean your relay won't be the exit
> point for helping people reach their ssh servers while protecting their
> communications metadata. Exiting to port 22 is a helpful thing to do

Yes.

> Port 465 is for secure mail delivery,
> which probably doesn't work so well over Tor these days anyway.

There are some onion services and nodes that directly deliver
outbound via exits to clearnet destinations. They tend to
be unreliable for obvious reasons of today's spam preventions.

Other implementations of Tor mail services rent a frontend
domain and clearnet shell, tunnel the Tor mail to that point
on clearnet via onion or exit, and deliver it on to clearnet
destinations from there. That model does not need 465.

Unfortunately there is some legacy mashup for sending mail,
regarding server and users use of "smtp" 25 and "smtps" 465,
and variously plaintext or tls or starttls on top of those ports.

Fortunately these days 25 and 465 hardly enable or
document for user use anymore.

> wonder what they meant by 576, and if it's a transcription error and
> they meant some other port (like 587).

Same here for 576.

587 is submission protocol, dedicated to authenticated users
sending mail smtp over starttls.

As with fetching pop3s 995 and imaps 993, sending submission 587
is critical for use with users mail clients.

pop3s 995 and imaps 993 are not any nuisance at all.
submission 587 could be spammy but gets account nuked quickly.
ssh 22 is just internet scanning noise with occaisional crack.

You could negotiate away 567 for free.
See about discussing proportion of 22 noise coming from exit
versus clearnet, and the huge legit use it has.
And keep the three mail client ports as equally legit.

You could also analyse all the exits in consensus
to see which ports are at risk of not having enough
exit support and thus might be more needed.
And publish your analysis project results.

Since you operate exits, you might want to join
tor-rel...@lists.torproject.org
where all these things and more help are in the archives.
ttps://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

And there are wiki.torproject.org pages to list
results of searches for ISP's.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] Onion v2 HSDir Support (ref: v3 prop224) [was: fishy fingerprint patterns]

[grarpamp]

> relays have a rather distinct signup and fingerprint pattern
> usually seen for onion attacks.
> ...
> a) If you are an .onion operator I'd like to encourage you to switch to onion
> services version 3
> ...
> so we can start
> ...
> b) dropping onion version 2 services eventually.

These are two separate things not necessarily tied together,
thus split for clarity as above.

The former a) is up to the onion operator based on their needs.
If they have no need for v2, or need v3, they can or should
switch to v3, indeed.

The latter b) is a feature that some users and operators
in and for onionspace explicitly choose and depend on
to support common apps, and thus would definitely not
like to see yanked out from under them.
Better instead to advertise and update the default onion
semantics for [new] users to v3, and continue support
and backport doable features to v2 until time below...

Node operators (tor-relays) would continue offering
v2 HSDir support module until such time as the reasons
for choosing v2 by those above are supported in v3 or vN.

See the threads on this subject on tor-talk, tor-onions,
and tickets for more.

[CC for inclusion, move there if not relay specific]
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] circpathbias.c : Your Guard vs The Guard

[grarpamp]

> latest code base I see the string "Your Guard" recurring.
>
> Does this string actually refer to a Guard the user is responsible for
> operating and maintaining?

No, the "user" ie client doesn't "operate and maintain" any
type of node or guard by default.

> Or does it refer to the guard the Tor client
> is connecting to on its first hop in the circuit?

Yes.

> perhaps the string
> ought to read "The Guard" instead of "Your Guard".

Many projects prefer bad strings perpetuate
legacy than fix them for future.

You'll have to wait other replies or open ticket to find out which.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] What happens when an .onion site is compromised?

[grarpamp]

> Imagine that an .onion site is compromised. This could be by the owner who
> wishes to expose visitors or by the police who want to target the
> clientele.

> How would it
> be possible for a visitor to be in danger?

Other posts covered technical code exploits.

Other risks are trust changes... social engineering
users, cute quizzes to fill out, metadata analysis
that any formerly legit owner wasn't doing,
accounts popping up, etc, etc... typical psych
stuff that traps and users dox themselves.

A lot of that is covered on any of the onion forums,
even some /r/onions and deepdotweb, etc.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Most Security Assertions Dangerous [Re: YouTube via Onion Services]

[grarpamp]

> Tutanota open sourced their client. You could use the source and run your
> own version of the Tutanota client if that's your threat model. It's true
> the email provider could serve different users different versions of the app
> and there is no possible way to audit it in real time

A standalone app can give at least some distance and pinnable code.
And a bit more if served up from a "neutral" third party like github,
f-droid, or allowing tor or vpn to get it in some masked user fashion.


> 2) You are running unknown code every day. Do you trust the vendors?

Probably not wise until the world changes some more
towards those hashtags. Shall we add #SharedAudit .


> It's unfair [...] They're trying to
> solve a complicated problem, inside a web browser, with no easy solution :-/

Yes of course, they're at least trying something new,
that's important, so kudos.

> It's unfair [...] to call [out] encrypted email providers

But is it... just look at most of their own front page
advertising statements that often go like...

"Secure Encrypted Email in your Browser"

Without weasel words, those statements can end up
being fake.

Does what net benefit the service may have for [most] users
offset potential damage arising from such statements?

There's a bunch of front page statements here too
that also have more holes than a block of Swiss Cheese...

https://www.torproject.org/

Who is parsing and calling them out, and or proffering
page updates that use suitably accurate weasel words?

> inside a web browser, with no easy solution :-/

If the world is still stupidly insisting on the derelict spy exploited
relic of SMTP transport, instead of say fully encrypted P2P
overlay transports with legacy SMTP / POP / IMAP frontends
for the old timey feels, they should at least be directly extending
browser functionality to load and exec user selected third party
provided and fourth party audited message crypting code modules
from local disk.

Or should be using actual properly stood at a distance
tools like GPG, Enigmail, Mailpile, NeoMutt, whatever,
while replacement distributed P2P messaging and storage
systems gain marketshare.

If user can locally compile and use Tutanota from Github
with no blobs, that's interesting, perhaps consider dropping
them some coin if so.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] comparison of Tor and Kovri in regards to deanonymization attacks

[grarpamp]

> instead of continuing to throw [government] money

Sorry, didn't mean to imply it was theirs...
https://www.youtube.com/results?search_query=taxation+is+theft

Carry on.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] comparison of Tor and Kovri in regards to deanonymization attacks

[grarpamp]

> - I2P can be attacked with far less resources than Tor;

Moot when $10k is probably enough to Sybil at least
some small fraction of either of them.

> - Tor is deeply researched and various attack types and problems have
> already been solved;

So if Tor is done, why don't you start writing grants to reseach,
advance, and solve some of the undone, equally applicable,
and necessary problem space of mixnets and other potential
designs, instead of continuing to throw [government] money
at Tor's curve of diminishing returns.

> - Tor is larger as a network with more capacity, and more diversity;

Start advertising, using, analysing other types of networks then.

> They also have different purposes so they cannot be directly compared on
> absolutely every feature

Why do so many reviews keep implying this copout,
"B network doesn't have X feature therefore B sucks"...
of course networks are different, unique features are
not detractions they're just incomparable items,
go compare and analyse the similar features then.

Both Tor and I2P generally claim their non-exit modes
to be anonymous advanced designs resistant to attack.
Go compare and analyze that. If you don't like the results,
go start new designs.

Reviews can even conform features... users can
actually torrent internally over both, and exit over
both... analyze that.

Many orthagonal features are modular ideas embeddable
in any decent network anyway, so they're not necessarily
unique, only a matter of doing it, if sensible of course.

> - I2P is more oriented for traffic inside the I2P network (e.g. you
> cannot browse cnn.com anonymously via I2P).

Yes you can, you just have to find or be an exit outproxy service
and configure it manually.

>> I would summaries the success of Tor over I2P with these points:

Government: Initialed the Tor design, put in Decades of $Millions
of controlling interest funding, and programmed Marketing.

Throw those kind of resources at I2P or any other network
and they would be relatively equal contenders too.

Throw Voluntary versions of those kinds of resources
at any network, and it might be a bit more novel and free
to go up against the backer of the "successful" one above.

>> - Tor has a modified browser which is a fork of firefox-esr called Tor
>> Browser Bundle which is easy to click and run with Tor. I2P until now
>> there is no official browser supporting it and user needs to do the
>> configurations manually.

So stuff I2P inside TBB's work and call it IBB.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] comparison of Tor and Kovri in regards to deanonymization attacks

[grarpamp]

>> I was curious for Monero dev's rationale to pick I2P over Tor
>> Whatever I've seen online doesn't strike me as particularly convincing.

Same could be asked of Zcash strong cryptographic ZKP style
currencies users often using Tor. As well as a handful of other
cryptocurrencies explicitly advertised and designed to use
with Tor.

>> Whatever I've seen online doesn't strike me as particularly convincing.

>> Is there published research in regards to deanonymization attacks against
>> both Tor and I2P

Some are here, some are in sites of other messaging systems...
https://www.freehaven.net/anonbib


All overlay networks currently in production are
massively vulnerable to at least two classes of attack
by sufficiently interested and capable adversaries...


1) Sybil
a) This requires people to actually use PKI to make and use
assertions and identities and to punt the results they get from
their deep social anal probing of each other in real life as
operator peers worldwide... into the consensus, DHT, or whatever
mechanism each network uses for node approval and selection.
b) Also requires complete ongoing analysis of all known physical
and logical metadata and behaviour of the nodes themselves.


2) Global Passive Monitoring
The US NSA, Global and Regional Telecom Corporations,
and other Entities Worldwide, acting both separately and
together, have a complete passive and active view of the
internet from at minimum the Global Tier-1 ISP Level,
including significant analysis and recording capabilities
therein.

Yet everyone still stupidly fails to execute at least a few of
the seemingly available and reasonable countermeasures...

a) Encrypt Everything.
Automatic, on by default, strong crypto suites, forward
secrecy, tofu, psk, rekeying, whatever works best, etc... both...
1) By and between end to end users, same for server to server...
2) On all physical network links worldwide, every port
automagic and independant... fiber, copper, radio, etc...
embedded in the network hardware itself via RFC, IEEE, etc

b) Deploy fulltime network fill traffic aka chaff, to fill the committed
capacity that each node provisioned itself into the [overlay]
network with, dynamically yielding room for and upon native traffic.
This applies both to, logical nets 2a1, and physical nets 2a2, above.

c) Politics, Anarchism, Cryptocurrency Crowdfunding, and
whatever else works to uproot and route around persistant
known bad actors.


3) Etc


Nobody seems to want to do much on the above, to actually
shape those into effective global project efforts, to deploy any
sufficient mitigation finally therein, therefore the vulnerabilities
shall remain.

#OpenFabs , #OpenHW , #OpenSW , #OpenDev , #OpenBiz , #CryptoCurrency
, #Anarchism , #SybilBusters , #EncryptEverything , #FillEverything
... the list gets longer.


Anyone can launch rockets these days.
So there is no reason any of the above and more can't be done.
Go build and launch some rockets.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] Most Security Assertions Dangerous [Re: YouTube via Onion Services]

[grarpamp]

In a thread...
https://lists.torproject.org/pipermail/tor-talk/2018-December/044709.html

on...
> http://kgg2m7yk5aybusll.onion/
> http://axqzx4s6s54s32yentfqojs3x5i7faxza6xo3ehd4bzzsg2ii4fv2iid.onion

(noting that all onions can be physically located by determined
adversaries, thus failing another commonly sold security assertion)

> https://github.com/omarroth/invidious


> - Its free software and the code is available for install/checkup.

That assertion is irrelevant in the security context
of the thread so far, and it's dangerous advice.

As with protonmail and all the other fakeass encrypted email
websites... the JS code is loaded by the browser from the web
service itself, there is currently NO trusted way for the user to
independantly audit that the code they end up executing in
real time *from* the service matches the code *in* any repo,
or for the user to choose to ignore the service code and load
and execute any repo code of their choosing instead.

> Youtube is made by a dick company to humanity called Google, which is
> funding their services by stealing/collecting users data. So the JS

The current code load model is a nasty exploit waiting to happen,
does happen (Hushmail, NIT's, etc), and simply should not be trusted,
no more than GOOG and FB the dicks, themselves, indeed.
Or Java, ActiveX, Flash, and whatever other "secure" crap some
scam tries to push into your pathetically insecure and
untrusted exec platform.

Sure Invidious Onion is fun, probably has some merits and
use cases, and even simple html could be an exploit, and
users can run it all in a sandbox, etc.
But let's not say there's any trusted link between the running
and repo codes, nor that any sufficient set of people have looked
at, and signed over, most codes, or are even allowed to... [1].

Also, clicking on any video listed on the onion frontpage
index initiates at least three connections straight to google
instead of the proxy onion. That's not clean.

> Plus you can watch the videos without the need to allow any JS.

> this particular YouTube frontend/proxy seems to be
> more focused on offering an alternative viewing experience rather than
> privacy.

https://github.com/mps-youtube/mps-youtube
https://github.com/rg3/youtube-dl

... those and a few others readers can find and post here.


[1] You can't even say those for the release iso's of
OpenBSD, FreeBSD, the Linux's, etc... back
to their claimed source code repos... because
either those repos have no internal cryptographic
roots or hashes to sign over or with in the first place,
or some process in the path from there to the iso's
is not reproducible or cryptographically chained.
Same goes for Apple, Microsoft, Intel, AMD, ARM,
Government, etc...
You're all still woefully fucked therein because you keep
buying the Kool-Aid, and refusing to demand, fix,
ignore, or eliminate them and their issues.

#OpenFabs , #OpenHW , #OpenSW , #OpenDev , #OpenBiz , #CryptoCurrency
, #Anarchism

The list of requisites to even get close to improving
the situation grows...
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Tor official list of new .onion addresses?

[grarpamp]

[Typo in onion list address, fixed and resent herein]

> The descriptors seem to indicate onion addresses. So if I act a relay, I
> seem to be able to get the addresses. Then how? ... Could someone
> skilled try to get the lists? :D

Yes, many services, researchers, and privates routinely do this.
The code exists in some repositories, or you can write your own,
it's not hard. Enumeration and listing in and of itself is not a problem,
neither good nor bad on its face, a mere fact of the technology in use.

It's up to the v2 users to decide if the tech works for them or not,
fits their use case or not, and whether or not to use it, not use it,
or use something else, or to seek or be provided education on the
tech and tradeoffs. For many users, v2 vs v3 simply doesn't matter.
For others, you may wish to blog or help them choose v2 vs v3.

And in fact, v2 onion services are very useful when combined
with OnionCat to yield IPv6 and UDP transport among tor's P2P
onions. That's simply not possible with v3's no-IP TCP only onions.
So for example, VoIP and other existing and new comms apps,
mossh, and Bittorrent freespeech and robust uncensorable
distribution channels, are enabled and exist entirely within tor's
v2 onion space, somewhat similar to I2P. Search the list and
tickets for "onioncat" for other use cases.

Just because some poor souls footshoot themselves... which they'll
still obviously somehow mangage to do with any tech regardless...
isn't sufficient reason to cease support, maintenance, development,
backporting, and furtherance of an agnostic technology such
as v2 onions.


> with OnionCat to yield IPv6 and UDP transport among tor's P2P
> That's simply not possible with v3's no-IP TCP only onions.

That is to say, it's not possible with code that exists today...
the various possible solutions, and others yet to be proposed,
that could provide those things with v3 onions, haven't been
developed and put into working code yet. As such, it would be
an interesting project for anyone or group that wants to do it.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Tor official list of new .onion addresses?

[grarpamp]

> with OnionCat to yield IPv6 and UDP transport among tor's P2P
> That's simply not possible with v3's no-IP TCP only onions.

That is to say, it's not possible with code that exists today...
the various possible solutions, and others yet to be proposed,
that could provide those things with v3 onions, haven't been
developed and put into working code yet. As such, it would be
an interesting project for anyone or group that wants to do it.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Tor official list of new .onion addresses?

[grarpamp]

> The descriptors seem to indicate onion addresses. So if I act a relay, I
> seem to be able to get the addresses. Then how? ... Could someone
> skilled try to get the lists? :D

Yes, many services, researchers, and privates routinely do this.
The code exists in some repositories, or you can write your own,
it's not hard. Enumeration and listing in and of itself is not a problem,
neither good nor bad on its face, a mere fact of the technology in use.

It's up to the v2 users to decide if the tech works for them or not,
fits their use case or not, and whether or not to use it, not use it,
or use something else, or to seek or be provided education on the
tech and tradeoffs. For many users, v2 vs v3 simply doesn't matter.
For others, you may wish to blog or help them choose v2 vs v3.

And in fact, v2 onion services are very useful when combined
with OnionCat to yield IPv6 and UDP transport among tor's P2P
onions. That's simply not possible with v3's no-IP TCP only onions.
So for example, VoIP and other existing and new comms apps,
mossh, and Bittorrent freespeech and robust uncensorable
distribution channels, are enabled and exist entirely within tor's
v2 onion space, somewhat similar to I2P. Search the list and
tickets for "onioncat" for other use cases.

Just because some poor souls footshoot themselves... which they'll
still obviously somehow mangage to do with any tech regardless...
isn't sufficient reason to cease support, maintenance, development,
backporting, and furtherance of an agnostic technology such
as v2 onions.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] How to get the running state of a Tor relay by its fingerprint?

[grarpamp]

Use "relay search" from this page...

https://metrics.torproject.org/

Nickname is not unique, so use fingerprint instead.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Fixing Orchid (again), need help!

[grarpamp]

You could likely remove the ones not mentioned
in torspec or the tor code, most of which are deprecated,
and potentially add compatibility for these tls 1.3 suites
from openssl 1.1.1 in case tor goes adds them later,
so long as current tor does not reject hello's with them...

TLS_CHACHA20_POLY1305_SHA256
TLS_AES_256_GCM_SHA384
TLS_AES_128_GCM_SHA256
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] public Freenet webGUI cluster over tor with OnionCat

[grarpamp]

From: damieng...@tutanota.com

Ever wonder what's on Freenet? If you're curious, there's a public
FProxy webGUI at:
http://gel2bzjxrvcmqpji.onion:/
It's part of a darknet on the Tor OnionCat IPv6 overlay network. The
other 20 peers are listed here:
http://zerobinqmdqd236y.onion/?ceffbd4a36f954e0#UTW52y4tvML8B0Wwu9i3Wl2BhbGruntf6k1f0kScz+Y=
It runs in a Debain 8.11 Docker container, which is hosted in a Debain
9.6.0 KVM domain, and that in turn is hosted on a Ubuntu 18.10 KVM
VPS. Iptables rules at VPS and KVM domain levels block all Internet
access except through Tor and OnionCat.I'll check it periodically. If
someone has broken it, I'll restart the Docker container. If someone
has managed to break the KVM domain, I'll restore that from backup.
And if someone has gone the extra mile to break the VPS, I'll restore
that from backup.
This may seem bizarre to privacy lovers. I mean, I could be logging
everything! But the point is providing easy-to-use access to Freenet
that's secured from third parties. If you decide that it's worth the
hassle, I recommend running your own node, connecting through OnionCat
IPv6 peers. Or through I2P GarlicCat peers, if you like.
While I could be logging everything, that's arguably more-or-less
irrelevant, because Tor renders you and the node mutually anonymous.
Not perfectly anonymous, true. But there's arguably little risk,
unless you and/or the node have been targeted. Just be prudent.
Especially be prudent about downloading files from the node. I
recommend using Whonix, on a machine with full-disk encryption. Or
Tails, with encrypted USB storage.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] HTTP/3 on UDP and no TCP

[grarpamp]

If you need to move UDP (or any other non-TCP protocol, including
raw IP) across tor today, you can use OnionCat or OnionVPN.
They work fine and automagically.

Obviously those are also the only available solution
for testing and using QUIC with tor today, other than
running VPN over tor out to clearnet sites, or privately
between your own onions.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] Bittorrent Legal Noise, Advocacy [re: Explaining Tor to worried parent]

[grarpamp]

> Yeah, one of the complete bullshit things. I get around 200 emails per day
> like this one:
>
> Protocol: BITTORRENT

This should tend to diminish when you begin creating and
showing people how to use filesharing and distributed storage
protocols operating entirely within the various encrypted
anonymous overlay and storage networks that exist out there.

Talking "Privacy" and "Freedom" is hardly enough to get
any percentage of various communities migrating inside
and safely using these networks, nor to get much change
in the world, you have to show them how to use real world
apps over those nets.

The *years* of anti speech and dis enablement from Tor about
agnostic Bittorrent in particular has no doubt hindered some
onionification et al of same. So you get that many more bullshit
emails and leave lots of unprotected non private and un free
peoples still out hanging using clearnet.


> I run into this all the time whilst proselytizing for Tor, as for
> example at a local non-profit makerspace recently. "Kiddie porn! FBI
> raids!" was the hue and cry, whereupon people's brains shut down. But
> this is very much a public relations issue

Jacob Appelbaum has some great presentations and
arguments made very much in the public free speech
space mentioning and addressing some of what you
speak of. You should look them up on youtube.



Move to tor-talk to discuss more.


Obligatory PJDU...
https://www.youtube.com/watch?v=jW3PFC86UNI


> I mentioned [Tor] to a parent.
>
> The conversation quickly devolved into worry and fear advising me to
> stop running it,
> to be honest now that I think about it from her perspective I can't
> blame her for thinking like this.
> However the responses and explanations from my end never hit the mark, I
> know why I'm doing it
> I know their might be risks but that I'm doing something that I believe in.
>
> Have you guys/gals ever faced situations similar to this? How did you
> handle it?
>
> Secondly she also raised the following question:
> 'if you don't do it somebody else will, so why do you put yourself at risk?
>
> Thirdly she detected from the conversation that a [node] might not
> be free from legal issues and
> I can't say that this is not the case, but I do think her view of these
> issues is utmost grim bringing up
> my future and employment opportunities.
> How would do you view/explain the severity of these legal issues?
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] torstatus.blutmagie.de

[grarpamp]

>> I'm planning to shut down my Tor network status site within the next

> Enormous thanks for all your work Olaf.
> (and if I remember correctly, you did run a heavy exit for many years in
> the past also..)


https://www.youtube.com/watch?v=Qmxd7GWWP_k
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Downloads over tor

[grarpamp]

> Tor prevents people from learning your location

There are published attacks that can and do result in
location determination. So "prevents" is a false word here.
And unfortunately it's still advertised right top of the front page:
https://www.torproject.org/

"Resists" or "makes harder / costlier" may be better terms.

It might be possible to prevent such attacks by adding
fulltime network wide padding to tor, however Tor is unwilling
to do that, and tor might not be suitable architecture for it,
so tor will remain vulnerable to attacks that exploit that.

And to Sybil attacks... cost raisers there have been suggested
for which none have taken up as a project either.

These issues are not unique to tor.

However some other newer projects are now trying to
address them as fundamental parts of their designs.

You can find some of the attacks in the "anonbib".

"Downloading" was not sufficiently defined by OP for anyone
to help estimate or rank any deanonymization risk therein.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] Onionland: Bittorrent, VoIP, Gaming, P2P, Biz, Mosh, IRC, Mail, News, Social, Apps... and UDP IPv6 OnionCat

[grarpamp]

On 10/23/18, Iain Learmonth  wrote:
>> [from other threads]

>> Bittorrent users

> This is an area with a lot of open research questions.

As to width, not really. As before, for the forseeable future regarding
the cost to generate collisions into 2^80 compared to the planet's
population, Bittorrent, over otherwise acceptably resistant overlay
networks, simply has no need for stronger authentication of
nodes than that. Worst case any bad blocks and bad talkers
will be rejected by existing torrent protocols. That's for the
public network. Private BT nets (corp, gov, friends, whatever)
have other means of restriction, PSK, VPN, etc.
And if someone does waste 80 bits of their time colliding
your bittorrent address, just generate another onion on
the fly and you're back on in seconds leaving them with
a nasty electric bill and nothing to show for it.

For purely "non exit" use, as with I2P, tor + Onioncat is
perfectly suitable to needs of today's bittorrent users
regarding node authentication bit width.

> as I understand it, v2 Onion
> services will not be around forever

Again, that's a completely arbitrary talking point based
on Tor's mommy coddling of the end user initiative.
That's certainly ok, go ahead, push v3 and all the latest
advances everywhere, no problem, that's actually a good
and noble thing.
However it is also *not* a valid excuse to drop v2,
which currently backs UDP IPv6 transport,
for those users and groups that have done the
analysis regarding their own use cases for v2.
In fact, given a v2 mode is sustainable not to the detriment
of v3 or future vX, such arbitrary statements against v2
end up looking silly. Even if it were detrimental to future
architecture it could be refactored to cohabitate with it
and for easier longer term support.

> while I don't have data on this
> I don't believe that there would be enough users to have the momentum to
> fork the Tor network.

Hard to say the strength. Looking at the numbers of
torrenters worldwide, their need for continued operations,
the big indexes and trackers now residing in overlay
networks, the constant crackdowns against the nonfree
copyright subsector on clearnet... if any significant fraction
of them woke up, the influx would be more than enough to
fork the net for the purpose of a new free haven for
torrenting alone.


> One thing I have discussed with the IETF Internet Architecture Board
> (IAB) in the past is some sort of scheme for IPv6 addressing for overlay
> networks.

Related RFC: ORCHIDv2

> The direct mapping between the IP address and an Onion service though is
> the problem. How do you discover the Onion service public key when you
> only have 96-bits of data?

That assumes that greater than any given width (from
the plausible range of 80 to 125) is needed for all use cases.
As before, for bittorrent, and human convo, it's probably not.

And for the applications where it is, well, people have been
musing solutions on the lists for years, but not devoting time
to developing a working solution as a project.

> work on v3 OnionCat
> or some Onion-native version of a protocol (via some kind of AF_ONION
> sockets).

"AF_ONION" has been suggested among many other potential
solutions. However as said, you're talking major 3rd party work...
libraries, compilation, and runtime options added to all software,
whereas essentially all software is IPv6 today, or there in near term.
Unlike torify and packet redirection, that AF is not a trivial solution.
And everyone knows that tor is not and will not be the only overlay.
Thus the software world will not accept all that work just for your
own little AF_ONION pet. Any AF_* effort would work *only* if it
was done as a wide and generic AF_OVERLAY... a library shim
that can talk to whatever overlay transports of the day, even
concurrently.. And such AF_OVERLAY work, being larger than tor,
would rightly likely be homed in independant working group elsewhere.

> An interesting fact I learnt recently is that FTP predates TCP
> and was actually "ported" after its original development.

NCP was dropped as a comms protocol in the early 80's.
Perhaps protocol and fundamental design elements of both
tor and that of other overlay networks will be dropped for
new ones in the near future as well. Nothing lasts forever,
and most today's networks aren't very resistant to today's
AI GPA. Three hops circuit extension seems dated to
defeating other primary attack classes of their day. And
today it is very unlikely that advanced GPA is the
laughable conjecture of yesteryear.

https://en.wikipedia.org/wiki/Packet_Radio_Van
https://en.wikipedia.org/wiki/Delay_line_memory

> +1 would encourage anyone that wanted to do research in this area.

Yes please.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] Onionland: Bittorrent, VoIP, Gaming, P2P, Biz, Mosh, IRC, Mail, News, Social, Apps... and UDP IPv6 OnionCat

[grarpamp]

A more generalized subject for whoever,
perhaps coming from the recent VoIP PBX threads,
or out from onionland.

There's a *lot* going on entirely within onionland that
most don't see because they never spend any time in it.
Same for the other popular overlay networks.

Onionland has been growing for over a decade now.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] Tor VoIP PBX Architecture Discussion / Onioncat

[grarpamp]

> Tor Metrics has some data on average latencies for client to Onion
> service. This is your absolute minimum latency, with the only way to
> reduce this being to have latency-aware path selection

Apps like VoIP, IRC, shell could all benefit from that selection.
Tor doesn't proffer path selection for valid reasons, so probably
won't anytime soon. Third parties might be able to develop
a controller plugin scheme for it, including as a byproduct,
even more metrics that one might wish to also choose nodes
based upon, trust, etc.

> https://metrics.torproject.org/onionperf-latencies.html

These data might generated from already cached HS descriptors,
so initiating a call to uncached would take somewhat longer.
Typically under 2s init, which is fine for any use case.

> Configuring your onion service to not be location hidden would
> improve this.

See the config options to reduce the hop count
in the path controlled by the onion service side.
The client chooses their own side.

> It would be interesting to see what kind of overheads are added by
> OnionCat

Not much.

> but I see that Onioncat is a project that has an end in sight

That's arbitrary.

Alternatively users can say, and Tor can listen... "Onioncat provides
good feature capabilities not provided by anything else, we're using
this, it works for us, or it's a nice feature capability that others can
use, we're aware of tradeoffs, we've evaluated our usage, needs,
and threat models, therefore support for it needs to continue, at
least until a replacement arrives".

That's fair.

> IPv6 addresses are not long enough to encode keys into to make
> them self-authenticating.

Referring explicitly to v3 HS desc... and without truncation,
generation, registration, mapping or other schemes... sure.

However, no... IPv6 address width is long enough for use cases where
it is long enough and not long enough for other use cases where
it is not.

Different use cases might select different strengths based on needs.

Bittorrent users don't need lifetime / PQC level authentication
between peers, they just need enough to prevent nuisance
collisions from degrading operations. Today even the less
than 32 bits of IPv4 (reality: users don't typically brute the ISPs)
are working just fine for that, and the 80 bits over Onioncat will
be sufficient for that for forseeable future. Where they need many
more equivalent bits of strength is likely in encryption, integrity,
and anonymity, not authentication.

Voice and video talkers also might not need lifetime / PQC
resistant authentication when they have additional bits
available to them through hearing and seeing and the
context of the conversation ratchet with their peer[s].
And they can repeat for integrity. But they might want
strong encryption and anonymity. Same for IRC.

Yes, strive to deploy the longest lengths and best accepted
algorithms universally wherever possible, just keep in mind
use cases exist that are quite happy to move all the sliders
around in order to meet their own overall needs.


> IPv6 addresses

Yes, one cannot rationally overload all 128 bits for that without colliding
upon allocated IPv6 space that may appear in one's host stack.
However the 1:1 key network can be larger than 80 bit. One could
easily play with up to say 125 bits by squatting on entirely
unallocated space. (Unlike the clear mistake CJDNS made by
squatting on space already allocated for a specific and conflicting
real world in stack purpose.) Obviously the common library widths
of 96 and 112 could be keyed. And request could be made for a
formal allocation if compatibility and compliance was felt needed
by some mental gymnastics.

https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml


> Either we need IPv7

256 bit equivalent strength for all keys and algos including PQC,
represented into addressing... ok, push it through the IETF just
like .onion was.

While you're at it, don't forget to push both...
1) PFS per link encryption, with PQC option
2) chaff fill to the full link rate
... in all switch and router and MAC PHY hardware,
automatically on by default, on every interface, out of the box.

Add to that pushing #OpenFabs and #OpenHW , etc
so that you know what you're getting.

> unless someone comes up with a way to make it work
> with v3 Onion Services.

> perhaps some Onion-native network layer or something else.

Lots of options and ideas here have been and can be
further solicited researched and developed. Search
the lists for Onioncat to find some of them, or generate
your own.

People would like IPv6 and UDP (even raw IP) transport because
their host stacks support it, the internet is moving to it,
many applications simply don't speak .onion or torify poorly,
and it's an interesting capability to plug into other things.

Whether in Tor or some other existing or new network,
try getting together to develop it, or white papering why it
cannot be done in any network ever. Whichever outcome,
any good 

Re: [tor-talk] Tor VoIP PBX Architecture Discussion

[grarpamp]

> architecture to Tor <—> OnionCat <—> Asterisk
> test ... one second round trip latency ... PSTN to a soft phone connected via 
> Tor (via OpenVPN).
> Hopefully performance improvement will be noticed with OnionCat.

OnionCat can provide access to using UDP and IPv6
over Tor without the extra openssh openvpn layers.

Onion to onion sets an average range of RTT due
to hopcount and speed of light. Software layers
add on top of that.


Those widely deploying onioncat / onionvpn should be
aware of some caveats and good future oppurtunities...

- Users have to compile and run them, they may not
be as available platform wide as openvpn / ssh.
That's minor since joint effort with those projects can be started
to port, document, and publish them [and their binaries again], etc.

- They're IPv6 only, that's minor, expected and ok since everyone
has local IPv6 stacks and apps now and IPv6 is the way forward.
[The encapsulated IPv4 mode is a hack, use IPv6 instead.]

- Doesn't yet work with v3 onion services automagically.
Tor may require an address resolution / translation layer
to do that, which would probably also end up handling
hostnames naming layer as a bonus.
This is a big oppurtunity for anyone who wants to design it :)

- Tor is thinking to kill off v2 onion services despite all the
uses and users of IPv6 and UDP via onioncat / onionvpn.
There is a trac ticket somewhere to continue v2 onion
services in perpetuity, with various levels of support, up
to and including fork of tor client and or network.
Continuation is a fine middle ground.

A few of the related tickets...
https://trac.torproject.org/projects/tor/ticket/23079
https://trac.torproject.org/projects/tor/ticket/6001
https://trac.torproject.org/projects/tor/ticket/25955

There are some communities using bittorrent, voice comms,
and other applications for many years, entirely within onionland,
via onioncat, onionvpn, udp, ipv6. So the tech works pretty good :)


See also...
https://www.onioncat.org/
https://github.com/rahra/onioncat
https://github.com/david415/onionvpn
https://www.youtube.com/watch?v=Zj4hSx6cW80
https://itsecx.fhstp.ac.at/wp-content/uploads/2014/11/FischerOnionCat.pdf
search: the lists for "onioncat", there are detailed posts that
 could be collated for reference by those working on things.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] torstatus.blutmagie.de

[grarpamp]

> the bird's eye view ... the default page

Same as original Hidden Wiki... all datas in your face.

Though with today's scale, an overall dashboard panel
on one page is what is needed...

"What is the status?"
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk