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 <jya at pipeline.com> 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>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 <other.arkitech at protonmail.com> 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 <https://protonmail.com>ProtonMail Secure Email.
>
>������� Original Message �������
>On Friday, May 8, 2020 8:35 AM, jim bell <jdb10987 at yahoo.com> 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 <jdb10987 at yahoo.com> 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 <jdb10987 at yahoo.com> wrote:
>>
>>
>>
>>Jim Bell's comments inline:
>>
>>On Tuesday, October 15, 2019, 11:23:53 AM PDT, Punk <punks at tfwno.gf> wrote:
>>
>>
>>On Sun, 13 Oct 2019 22:15:58 +0000 (UTC)
>>jim bell <<mailto:jdb10987 at yahoo.com>jdb10987 at yahoo.com> 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.htm 
>> l 
>> but>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, so 
>>Internet rate won't likely be a 
>>bottleneck.  But a data cap could easily become 
>>a limiting factor, especially if the network implements heavy chaff.
>>
>>
>> >> >    As to 'entirely new', it seems to me 
>> that a high latency mixing network (which is 
>> not a 'new' design) is desirable. Such a 
>> network should allow people to communicate 
>> using non-real-time messages, instead of 
>> allowing them to browse jewtube. Low 
>> latency/real time networks and communications seem a lot harder to secure."
>> >
>> >> What I'm thinking of is a 
>> programmable-latency network, say anything 
>> from 1 to 256 hops.  Although, it would be 
>> hard to imagine needing more than 16, I suppose.
>>
>>  >  some variables :
>>
>> >    *) number of mixers/nodes a message goes through
>>
>>
>>Yes, I'm thinking that a user should be able to 
>>decide, for any individual message, how many 
>>nodes it will go through.  He will still have 
>>a latency issue to deal with, but at least that 
>>tradeoff question will be decided by HIM, not 
>>the entire network as a group,.
>>
>>
>>  >  *) all clients and nodes are exchanging 
>> fixed size packets all the time (chaff)
>>
>>
>>I consider chaff essential to increase the 
>>difficulty of tracing messages, especially when traffic is low.
>>
>>
>>  >  *) there are no clients - it's a peer to peer network
>>
>>
>> > >This is a list of proposed 'improvements' 
>> to 
>> TOR. 
>> <https://blog.torproject.org/tor-design-proposals-how-we-make-changes-our-protocol 
>> No>https://blog.torproject.org/tor-design-proposals-how-we-make-changes-our-protocol 
>> No doubt SOMEWHERE there is a list of 
>> 'proposed improvements that we know the TOR 
>> structure will never agree to because they 
>> will be considered 'too good' '.  Shouldn't 
>> we use those, too?  Especially those!
>>
>>
>>  >  so the best pentagon criminals like tor's 
>> syverson have been 'working' on this for a 
>> while and there are tons of 'literature' - some of their stuff is here
>>
>>  >  <https://www.freehaven.net/papers.html>The Free Haven Project
>>
>>  >  notice that cypherpunks(...) like adam 
>> back(now blockstream CEO, google funded) a guy 
>> called goldberg and others have been/are 
>> involved with tor to varying degrees. 
>> Furthermore, adam back was subscribed to this list. His last message
>>
>> > 
>> <https://lists.cpunks.org/pipermail/cypherpunks/2015-June/053438.html>[Bitcoin-development] 
>> questions about bitcoin-XT code fork & non-consensus hard-fork
>>
>>  >  anyway, you Jim could try to get some 
>> ideas or/and help from back. Ver for marketing 
>> and funding and back for technical assistance may be a good combination.
>>
>>
>>I hope that if the proposal is technically 
>>sound, financing won't be a problem.  My idea 
>>of a target amount of initial subsidy for 
>>setting up one node (ignoring 
>>software-development costs) should be about 
>>$50:  Myself, I'd like to charge about $30 for 
>>the hardware kit, the quantity-1 cost would be 
>>$90 or so, but I don't yet have an estimate if 
>>the materials are purchased in 1000+ quantity.
>>
>>
>> >    Here are some other datapoints :
>>
>> >    <https://maidsafe.net/>https://maidsafe.net/
>>
>>  >  those ppl have allegedly been working on 
>> teh problem...since forever. And they've 
>> gotten nowhere. They have even launched their own shitcoin/financial scam.
>>
>>
>>I see lots of fine words on their 
>>website.    But they haven't accomplished much?
>>
>>
>>
>>  > 
>> <https://coinmarketcap.com/currencies/maidsafecoin/>MaidSafeCoin 
>> (MAID) price, charts, market cap, and other metrics | CoinMarketCap
>>
>> >    And they are not the only ones who want 
>> to add economic incentives to 'file sharing'. 
>> The idea seems like a good one to me, but it doesn't seem to work.
>>
>>
>>If it were truly easy to attach a 18-terabyte 
>>HD to each node, that would make it a really 
>>interesting proposition...  This, for $140 more...
>>
>>
>>    > <https://storj.io/>Decentralized Cloud Storage — Storj
>>    "Decentralized Cloud Storage"
>>
>> >    <https://tron.network/>TRON 
>> Foundation：Capture the future slipping away
>>    "TRON is an ambitious project dedicated to 
>> building the infrastructure for a truly decentralized Internet."
>>
>> >    there prolly are a few more like that.
>>
>>
>>  >  bottom line : there's a fair number of 
>> variables to take into account...
>>
>>
>>True, <sigh>, quite true.
>>
>>                      Jim Bell
>>
>>
>>
>>
>>
>>

  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 28130 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/cypherpunks/attachments/20200509/7c83d0ad/attachment.txt>