Re: tor replacement - was Re: Box for simple Tor node.

[grarpamp]

On 5/24/20, Karl  wrote:
> A general purpose network sounds nice.  Everything is doable.
>
> What do you think of forking the codebase of an existing network, like tor
> or gnunet or one of the newer examples from anonymity research?

What networks ultimately do, whether they are "for" voice,
video, IRC data, "messages" email files nntp etc,
http style interactivity, file storage retrieval,
cryptocurrency, etc, etc

... is move data from A to B... that's it, that's all they do.

They move a "message" data, a blob of bits, a "packet" from A to B.
Potentially but rarely in multicast-ish ways, sometimes
in route-relay-ish ways, but always, ultimately at lowest
layer, from A to B. [1]

There's probably quite little return in doing all the research just
to build some application specific network to be secure
in just that application, because under the hood all it did
was secure a more specific form of A to B for that app alone.

Yet by extending the initial upfront research a bit more, you
reach a general form of secure A to B for all applications,
such that each new application needs to do almost
no work to ride on top, applications become essentially
just plugins over a data moving network, not networks
themselves.

Further, there is timely need metrics... plowing resources
into making the best "chat" net, starves research from
all other standalone app specific nets, it builds incompatible
towers of networks which cannot interoperate, and they compete
for exclusive node count funding etc instead of combining
node count bandwidth for the commons. If need be, nodes within
the commons can offer more specific transport/plugin features.

Last, creating dozens of app specific nets cannot take
advantage of riding and hiding in each others noise over
a common transport overlay layer. And makes more risk
for singled out political attack on against one app than
against a general purpose net.


Perhaps tor is not best as all it does is TCP.
Phantom offers raw IPv6 for all existing apps, and is currently light
enough that may be an ok candidate for whitepapering a dynamic chaff
anti-traffic-analysis bolt on tech proof of concept, but IPv6 is not
a generic data message handling network in sense of application
level concepts.
Building a more generic network may serve better long term,
but will produce and require new apps to compile
to its plugin API such as i2p-snark torrent app is
specific to i2p net and has to use its API instead of
just using IPv6. More generic nets could offer IPv6 as a
plugin on top of them. But the extra layering to do that will
make them slower than tor/phantom style IP base alone.

Not to say "forking" any one net is better than other
as 10 or more already extant or papered could be evaluated for that,
just that a generic or at least IP API design may be more likely to
produce a mass payoff effect than say building the next singularly
focused impenetrable "cypherpunk mixmaster email network",
which is a useless waste to anyone wanting to do browser,
IRC, file, coin, voice, etc.



[1] Note the only place you'll find research on
anything different from A to B, is from people trying
to design fundamental alternatives to IP networks...
broadcast, radio, satcom etc.

Re: tor replacement - was Re: Box for simple Tor node.

[jim bell]

 Components of software are supposed to be reuseable, which is one of its 
efficiencies.  Of course, if there is some sort of flaw already present, 
reusing it adopts the flaw.  Nevertheless, I suspect that it is more valuable 
to get SOMETHING working, relatively rapidly, especially if the same group of 
hardware nodes can run multiple 'virtual' anonymity networks.  
I don't have the expertise to weigh in on the issue of using the code of a 
specific network.  But if the new network we are building can readily run 
multiple examples of code, I don't see anything wrong with trying to implement 
multiple software concepts.  
          Jim Bell

On Sunday, May 24, 2020, 02:59:42 PM PDT, Karl  wrote:  
 
 A general purpose network sounds nice.  Everything is doable.
What do you think of forking the codebase of an existing network, like tor or 
gnunet or one of the newer examples from anonymity research?
On Thu, May 21, 2020, 1:55 AM jim bell  wrote:

 On Wednesday, May 20, 2020, 07:27:40 PM PDT, other.arkitech 
 wrote:
 

‐‐‐ Original Message ‐‐‐
 On Tuesday, May 19, 2020 10:41 PM, jim bell  wrote:
 


Algorithm-agnostic anonymization network.

Let's say we are agreed that a new anonymization network should be implemented. 
 One problem is that advances in such networks generally  require implementing 
entirely new networks to check out new algorithms and new features, such 
improvements are strongly deterred.  After all, that's one reason that TOR 
doesn't get as many improvements as we might like.  (Another reason is that it 
is financed, at least in part, by people who are hostile to a "too-good" 
anonymization system.)

Sure, we could implement a new set of nodes, hopefully at least 1000 in number. 
I think that ordinary, residential users should be able to run nodes. Internet 
services are provided with as much as 1 terabyte/month capacity, and possibly 
unlimited as well.  (CenturyLink 1 Gbps, for example)    We could implement a 
new onion-routing system, akin to TOR but with some improvements, most 
prominently adding chaff.  So far, so good.  But there may be other ideas, 
other improvements that people might want to try out.

I've already proposed that it should be possible for just about every node to 
be an output node.  Possibly every node should be an input node, as well.   The 
big impediment to this is that people naturally want to avoid the potential 
legal harassment they might get if their IP node sent out gigabytes of 'in the 
clear' forbidden data.  My ideas for a solution?  Output data could be 
encrypted, enough to make it unreadable except by the end recipient.  The 
operator of an output node that emits only seemingly-random data would be hard 
to hold legally responsible for that forbidden content, since nobody expects 
him to know how to convert it into plaintext.  And/or, the data can be output 
into two streams, which would be XOR'd with each other only by the intended 
recipient to find the data.  

And, this network could also run different anonymization algorithms, 
simultaneously.  Onion-routing may have its own limitations.  Somebody might 
have a good idea for an alternative system.  Why shouldn't it be possible to 
serve two algorithms?  Or dozens?  How about Bittorrent as well?  Imagine 1000 
nodes, each equipped with a 10-terabyte hard drive?  

                 Jim Bell



>Hi,
>I am preparing a draft of a draft for a spec of what I think would be the 
>ideal complimentary anonymization overlay that fits on the already running 
>distributed system I am working on, which is USPS and is very good. 
It would be great if many ideas arise in this list so we can start focusing a 
conversation. My personal interes is to achieve a system that can provide Sybil 
protection for voting systems. Which is the reason Tor cannot be used with 
USPS, since one could create millions of colluding evil nodes and ditch the 
system. I limit it using IPv4 because it is very easy to enforce an 
homogeneously distributed network controlling the maximum number of nodes/votes 
  per IP. This limit will grow as the IPs are filled with voting power.
I already have the Sysbil protection implemented and the network of nodes 
running exchanging encrypted traffic about consensus. The only thing I have 
left are two things:
onion routing (or a faster alternative that doesn't exist but I am 
researching), chaff traffic.

Jim Bell's comments follow:
I hope that what I've suggested, an anonymization constellation that can run 
multiple algorithms simultaneously, is practical and can be implemented 
successfully.  I suppose what I'm describing amounts to multi-tasking, and my 
understanding is that's not trivial.  What does everyone think about this?  Can 
it be done?

...and probably more considerations. I am not expert in anon overlays, but 
perhaps we can brainstorm so I can become one : )

Thanks for reading
OA


  
  

Re: tor replacement - was Re: Box for simple Tor node.

[Karl]

A general purpose network sounds nice.  Everything is doable.

What do you think of forking the codebase of an existing network, like tor
or gnunet or one of the newer examples from anonymity research?

On Thu, May 21, 2020, 1:55 AM jim bell  wrote:

> On Wednesday, May 20, 2020, 07:27:40 PM PDT, other.arkitech <
> other.arkit...@protonmail.com> wrote:
>
>
> ‐‐‐ Original Message ‐‐‐
> On Tuesday, May 19, 2020 10:41 PM, jim bell  wrote:
>
>
> Algorithm-agnostic anonymization network.
>
> Let's say we are agreed that a new anonymization network should be
> implemented.  One problem is that advances in such networks generally
> require implementing entirely new networks to check out new algorithms and
> new features, such improvements are strongly deterred.  After all, that's
> one reason that TOR doesn't get as many improvements as we might like.
> (Another reason is that it is financed, at least in part, by people who are
> hostile to a "too-good" anonymization system.)
>
> Sure, we could implement a new set of nodes, hopefully at least 1000 in
> number. I think that ordinary, residential users should be able to run
> nodes. Internet services are provided with as much as 1 terabyte/month
> capacity, and possibly unlimited as well.  (CenturyLink 1 Gbps, for
> example)We could implement a new onion-routing system, akin to TOR but
> with some improvements, most prominently adding chaff.  So far, so good.
> But there may be other ideas, other improvements that people might want to
> try out.
>
> I've already proposed that it should be possible for just about every node
> to be an output node.  Possibly every node should be an input node, as
> well.   The big impediment to this is that people naturally want to avoid
> the potential legal harassment they might get if their IP node sent out
> gigabytes of 'in the clear' forbidden data.  My ideas for a solution?
> Output data could be encrypted, enough to make it unreadable except by the
> end recipient.  The operator of an output node that emits only
> seemingly-random data would be hard to hold legally responsible for that
> forbidden content, since nobody expects him to know how to convert it into
> plaintext.  And/or, the data can be output into two streams, which would be
> XOR'd with each other only by the intended recipient to find the data.
>
> And, this network could also run different anonymization algorithms,
> simultaneously.  Onion-routing may have its own limitations.  Somebody
> might have a good idea for an alternative system.  Why shouldn't it be
> possible to serve two algorithms?  Or dozens?  How about Bittorrent as
> well?  Imagine 1000 nodes, each equipped with a 10-terabyte hard drive?
>
>  Jim Bell
>
>
>
> >Hi,
> >I am preparing a draft of a draft for a spec of what I think would be the
> ideal complimentary anonymization overlay that fits on the already running
> distributed system I am working on, which is USPS and is very good.
> It would be great if many ideas arise in this list so we can start
> focusing a conversation. My personal interes is to achieve a system that
> can provide Sybil protection for voting systems. Which is the reason Tor
> cannot be used with USPS, since one could create millions of colluding evil
> nodes and ditch the system. I limit it using IPv4 because it is very easy
> to enforce an homogeneously distributed network controlling the maximum
> number of nodes/votes   per IP. This limit will grow as the IPs are filled
> with voting power.
> I already have the Sysbil protection implemented and the network of nodes
> running exchanging encrypted traffic about consensus. The only thing I have
> left are two things:
> onion routing (or a faster alternative that doesn't exist but I am
> researching), chaff traffic.
>
>
> Jim Bell's comments follow:
>
> I hope that what I've suggested, an anonymization constellation that can
> run multiple algorithms simultaneously, is practical and can be implemented
> successfully.  I suppose what I'm describing amounts to multi-tasking, and
> my understanding is that's not trivial.  What does everyone think about
> this?  Can it be done?
>
> ...and probably more considerations. I am not expert in anon overlays, but
> perhaps we can brainstorm so I can become one : )
>
> Thanks for reading
> OA
>
>
>

Re: tor replacement - was Re: Box for simple Tor node.

[grarpamp]

https://arstechnica.com/information-technology/2016/08/building-a-new-tor-that-withstands-next-generation-state-surveillance/

"Tor hasn't changed, it's the world that's changed." -- Tor Project
Five years later, tor still looks same as 20 years prior,
while world adversaries advanced 20 years and counting.

Re: tor replacement - was Re: Box for simple Tor node.

[jim bell]

 On Wednesday, May 20, 2020, 07:27:40 PM PDT, other.arkitech 
 wrote:
 

‐‐‐ Original Message ‐‐‐
 On Tuesday, May 19, 2020 10:41 PM, jim bell  wrote:
 


Algorithm-agnostic anonymization network.

Let's say we are agreed that a new anonymization network should be implemented. 
 One problem is that advances in such networks generally  require implementing 
entirely new networks to check out new algorithms and new features, such 
improvements are strongly deterred.  After all, that's one reason that TOR 
doesn't get as many improvements as we might like.  (Another reason is that it 
is financed, at least in part, by people who are hostile to a "too-good" 
anonymization system.)

Sure, we could implement a new set of nodes, hopefully at least 1000 in number. 
I think that ordinary, residential users should be able to run nodes. Internet 
services are provided with as much as 1 terabyte/month capacity, and possibly 
unlimited as well.  (CenturyLink 1 Gbps, for example)    We could implement a 
new onion-routing system, akin to TOR but with some improvements, most 
prominently adding chaff.  So far, so good.  But there may be other ideas, 
other improvements that people might want to try out.

I've already proposed that it should be possible for just about every node to 
be an output node.  Possibly every node should be an input node, as well.   The 
big impediment to this is that people naturally want to avoid the potential 
legal harassment they might get if their IP node sent out gigabytes of 'in the 
clear' forbidden data.  My ideas for a solution?  Output data could be 
encrypted, enough to make it unreadable except by the end recipient.  The 
operator of an output node that emits only seemingly-random data would be hard 
to hold legally responsible for that forbidden content, since nobody expects 
him to know how to convert it into plaintext.  And/or, the data can be output 
into two streams, which would be XOR'd with each other only by the intended 
recipient to find the data.  

And, this network could also run different anonymization algorithms, 
simultaneously.  Onion-routing may have its own limitations.  Somebody might 
have a good idea for an alternative system.  Why shouldn't it be possible to 
serve two algorithms?  Or dozens?  How about Bittorrent as well?  Imagine 1000 
nodes, each equipped with a 10-terabyte hard drive?  

                 Jim Bell



>Hi,
>I am preparing a draft of a draft for a spec of what I think would be the 
>ideal complimentary anonymization overlay that fits on the already running 
>distributed system I am working on, which is USPS and is very good. 
It would be great if many ideas arise in this list so we can start focusing a 
conversation. My personal interes is to achieve a system that can provide Sybil 
protection for voting systems. Which is the reason Tor cannot be used with 
USPS, since one could create millions of colluding evil nodes and ditch the 
system. I limit it using IPv4 because it is very easy to enforce an 
homogeneously distributed network controlling the maximum number of nodes/votes 
  per IP. This limit will grow as the IPs are filled with voting power.
I already have the Sysbil protection implemented and the network of nodes 
running exchanging encrypted traffic about consensus. The only thing I have 
left are two things:
onion routing (or a faster alternative that doesn't exist but I am 
researching), chaff traffic.

Jim Bell's comments follow:
I hope that what I've suggested, an anonymization constellation that can run 
multiple algorithms simultaneously, is practical and can be implemented 
successfully.  I suppose what I'm describing amounts to multi-tasking, and my 
understanding is that's not trivial.  What does everyone think about this?  Can 
it be done?

...and probably more considerations. I am not expert in anon overlays, but 
perhaps we can brainstorm so I can become one : )

Thanks for reading
OA


  

Re: tor replacement - was Re: Box for simple Tor node.

[other.arkitech]

‐‐‐ Original Message ‐‐‐
On Tuesday, May 19, 2020 10:41 PM, jim bell  wrote:

> Algorithm-agnostic anonymization network.
>
> Let's say we are agreed that a new anonymization network should be 
> implemented.  One problem is that advances in such networks generally  
> require implementing entirely new networks to check out new algorithms and 
> new features, such improvements are strongly deterred.  After all, that's one 
> reason that TOR doesn't get as many improvements as we might like.  (Another 
> reason is that it is financed, at least in part, by people who are hostile to 
> a "too-good" anonymization system.)
>
> Sure, we could implement a new set of nodes, hopefully at least 1000 in 
> number. I think that ordinary, residential users should be able to run nodes. 
> Internet services are provided with as much as 1 terabyte/month capacity, and 
> possibly unlimited as well.  (CenturyLink 1 Gbps, for example)We could 
> implement a new onion-routing system, akin to TOR but with some improvements, 
> most prominently adding chaff.  So far, so good.  But there may be other 
> ideas, other improvements that people might want to try out.
>
> I've already proposed that it should be possible for just about every node to 
> be an output node.  Possibly every node should be an input node, as well.   
> The big impediment to this is that people naturally want to avoid the 
> potential legal harassment they might get if their IP node sent out gigabytes 
> of 'in the clear' forbidden data.  My ideas for a solution?  Output data 
> could be encrypted, enough to make it unreadable except by the end recipient. 
>  The operator of an output node that emits only seemingly-random data would 
> be hard to hold legally responsible for that forbidden content, since nobody 
> expects him to know how to convert it into plaintext.  And/or, the data can 
> be output into two streams, which would be XOR'd with each other only by the 
> intended recipient to find the data.
>
> And, this network could also run different anonymization algorithms, 
> simultaneously.  Onion-routing may have its own limitations.  Somebody might 
> have a good idea for an alternative system.  Why shouldn't it be possible to 
> serve two algorithms?  Or dozens?  How about Bittorrent as well?  Imagine 
> 1000 nodes, each equipped with a 10-terabyte hard drive?
>
>  Jim Bell

Hi,
I am preparing a draft of a draft for a spec of what I think would be the ideal 
complimentary anonymization overlay that fits on the already running 
distributed system I am working on, which is USPS and is very good.
It would be great if many ideas arise in this list so we can start focusing a 
conversation. My personal interes is to achieve a system that can provide Sybil 
protection for voting systems. Which is the reason Tor cannot be used with 
USPS, since one could create millions of colluding evil nodes and ditch the 
system. I limit it using IPv4 because it is very easy to enforce an 
homogeneously distributed network controlling the maximum number of nodes/votes 
  per IP. This limit will grow as the IPs are filled with voting power.
I already have the Sysbil protection implemented and the network of nodes 
running exchanging encrypted traffic about consensus. The only thing I have 
left are two things:
onion routing (or a faster alternative that doesn't exist but I am 
researching), chaff traffic.

...and probably more considerations. I am not expert in anon overlays, but 
perhaps we can brainstorm so I can become one : )

Thanks for reading
OA

Re: tor replacement - was Re: Box for simple Tor node.

[jim bell]

 Algorithm-agnostic anonymization network.
Let's say we are agreed that a new anonymization network should be implemented. 
 One problem is that advances in such networks generally  require implementing 
entirely new networks to check out new algorithms and new features, such 
improvements are strongly deterred.  After all, that's one reason that TOR 
doesn't get as many improvements as we might like.  (Another reason is that it 
is financed, at least in part, by people who are hostile to a "too-good" 
anonymization system.)
Sure, we could implement a new set of nodes, hopefully at least 1000 in number. 
I think that ordinary, residential users should be able to run nodes. Internet 
services are provided with as much as 1 terabyte/month capacity, and possibly 
unlimited as well.  (CenturyLink 1 Gbps, for example)    We could implement a 
new onion-routing system, akin to TOR but with some improvements, most 
prominently adding chaff.  So far, so good.  But there may be other ideas, 
other improvements that people might want to try out.
I've already proposed that it should be possible for just about every node to 
be an output node.  Possibly every node should be an input node, as well.   The 
big impediment to this is that people naturally want to avoid the potential 
legal harassment they might get if their IP node sent out gigabytes of 'in the 
clear' forbidden data.  My ideas for a solution?  Output data could be 
encrypted, enough to make it unreadable except by the end recipient.  The 
operator of an output node that emits only seemingly-random data would be hard 
to hold legally responsible for that forbidden content, since nobody expects 
him to know how to convert it into plaintext.  And/or, the data can be output 
into two streams, which would be XOR'd with each other only by the intended 
recipient to find the data.  
And, this network could also run different anonymization algorithms, 
simultaneously.  Onion-routing may have its own limitations.  Somebody might 
have a good idea for an alternative system.  Why shouldn't it be possible to 
serve two algorithms?  Or dozens?  How about Bittorrent as well?  Imagine 1000 
nodes, each equipped with a 10-terabyte hard drive?  
                 Jim Bell

Re: tor replacement - was Re: Box for simple Tor node.

[Karl]

That sounds cool.  Let's design and build it.

On Thu, May 14, 2020, 5:02 AM grarpamp  wrote:

> >   well yes you can rate limit any application. If you rate limit the
> web
> > browser then the typical 5mb pages (95% malware)  won't load in
> 0.1s, 'like
> > they should'.
>
> Moot since this chaff fill does not rate limit or impede wheat traffic,
> some overheat but user should see roughly same speed
> as tor, i2p, phantom, etc.
>
> > the basic architecture for an overlay that works as "tor replacement".
>
> Would rather see a TA resistant general purpose overlay
> transport network that can serve many uses. A 'tor replacement'
> would be just one module in that.
>

Re: tor replacement - was Re: Box for simple Tor node.

[Karl]

On Thu, May 14, 2020, 5:02 AM grarpamp  wrote:

> > the basic architecture for an overlay that works as "tor replacement".
>
> Would rather see a TA resistant general purpose overlay
> transport network that can serve many uses. A 'tor replacement'
> would be just one module in that.
>

Do you mean Template Attacks ( https://wiki.newae.com/Template_Attacks ) or
something else?  Template attacks look so incredibly cool.  I want to learn
to do them so I can put a battery-operated olimex in a few insulated layers
of soldered foil and see if I can still read the secret key by using a
parabolic reflector.

>

Re: tor replacement - was Re: Box for simple Tor node.

[grarpamp]

>   well yes you can rate limit any application. If you rate limit the web
> browser then the typical 5mb pages (95% malware)  won't load in 0.1s, 
> 'like
> they should'.

Moot since this chaff fill does not rate limit or impede wheat traffic,
some overheat but user should see roughly same speed
as tor, i2p, phantom, etc.

> the basic architecture for an overlay that works as "tor replacement".

Would rather see a TA resistant general purpose overlay
transport network that can serve many uses. A 'tor replacement'
would be just one module in that.

Re: tor replacement - was Re: Box for simple Tor node.

[grarpamp]

>> > web cesspool servers send data in
>> > big chunks/high speed bursts, which is not compatible with constant
>> > rate links.

Go play packet filter rate limits, works fine.

>> your ISP rate or physical link speed already
>> serves as max rate

> people could generally send
> dummy traffic to eacht other at the max rate advertised by their
> ISP

They already send all kind of traffic to each other today.
Go plug in your 100Mbps NIC, go buy 10Mbps from
your ISP, then go send 10Mbps worth of whatever you
want between whoever you want. Works fine.

> you can't just foward traffic from
> the  overlay to the arpanet web cesspool and expect anonimity

That's further approachable with some network fill design
than it is with tor or anything else today that do nothing.
Possibly even a 10x odds reduction or more.

> Services that
> don't require high speed/high volume traffic, like, say, mail, may be fine.
> 'Bursty' traffic won't work.

Define 'bursty'. Anything three packets or more might be considered
as such. An email message is a lot of TCP packets, go plot their
traffic curve.

Go play with packet filter rate limits, introduce and give a wheat
flow priority over a pipe that is already maxed out with a chaff flow,
watch the flows trade off.

Re: tor replacement - was Re: Box for simple Tor node.

[grarpamp]

> web cesspool servers send data in
> big chunks/high speed bursts, which is not compatible with constant rate
> links.

They are, your ISP rate or physical link speed already
serves as max rate, or go test set a lower rate in your
packet filter, things work fine, just slower.
https://www.freebsd.org/cgi/man.cgi?query=dummynet

People obviously can't shove a 320kbps audio file
over 256kbps link and expect to hear it in lossless
realtime 1x speed direct off the wire, have to save it first.

Re: tor replacement - was Re: Box for simple Tor node.

[grarpamp]

On 5/9/20, jim bell  wrote:
> At this point, I see the main impediment is finding somebody with the
> motivations and qualifications to write the software.  An additional
> complication is that whoever volunteers, he might not be trusted by

While coders can provide design meta, coders can also
be hired more or less to just meet some premade spec.
It will be opensource where trust as to code exploit
is somewhat reasonably determinable. Trust as to protocol spec
design itself holding up to adversaries in operation is a different
area of evaluation.

> What is to be done?

People might start surveying relevant existing networks and papers,
past and present, note and annotate all their design and features in
some big comparison tables, cut out their bad parts, invent new parts,
assemble all the then viable parts into some design specification.
Parade it around to see how badly it gets attacked and broken.
Then scrap or amend it, and code and deploy it.

Or skip all those traditional formalities and just start
hacking stuff together.


> The one situation that I consider intolerable is that TOR remains as a
> monopoly in the "anonymization marketplace".

Yes, there should be some solid competition in the
deployed overlay network space.

A good generic overlay transport network might be one that will be able
to carry, and thus cater to, many people's desires to otherwise go off and
create single purpose networks that would generally have the same anonymous
overlay feel but for different applications... such as one net for messaging,
one net for storage, one for cryptocurrency, voice, grid compute, etc, etc.
Doing ten different application nets seems a bit redundant effort and tech,
instead of ten different plugins into one net.

Of course if you restrict yourself to only same basic functions as Tor
(onionland + exits) under an alternative new Tor design + say chaff,
things become easier, at expense of being able to plug more
applications generically over it.

Defining what you want to be, and how, is work.
Coding is more trivial.

Tor does have a monopoly over automagic exit capability.
But networks like i2p and phantom do compete with it in
offering psuedo TCP network stack compatible hidden services.

There are probably at ten or so reasonably well papered overlay
networks that never got implemented and could be drawn from.

The internet just transports messages around a packet switch,
only the applications know whether they're storage, coin, voice,
messages, etc.

Re: tor replacement - was Re: Box for simple Tor node.

[jim bell]

 Okay, so what should I actually do?  I didn't suggest this project intending 
to make the decisions by myself, alone.  I figured I might be one of dozens of 
deciders who combine ideas to plan this.  
At this point, I see the main impediment is finding somebody with the 
motivations and qualifications to write the software.  An additional 
complication is that whoever volunteers, he might not be trusted by others. 
What is to be done?
The one situation that I consider intolerable is that TOR remains as a monopoly 
in the "anonymization marketplace".  
          Jim Bell 


On Friday, May 8, 2020, 01:09:16 PM PDT, John Young  
wrote:  
 
 So long as it is much more profitable to prevent 
and damage cybersecurity it is unlikely that any 
scheme for reliable and trustworthy public 
cybersecurity will be developed for any longer 
than it takes to monetize it, following a 
campaign to generate public trust with freeware 
and high recommendations of experts already 
deeply compromized (that's what experts means).

This has been the pattern for as long as 
insecurity and fear has been promoted by 
authoritarians, revolutionaries and "freedom fighters."

Challengers of authority inevitably betray 
believers for king's coin and/or other 
irresistable rewards. The only sec methods that 
publicly protect as expected are the ones never 
heard about, used briefly, disappear without a 
trace. "Never heard about," "used briefly," and 
"disappear without a trace" are obviously 
deception marketing tools. "Obviously deception marketing tools" too.

Mea culpa. This is freeware. Don't click it.

At 02:17 PM 5/8/2020, you wrote:
>Excellent.  I should mention that I have 
>focussed on Raspberry Pi 4 merely because it was 
>new, and seemed to be quite capable of serving 
>as a anonymization node.  If anything, we might 
>call it "over-capable", but in the computer 
>world that's not necessarily a bad 
>thing.  Standardized devices, especially if they 
>are manufactured in huge quantity, become more 
>economical. If somebody has an alternative idea 
>for the hardware, now would be an excellent time to speak up.
>
>  They also tend to be studied more intensely 
> than obscure, low-volume devices, I would 
> imagine.  What's the old saying, something like 
> "Yes, we're paranoid, but I sometimes wonder if 
> we are paranoid 
> ENOUGH?" 
> https://www.goodreads.com/quotes/876669-yes-i-m-paranoid-but-am-i-paranoid-enough
>
>
>One big improvement that I think we've settled 
>on should be done is to implement 'chaff' into 
>the protocol. 'chaff' might have been a problem 
>if the people who host the nodes had some 
>limited-data Internet service, but I am aware 
>that Centurylink now offers 1 gigabit service 
>for $65 monthly, and I think that service has no 
>monthly data limit.  (their slower services have 
>a 1 terabyte montly limit).  That should be 
>plenty to allow for generous chaff.
>
>  I also thought of an idea to encrypt, or at 
> least combine the outputs of two output nodes 
> to generate the final data.  Why?  It is 
> frequently (and quite wisely!) recommended that 
> a home-user NOT act as an output node, for fear 
> of being held liable (civilly or criminally) 
> for plaintext that comes out of an output 
> node.  But I think there is a solution.  Don't 
> output plaintext, encrypt it somewhat so 
> 'nobody' can simply point to it and declare, 
> "There goes that forbidden data, again!".
>
>One idea, mine, is to output TWO 
>seemingly-random files, from two different 
>output nodes, which when XOR'd with each other 
>regenerates the (suspicious?) data.  Another 
>possibility is to encrypt the output with a 
>symmetrical key, and perhaps deliver the key 
>from another node.  Not so much to make the data 
>REALLY secure, but instead merely turn it into 
>seemingly-randomized data that cannot be 
>labelled 'suspicious' merely by monitoring the node's output.
>
>Why shouldn't ordinary people be able to run an 
>anonymization node, and even an output node, if these precautions are taken?
>
>
>My point about the lifetime of SD cards was 
>simply that if it used 'frequently', they might 
>wear out.  But, if they are only used for 
>program storage and settings, that won't be a problem.
>
>                  Jim Bell
>
>
>
>On Friday, May 8, 2020, 01:51:58 AM PDT, 
>other.arkitech  wrote:
>
>
>I've been running USPS on a network of raspberry pis.
>You anonymization layer project is very aligned 
>with my cryptoplatform project, and they both could be the same thing.
>with respect to wearing out the SD cards I have 
>Raspberry pis older than 2 years runing the 
>blockchain protocol and I haven detected failures in any of the _60 nodes
>
>best
>OA
>
>
>Sent with ProtonMail Secure Email.
>
>������� Original Message �������
>On Friday, May 8, 2020 8:35 AM, jim bell  wrote:
>
>>
>>It turns out 

Re: tor replacement - was Re: Box for simple Tor node.

[Zenaan Harkness]

On Fri, May 08, 2020 at 06:17:37PM +, jim bell wrote:
>  Excellent.  I should mention that I have focussed on Raspberry Pi 4 merely 
> because it was new, and seemed to be quite capable of serving as a 
> anonymization node.


A warning Jim, you might consider calling any conceivable such nodes as 
"corporate surveillance reduction nodes" or "privacy hope enhancement nodes" 
(PHEPs has a good ring to it).

Without qualifying "privacy" nodes, non technical users -will- be lead astray, 
for example they will be lead to believe they are achieving private online 
communications.  other.architekt fell into the same false assumption about Tor, 
not realising the very real and known problems directly about privacy on the 
Tor network.

When some folks discover they have been deceived in their thinking in this way, 
there will be backlash against those whom they believe deceived them.

Choose your words wisely.



>  If anything, we might call it "over-capable", but in the computer world 
>that's not necessarily a bad thing.  Standardized devices, especially if they 
>are manufactured in huge quantity, become more economical. If somebody has an 
>alternative idea for the hardware, now would be an excellent time to speak up.
>  They also tend to be studied more intensely than obscure, low-volume 
> devices, I would imagine.  What's the old saying, something like "Yes, we're 
> paranoid, but I sometimes wonder if we are paranoid ENOUGH?"  
> https://www.goodreads.com/quotes/876669-yes-i-m-paranoid-but-am-i-paranoid-enough

Just as an additional minor example, the above sentences, juxtaposed as they 
were immediately after your first sentence ("Raspberry Pi 4 .. seemed to be 
quite capable of serving as a anonymization node") would most likely further 
feed the unthinking "reader with AP hope" into assuming, subconsciously 
inferring, or consciously believing, the following:

   - So it's 'over-capable' as an anonymization node?  Great, that's even 
better.

   - So it's a 'standardized anonymization device', wow, how good is that?!

   - And so the Raspberry Pis "also tend to be studied more intensely than 
obscure, low-volume devices" - but of course, that will make it not only 
private and secure, but hardened!

   - And damn, he's also quoting "Yes, we're paranoid, but I sometimes wonder 
if we are paranoid ENOUGH?" - man, this Jim guy thinks just like I do, he must 
-really- be onto this security and privacy thing - wish I'd found this sooner, 
sign me up!



Again Jim, beware the backlash.

Re: tor replacement - was Re: Box for simple Tor node.

[John Young]

So long as it is much more profitable to prevent 
and damage cybersecurity it is unlikely that any 
scheme for reliable and trustworthy public 
cybersecurity will be developed for any longer 
than it takes to monetize it, following a 
campaign to generate public trust with freeware 
and high recommendations of experts already 
deeply compromized (that's what experts means).


This has been the pattern for as long as 
insecurity and fear has been promoted by 
authoritarians, revolutionaries and "freedom fighters."


Challengers of authority inevitably betray 
believers for king's coin and/or other 
irresistable rewards. The only sec methods that 
publicly protect as expected are the ones never 
heard about, used briefly, disappear without a 
trace. "Never heard about," "used briefly," and 
"disappear without a trace" are obviously 
deception marketing tools. "Obviously deception marketing tools" too.


Mea culpa. This is freeware. Don't click it.

At 02:17 PM 5/8/2020, you wrote:
Excellent.  I should mention that I have 
focussed on Raspberry Pi 4 merely because it was 
new, and seemed to be quite capable of serving 
as a anonymization node.  If anything, we might 
call it "over-capable", but in the computer 
world that's not necessarily a bad 
thing.  Standardized devices, especially if they 
are manufactured in huge quantity, become more 
economical. If somebody has an alternative idea 
for the hardware, now would be an excellent time to speak up.


 They also tend to be studied more intensely 
than obscure, low-volume devices, I would 
imagine.  What's the old saying, something like 
"Yes, we're paranoid, but I sometimes wonder if 
we are paranoid 
ENOUGH?" 
https://www.goodreads.com/quotes/876669-yes-i-m-paranoid-but-am-i-paranoid-enough



One big improvement that I think we've settled 
on should be done is to implement 'chaff' into 
the protocol. 'chaff' might have been a problem 
if the people who host the nodes had some 
limited-data Internet service, but I am aware 
that Centurylink now offers 1 gigabit service 
for $65 monthly, and I think that service has no 
monthly data limit.  (their slower services have 
a 1 terabyte montly limit).  That should be 
plenty to allow for generous chaff.


 I also thought of an idea to encrypt, or at 
least combine the outputs of two output nodes 
to generate the final data.   Why?   It is 
frequently (and quite wisely!) recommended that 
a home-user NOT act as an output node, for fear 
of being held liable (civilly or criminally) 
for plaintext that comes out of an output 
node.  But I think there is a solution.  Don't 
output plaintext, encrypt it somewhat so 
'nobody' can simply point to it and declare, 
"There goes that forbidden data, again!".


One idea, mine, is to output TWO 
seemingly-random files, from two different 
output nodes, which when XOR'd with each other 
regenerates the (suspicious?) data.  Another 
possibility is to encrypt the output with a 
symmetrical key, and perhaps deliver the key 
from another node.  Not so much to make the data 
REALLY secure, but instead merely turn it into 
seemingly-randomized data that cannot be 
labelled 'suspicious' merely by monitoring the node's output.


Why shouldn't ordinary people be able to run an 
anonymization node, and even an output node, if these precautions are taken?



My point about the lifetime of SD cards was 
simply that if it used 'frequently', they might 
wear out.  But, if they are only used for 
program storage and settings, that won't be a problem.


  Jim Bell



On Friday, May 8, 2020, 01:51:58 AM PDT, 
other.arkitech  wrote:



I've been running USPS on a network of raspberry pis.
You anonymization layer project is very aligned 
with my cryptoplatform project, and they both could be the same thing.
with respect to wearing out the SD cards I have 
Raspberry pis older than 2 years runing the 
blockchain protocol and I haven detected failures in any of the _60 nodes


best
OA


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, May 8, 2020 8:35 AM, jim bell  wrote:



It turns out that in two months, I will have 
the opportunity to announce this project at a 
convention.  I will be happy to do so if it 
appears that there will be sufficient progress 
in the next two months.  A fairly firm 
commitment by someone to write the software 
would be an excellent start.And, this 
announcement MAY lead to some financing of the project.


The main question, other than the financing, is 
the programming of the software.  Has there been any progress on this matter?



  Jim Bell




On Monday, December 9, 2019, 11:39:10 AM PST, 
jim bell  wrote:




I hope people haven't fotten about the idea for 
making  an alternate anonymization system.  The 
hardware requirements almost write 
themselves.  Yes, there was some 

Re: tor replacement - was Re: Box for simple Tor node.

[jim bell]

 It turns out that in two months, I will have the opportunity to announce this 
project at a convention.  I will be happy to do so if it appears that there 
will be sufficient progress in the next two months.  A fairly firm commitment 
by someone to write the software would be an excellent start.    And, this 
announcement MAY lead to some financing of the project.  
The main question, other than the financing, is the programming of the 
software.  Has there been any progress on this matter?  

      Jim Bell



On Monday, December 9, 2019, 11:39:10 AM PST, jim bell  
wrote:  
 
  I hope people haven't fotten about the idea for making  an alternate 
anonymization system.  The hardware requirements almost write themselves.  Yes, 
there was some discussion about the software issues.  Could/did somebody write 
a proposal of the functions and features of this system?  Any volunteers on 
programming it?
               Jim Bell


On Tuesday, October 15, 2019, 01:21:31 PM PDT, jim bell 
 wrote:  
 
  Jim Bell's comments inline:  
On Tuesday, October 15, 2019, 11:23:53 AM PDT, Punk  wrote: 
 
 
 On Sun, 13 Oct 2019 22:15:58 + (UTC)
jim bell  wrote:



>>...let's flesh out some of the numbers and practices.  Shouldn't take more 
>>than a few hours or at most a couple days, to give everybody an input. 
>> This   appears to be a representative sample of a Raspberry Pi 4 board, in 
>> kit form, 4 gigabyte of RAM (I guess they must mean SDCard, right, and not 
>> ordinary SRAM or DRAM?

    as coderman said, that's the pi's main RAM memory. So yeah, those ARM 
'systems on a chip'  are quite capable. They have 4 cores running at ~1.2gcps 
and tons of ram. 

_I_ remember when an Intel 8048 was called a "computer on a chip"!!!

>>  SD wears out, right?), with cables, a clear plastic box.  $85 in quantity 
>>one.  

>    the previous model with 'only' 1gb or RAM, same processor is $35 or less. 
>(you need to add a sd card, power supply and case)

How much main memory would be useful for a transfer node to use?

 >   ...so the hardware is quite cheap. The question is, of course, to what 
degree is it safe? The rpi for instance is designed in the english shithole by 
people working for the amerikan mafia known as broadcom. The rpi's main 
processor is a broadcom processor (not the quadcore ARM), running closed source 
firmware written by the raspberry 'foundation'. 

>    there are other systems that are not as bad as the rpi - at least you 
>won't be running GCHQ-NSA firmware directly. (some people were working on an 
>open source firmware but I don't think they got it to work)

I agree that this is a matter that needs to be discussed.  But no doubt you've 
heard of the saying, 'the perfect being the enemy of the good'.  


> Can we agree that 1,000 quantity will be a good initial "critical mass" for 
> this project? 

    A thousand independent node operators isn't a small number. 


>> tor is currently larger,  https://metrics.torproject.org/networksize.html 
>> but 1000 is still a good start.

 >   yeah, you have to take into account for instance what % of those nodes is 
owned by the NSA, GCHQ, FSB, stasi, whatever the chinese agency is called, 
samsung, hitachi, etc etc etc etc etc.

  >  but wait, is your network partially client/server like tor, or is it a 
fully decentralized peer to peer network? (freenetproject.org)

First, I'm not looking for it to be thought of as "my" network, although maybe 
I will be credited with some initiative for giving the project a kick.   The 
person whose network it is publicly known as might end up being the person who 
initially funds it, and agrees to have his name attached to the project as 
sponsor.  
And no, I'm not qualified to answer your second comment.  I don't consider 
myself a "software person", never have been.  This is yet another issue 'we' 
will have to work out.  
    


>> While hypothetically node operators might receive some sort of subsidy (in 
>> full or in part) for their internet-service cost, it's also plausible that 
>> their Internet payment will be their "skin in the game", their contribution 
>> to the project.  Centurylink offers 1 gigabit/second service for $65 plus 
>> tax.  The speed itself is only one part of the issue.  I think there is no 
>> data limit for their 1 gigabit service; their slower services may have a 1 
>> terabyte/month limit.  

>    I don't know about bandwidth costs, but they obv. depend on how your 
>network works. So discussing those costs before having some idea about what 
>kind of capacity/traffic/padding/architecture etc the system will have seems 
>kinda backwards.

The reason I initially referred to "1 gigabit"  service for nodes is that I 
was, and still am, under the impression that current Centurylink policy exempts 
them from their "excessive use" policy.  I suspect that computers of this level 
(Raspbery pi 4) won't be able to throughput more than a few tens of megabits of 
(processed) data, if that, 

Re: tor replacement - was Re: Box for simple Tor node.

[Zenaan Harkness]

On Sat, Oct 26, 2019 at 10:30:36PM -0300, Punk - Stasi 2.0 wrote:
> 
> 
>   here's another article with some interesting info.
> 
>   Freedom Systems 2.1 Security Issues and Analysis
>   https://www.freehaven.net/anonbib/cache/freedom21-security.pdf
> 
>   'freedom' was the name of the network run by 'zero knowdlege systems' - 
> As noted ian goldberg was part of zks and now works for tor. Adam back was 
> also involved. It seems to me that when the company failed some(most?) ppl 
> went from working in the 'private' sector to working for the govt. 
> 
>   
>   "someone who is watching the network links can see that you are logging 
> into the Freedom Network by watching the packets. They can’t tell what you’re 
> doing, but can see that you are logged in, and by counting packets and seeing 
> how long you’re online, may be able to make certain assumptions. (Counting 
> and timing packets is possible today since traffic shaping and link padding 
> do not offer strong security as implemented."
> 
> 
>   "In the current version of the protocol there is no link padding, cover 
> traffic or traffic shaping. It might be argued that one at minimum needs some 
> of these countermeasures to defend against traffic analysis, but our initial 
> analysis suggests that these countermeasures are probably necessary, but 
> certainly not sufficient. This is because even if one does implement a 
> combination of these countermeasures there remain a number of attacks, not 
> significantly harder than attacking a system without these countermeasures.  
> The main example is the packet round-trip timing related attacks, where the 
> attacker passively observes or actively (and plausibly deniably) induces 
> latency variations to uniquely identify the source of a route. These 
> remaining attacks are expensive in bandwidth utilization to defend against, 
> and the counter measures greatly hinder performance. Consider that to defend 
> against timing attacks, even as a first step one would need to start by 
> padding round-trip times to get cover, reducing all round-trip times to worst 
> case round-trip." 


Yes, that's the same conclusion.

You install/ set up one or more dark links, or you are exposed to
active latency injection attacks.

Given this fact, is it still worth pursuing the software side of any
overlay net?

For many use cases an overlay net appears to provide benefits - the
usage stats of Tor certainly suggest there is not insignificant
demand for as much, and all high latency low b/w apps appear to
"obviously benefit" since active latency injection attacks must
inject latency "in the order of" your particular local ping circle's
latency config - if your ping is 2 hours, and your first hop is
always to nodes who are actual friends and therefore maintain their
own fixed rate links, your own node going down for an hour or a day
says nothing about anyone else or about who you connect to through
your friend's node, other than that your own node went down.
[absolutism warning, but this one feels sound]

Re: tor replacement - was Re: Box for simple Tor node.

[Zenaan Harkness]

On Wed, Oct 23, 2019 at 05:15:57AM -0400, grarpamp wrote:
> >> ok, so that's actually one of, or the most fundamental requirement.
> >> The connection between user and 'network' HAS to have a fixed rate.
> 
> Assuming "fixed rate" means "always filled to said rate" not
> "fillable up to said rate"... then that makes every users node
> look nicely busy.

Ack.

"Chaff fill" has become overloaded.

Let's try Link Metrics Normalization or LMN (or something better if
someone speaks up soon):

 1. packets per time unit normalization

 2. packets transmission latency/jitter normalization

 3. packet size normalization (this one's easy)


> And if the rate is the same for all users, then
> every user looks the same.

Ideal operating mode.

Practical (as in acceptable to users) operation probably requires as
coderman suggested earlier, to allow steady stepping upwards/
downwards over time (by config only of course), to provide for the
impatient bittorrent and youtuber crowd. There is no bw cap that will
be accepted by all, probably not even by a majority.


> However all nodes in the net need to be always filled to
> some rates.

Ack. I imagine a network ping (to friend/ connected nodes) on say a
10 minute interval, which from memory was only about 2.1MiB per
month, would be an acceptable base load for everyone, and that many
will accept higher base load than this.


> Otherwise adversary vampire can just watch
> the nodes end user is connected to, or perturb the users
> packet stream, or wait until user unluckily routes across
> quiet middle nodes, etc.

Ack. Gov stalkers gonna stalk.

One limit case to consider is all direct (first hop) p2p/f2f links
are always and only ever, 1KiB/s (say). You want more bw, you add
more separate links, and the disappearing act is handled by stepping
up, and maintaining that rate for some period of time (presumably
longer than actually needed), before eventually stepping down
(removing links).

And the point, in relation to "unluckily route across quiet
(stalking) middle node" - some application of multi-path:

  - 10 trusted friends to whom I hop in to the net

  - 1 dark net server supporting multi path, from which I download
the latest Adobe Photoshop cr24c/7

  - 10 separate routes to 10 separate "darknet server access point
nodes"

  - if 1 link gets killed in the middle, my corresponding friend node
keeps chaff filling to my node regardless, and I can attempt to
create with him, a new route;
- also, the other 9 links continue to hum along



> > last but not least, you could apply the padding traffic to key
> > pre-distribution or opportunistic protocol maintenance. e.g. distributing
> > routing and node identity information. (the "directory")
> 
> If pad fill can be used to carry something, better than to
> waste it.

Re: tor replacement - was Re: Box for simple Tor node.

[Zenaan Harkness]

On Thu, Oct 17, 2019 at 11:11:41PM +, coderman wrote:
> ‐‐‐ Original Message ‐‐‐
> On Thursday, October 17, 2019 10:31 PM, Punk  wrote:
> > ...
> > ok, so that's actually one of, or the most fundamental requirement. The 
> > connection between user and 'network' HAS to have a fixed rate. Let's check 
> > the archive...
> > ...
> >
> > So that's it Jim. Users have to be connected 24/7 using a constant rate 
> > link. Today it can be more than 100 bytes/s
> 
> one idea is to use something akin to reliable multicast groups,
> where you gradually increase your bandwidth according to some
> defined strata of bandwidth, and affirmative control notification
> is required to increase your bandwidth (number of concurrent
> strata).

There are various improvements, but the most basic operational mode
is simple in design and ought be straightforward to implement - never
has been, yet.


> this is not TCP friendly,

The protocol should not be TCP, but should be UDP.

Then apps can use UDP, or TCP, or any protocol higher than UDP;
TCP precludes, or rather introduces latency and other problems, for
many apps/protocols that rely on something lower level than TCP.


> but it would support multiple levels of
> bandwidth in such a system. this doesn't eliminate traffic analysis
> (like true link padding) but it does muddy the waters into
> partitions which are much larger than (1).
> 
> another benefit would be to use that padding traffic with
> application layer awareness of bulk transport. e.g. ability to say
> "send this, but no rush..." vs. interactive traffic.
> 
> last but not least, you could apply the padding traffic to key
> pre-distribution or opportunistic protocol maintenance. e.g.
> distributing routing and node identity information. (the
> "directory")

Indeed. Lots of improvements possible.


Anecdote:

Back about 3 years ago when I first ran a Tor exit node at home (on a
~1 MiB/s ADSL), I would sometimes SSH into the box from another
location and forward VNC for a virtual desktop, really just to
monitor the Tor node.

Pretty consistently, within about 10 minutes, the SSH connection
would die with some SSH error, so I'd reconnect and watch some more,
then it would die again.

It appeared evident to me that SSH had some bug that was being
exploited to, at the very least, kill SSH connections with some
presumably packet injection or modification (presumably after
monitoring the connection for a bit).

That, of course, was entirely disconcerting.

Since then there's been at least one SSH bug finally disclosed/
fixed, though I can't find the one that stood out to me as
commensurate to my experience, the following may be of anecdotal
interest:


  Fixing The New OpenSSH Roaming Bug
  https://www.upguard.com/blog/fixing-the-new-openssh-roaming-bug

  ... The flaw involves the accidental inclusion of experimental
  client-side roaming support in the OpenSSH client, despite being
  disabled on the server-side years ago. This feature essentially
  enables users to resume broken SSH connections. Unfortunately, a
  maliciously configured server can exploit a bug in the client and
  capture its memory contents, including any private encryption keys
  used for SSH connections.



  Cisco's warning: Patch now, critical SSH flaw affects Nexus 9000
  fabric switches
  
https://www.zdnet.com/article/ciscos-warning-patch-now-critical-ssh-flaw-affects-nexus-9000-fabric-switches/
  May 2, 2019 -- 11:12 GMT (21:12 AEST)

  The company disclosed the bug on Tuesday and has given it a
  severity rating of 9.8 out of 10.
...


  
https://nakedsecurity.sophos.com/2018/08/23/vulnerability-in-openssh-for-two-decades-no-the-sky-isnt-falling/


  Serious SSH bug lets crooks log in just by asking nicely…
  
https://nakedsecurity.sophos.com/2018/10/17/serious-ssh-bug-lets-crooks-log-in-just-by-asking-nicely/

  Big, bad, scary bug of the moment is CVE-2018-10933.

  This is a serious flaw – in fact, it’s a very serious flaw – in a
  free software library called libssh.

  The flaw is more than just serious – it’s scary, because it
  theoretically allows anyone to log into a server protected with
  libssh without entering a password at all.

  It’s scary because ssh, or SSH as it is often written, is probably
  the most widely deployed remote access protocol in the world.

  Almost all Unix and Linux servers use SSH for remote
  administration, and there are an awful lot of awfully large server
  farms out there, and so there’s an awful lot of SSH about.

  ... By far the most commonly used SSH version out there is an open
  source product called OpenSSH, created and maintained by the
  security-conscious folks at OpenBSD.

  OpenSSH is a completely separate implementation to libssh – they
  don’t include or rely on each other’s code.

  Other well-known open source implementations of SSH include
  Dropbear (a stripped down version commonly used on routers and
  other IoT devices), libssh2 (it’s a different product to