Re: Neowin: New OnionShare 2.2 update makes it easy to share files and host sites on the Tor network
Now, I'm sending to the list, also. On Thursday, October 17, 2019, 05:23:40 PM PDT, jim bell <jdb10987@yahoo.com> wrote: Okay, I'm not advocating (or opposing) this concept. It just seemed to me that since we are talking TOR-related features, we should pay attention to what TOR currently claims to provide. I think a few months ago, I mentioned the idea (which I assume somebody else thought of first, probably years ago) of splitting a file into two (or more?) pieces, stored in two (or more?) separate systems), which when XOR'd together, provide the (forbidden, banned, 'reallybad!!!' 'highly-illegal') product file. Neither file, alone, would be 'forbidden'. The purpose of this is not 'secrecy' of course, but merely deniability. Without the other file(s), the one file _I_ possess will be indistinguishable from a random number. In fact, it could be a random number, which when XOR'd with a forbidden text, becomes what amounts to another random number, and somebody else's system will hold the other 'random number' . Think Vernam cipher, otherwise known as a "one-time pad". https://en.wikipedia.org/wiki/One-time_pad Jim Bell On Thursday, October 17, 2019, 12:36:16 PM PDT, Steven Schear <schear.steve@gmail.com> wrote: Filesharing is a privacy dead end. Only something like Mojo Nation / Mnet publishing, where few or no participants need be aware of or hold file contents, offer viable plausible deniability. On Thu, Oct 17, 2019, 6:07 PM jim bell <jdb10987@yahoo.com> wrote: Neowin: New OnionShare 2.2 update makes it easy to share files and host sites on the Tor network. https://www.neowin.net/news/new-onionshare-22-update-makes-it-easy-to-share-...
On 10/17/19, jim bell <jdb10987@yahoo.com> wrote:
Okay, I'm not advocating (or opposing) this concept. It just seemed to me that since we are talking TOR-related features, we should pay attention to what TOR currently claims to provide. I think a few months ago, I mentioned the idea (which I assume somebody else thought of first, probably years ago) of splitting a file into two (or more?) pieces, stored in two (or more?) separate systems), which when XOR'd together, provide the (forbidden, banned, 'reallybad!!!' 'highly-illegal') product file. Neither file, alone, would be 'forbidden'. The purpose of this is not 'secrecy' of course, but merely deniability. Without the other file(s), the one file _I_ possess will be indistinguishable from a random number. In fact, it could be a random number, which when XOR'd with a forbidden text, becomes what amounts to another random number, and somebody else's system will hold the other 'random number' . Think Vernam cipher, otherwise known as a "one-time pad". https://en.wikipedia.org/wiki/One-time_pad
See the related... https://en.wikipedia.org/wiki/OFFSystem
On Thursday, October 17, 2019, 12:36:16 PM PDT, Steven Schear <schear.steve@gmail.com> wrote:
Filesharing is a privacy dead end. Only something like Mojo Nation / Mnet publishing, where few or no participants need be aware of or hold file contents, offer viable plausible deniability.
On Mon, Oct 21, 2019 at 07:08:58AM -0400, grarpamp wrote:
See the related...
Nice! Can imagine OFFSystem, combined with even just 1- or 2-hop onion routing, where you route amongst 'friends', to be a viable low overhead (extra bandwidth) and reasonably low latency and therefore to replace existing torrent clients. Which reminds me - we must treat different streams according to the nature of the stream. - Phone call demands low latency, reasonably low bandwidth. - Bittorrent demands high throughput, is fine with utilizing excess available bandwidth (like running a coin miner in your idle process). - Text messages/ txt chat, are miniscule bandwidth, can tolerate unpredictable latency (at least, up to a few seconds if it so happens), but to achieve a systemic difference, we -must- achieve wheat in the chaff (and "via trusted friends") "disappearing act". - some txt messages can tolerate super high latency, in exchange for significantly increased anonymity and etc properties - comfort for the main stream end consumer crowd accessing MSM web sites, demands low privacy, low security, bursty, relatively low latency streams to view heavy moronic web page "CNN brain programming" - like Tor achieves Within the confines of: - packet switched altnet - with end-user node making own routing decisions - plus applied/configured meat space "friend trust metrics" I believe we can group streams into the above categories and others which make sense. Different security requires different routing - even accessing an MSM web page could be diverted to my altnet chaff fill node, if more important stuff is not being up/down-loaded via my node, but only if my node is not doing something I deem more important. With a fundamentally flexible packet switched UDP base layer, we can build appropriate stream "protocols" or "configurations" on top, to satisfy different users, uses and/ or apps - at least this is the goal - don't lock in the end users to a single stream modality, so that we don't keep rewriting the stack over and over and ...
On Monday, October 21, 2019, 04:10:23 AM PDT, grarpamp <grarpamp@gmail.com> wrote: On 10/17/19, jim bell <jdb10987@yahoo.com> wrote:
Okay, I'm not advocating (or opposing) this concept. It just seemed to me that since we are talking TOR-related features, we should pay attention to what TOR currently claims to provide. I think a few months ago, I mentioned the idea (which I assume somebody else thought of first, probably years ago) of splitting a file into two (or more?) pieces, stored in two (or more?) separate systems), which when XOR'd together, provide the (forbidden, banned, 'reallybad!!!' 'highly-illegal') product file. Neither file, alone, would be 'forbidden'. The purpose of this is not 'secrecy' of course, but merely deniability. Without the other file(s), the one file _I_ possess will be indistinguishable from a random number. In fact, it could be a random number, which when XOR'd with a forbidden text, becomes what amounts to another random number, and somebody else's system will hold the other 'random number' . Think Vernam cipher, otherwise known as a "one-time pad". https://en.wikipedia.org/wiki/One-time_pad
See the related...
Yup. Sounds like it, Remember, 'deniability', not 'secrecy'. Jim Bell
On Mon, Oct 21, 2019 at 07:08:58AM -0400, grarpamp wrote:
On 10/17/19, jim bell <jdb10987@yahoo.com> wrote:
'random number' . Think Vernam cipher, otherwise known as a "one-time pad". https://en.wikipedia.org/wiki/One-time_pad
See the related...
Their download looks like a live CD. https://sourceforge.net/projects/offsystem/files/ Anyone got just the source code, without using SF CVS? Or, can you let us know what size is the SF.net CVS repo for OFFSystem? Finally, anyone know how to bypass (or bring back the "Advanced - add exception" to firefox for the following site: https://www.eleves.ens.fr:8080/home/madore/misc/freespeech.html (OFFSystem core ideas link.) ?? TIA
On Thursday, October 17, 2019, 12:36:16 PM PDT, Steven Schear <schear.steve@gmail.com> wrote:
Filesharing is a privacy dead end. Only something like Mojo Nation / Mnet publishing, where few or no participants need be aware of or hold file contents, offer viable plausible deniability.
On Fri, Oct 25, 2019 at 12:53:13PM +1100, Zenaan Harkness wrote:
On Mon, Oct 21, 2019 at 07:08:58AM -0400, grarpamp wrote:
On 10/17/19, jim bell <jdb10987@yahoo.com> wrote:
'random number' . Think Vernam cipher, otherwise known as a "one-time pad". https://en.wikipedia.org/wiki/One-time_pad
See the related...
Their download looks like a live CD. https://sourceforge.net/projects/offsystem/files/
Anyone got just the source code, without using SF CVS?
Or, can you let us know what size is the SF.net CVS repo for OFFSystem?
Finally, anyone know how to bypass (or bring back the "Advanced - add exception" to firefox for the following site: https://www.eleves.ens.fr:8080/home/madore/misc/freespeech.html (OFFSystem core ideas link.) ??
I tried but failed with this: https://support.mozilla.org/en-US/questions/1222739 If someone can upload the text content of that freespeech.html page somewhere, or attach it to an email here, that might be useful so we can read the page.
On Thursday, October 17, 2019, 12:36:16 PM PDT, Steven Schear <schear.steve@gmail.com> wrote:
Filesharing is a privacy dead end. Only something like Mojo Nation / Mnet publishing, where few or no participants need be aware of or hold file contents, offer viable plausible deniability.
More one time pads... http://www.madore.org/~david/misc/freespeech.html
On Monday, October 21, 2019, 04:10:23 AM PDT, grarpamp <grarpamp@gmail.com> wrote: On 10/17/19, jim bell <jdb10987@yahoo.com> wrote:
Okay, I'm not advocating (or opposing) this concept. It just seemed to me that since we are talking TOR-related features, we should pay attention to what TOR currently claims to provide. I think a few months ago, I mentioned the idea (which I assume somebody else thought of first, probably years ago) of splitting a file into two (or more?) pieces, stored in two (or more?) separate systems), which when XOR'd together, provide the (forbidden, banned, 'reallybad!!!' 'highly-illegal') product file. Neither file, alone, would be 'forbidden'. The purpose of this is not 'secrecy' of course, but merely deniability. Without the other file(s), the one file _I_ possess will be indistinguishable from a random number. In fact, it could be a random number, which when XOR'd with a forbidden text, becomes what amounts to another random number, and somebody else's system will hold the other 'random number' . Think Vernam cipher, otherwise known as a "one-time pad". https://en.wikipedia.org/wiki/One-time_pad
See the related... OFFSystem
One application of using this XOR principle is to avoid the problem of a anonymization output node (TOR or otherwise) containing openly suspicious or incriminating information. If all data through the network splits, before it exits, converted to two (or more???) seemingly-random data steams, outputted by two (or more???) distinct nodes, it can be recombined to regenerate the desired source data. An individual node's output is simply random data. Jim Bell
On Fri, Oct 25, 2019 at 09:44:23PM +0000, jim bell wrote:
On Monday, October 21, 2019, 04:10:23 AM PDT, grarpamp <grarpamp@gmail.com> wrote:
On 10/17/19, jim bell <jdb10987@yahoo.com> wrote:
Okay, I'm not advocating (or opposing) this concept. It just seemed to me that since we are talking TOR-related features, we should pay attention to what TOR currently claims to provide. I think a few months ago, I mentioned the idea (which I assume somebody else thought of first, probably years ago) of splitting a file into two (or more?) pieces, stored in two (or more?) separate systems), which when XOR'd together, provide the (forbidden, banned, 'reallybad!!!' 'highly-illegal') product file. Neither file, alone, would be 'forbidden'. The purpose of this is not 'secrecy' of course, but merely deniability. Without the other file(s), the one file _I_ possess will be indistinguishable from a random number. In fact, it could be a random number, which when XOR'd with a forbidden text, becomes what amounts to another random number, and somebody else's system will hold the other 'random number' . Think Vernam cipher, otherwise known as a "one-time pad". https://en.wikipedia.org/wiki/One-time_pad
See the related... OFFSystem
One application of using this XOR principle is to avoid the problem of a anonymization output node (TOR or otherwise) containing openly suspicious or incriminating information. If all data through the network splits, before it exits, converted to two (or more???) seemingly-random data steams, outputted by two (or more???) distinct nodes, it can be recombined to regenerate the desired source data.
An individual node's output is simply random data.
That's a nice property of course, but we're talking OTPs (one time pads), which scale directly by the quantity of data sent/received: - and you have to share the OTPs with the peer(s) you are communicating with - it's a 1-1 ratio - the more data you send, the more data you need as a OTP - if you reuse your OTP, at least in trivial ways then the reconstruction testing becomes likewise trivial, thus losing the advantage of your OTP XOR "hiding" Such a system could possibly be useful for low volume, very high latency, yet highly valuable messages, but then how many people have this time of use case? Those who use it therefore need to hide their use, thus depending on other systems. In every case you depend on using another system (for your hiding/ secrecy, and/ or anonymity), then the first question to ask is "does the first system still add any benefit, now that we're using this other system?" Not the simplest of problems this whole privacy and anonymity thing...
On Sat, Oct 26, 2019 at 09:49:55AM +1100, Zenaan Harkness wrote:
On Fri, Oct 25, 2019 at 09:44:23PM +0000, jim bell wrote:
On Monday, October 21, 2019, 04:10:23 AM PDT, grarpamp <grarpamp@gmail.com> wrote:
On 10/17/19, jim bell <jdb10987@yahoo.com> wrote:
Okay, I'm not advocating (or opposing) this concept. It just seemed to me that since we are talking TOR-related features, we should pay attention to what TOR currently claims to provide. I think a few months ago, I mentioned the idea (which I assume somebody else thought of first, probably years ago) of splitting a file into two (or more?) pieces, stored in two (or more?) separate systems), which when XOR'd together, provide the (forbidden, banned, 'reallybad!!!' 'highly-illegal') product file. Neither file, alone, would be 'forbidden'. The purpose of this is not 'secrecy' of course, but merely deniability. Without the other file(s), the one file _I_ possess will be indistinguishable from a random number. In fact, it could be a random number, which when XOR'd with a forbidden text, becomes what amounts to another random number, and somebody else's system will hold the other 'random number' . Think Vernam cipher, otherwise known as a "one-time pad". https://en.wikipedia.org/wiki/One-time_pad
See the related... OFFSystem
One application of using this XOR principle is to avoid the problem of a anonymization output node (TOR or otherwise) containing openly suspicious or incriminating information. If all data through the network splits, before it exits, converted to two (or more???) seemingly-random data steams, outputted by two (or more???) distinct nodes, it can be recombined to regenerate the desired source data.
An individual node's output is simply random data.
That's a nice property of course, but we're talking OTPs (one time pads), which scale directly by the quantity of data sent/received:
- and you have to share the OTPs with the peer(s) you are communicating with
- it's a 1-1 ratio - the more data you send, the more data you need as a OTP
- if you reuse your OTP, at least in trivial ways then the reconstruction testing becomes likewise trivial, thus losing the advantage of your OTP XOR "hiding"
Such a system could possibly be useful for low volume, very high latency, yet highly valuable messages, but then how many people have this time of use case? Those who use it therefore need to hide their
s/time/type/
use, thus depending on other systems.
In every case you depend on using another system (for your hiding/ secrecy, and/ or anonymity), then the first question to ask is "does the first system still add any benefit, now that we're using this other system?"
Not the simplest of problems this whole privacy and anonymity thing...
So OTPs are (according to the OFFSystem paper) the only provably uncrackable crypto. They however have the prerequisite of pad distribution between end points using an OTP - we're in meat space territory here. OTPs then need to be stored by each end point. If storage is offline, some mechanism to xfer your incoming encrypted message to where the OTP is (another computer presumably) Small OTPs could be used for short messages, with decoding done by hand, literally without any computer except perhaps for the generation, printout and deletion of pads - be sure your printer's HDD does not get into enemy hands :) So for "really high value short text messages", OTPs may not only be practical, but be especially desired - but usually it's just spooks and MIL folks who ever have any such use case. Notwithstanding, it will be trivial to support OTPs in IQNets for those who want to use them - at least, at the protocol layer it's just another encryption algorithm, known to each end point. If you have a use case for OTP's, you probably want some software for end users to use, or just OTP pad printouts and training on how to use them (offset (perhaps page and line number), and how to transform cypher text to plain text - e.g. XOR. And if you push that does into software, and store your OTPs on a local computer, and you're not Intel or the NSA, you're probably begging to have your messages decrypted. Anyway, OTPs can and likely shall be supported at the network layer, although the most practical use is like at a higher layer (you don't lose the OTP benefits by sending OTP-encrypted messages through some other crypto network).
On Sat, Oct 26, 2019 at 09:49:55AM +1100, Zenaan Harkness wrote:
On Fri, Oct 25, 2019 at 09:44:23PM +0000, jim bell wrote:
On Monday, October 21, 2019, 04:10:23 AM PDT, grarpamp <grarpamp@gmail.com> wrote:
See the related... OFFSystem
One application of using this XOR principle is to avoid the problem of a anonymization output node (TOR or otherwise) containing openly suspicious or incriminating information. If all data through the network splits, before it exits, converted to two (or more???) seemingly-random data steams, outputted by two (or more???) distinct nodes, it can be recombined to regenerate the desired source data.
An individual node's output is simply random data.
Not fully: - YES for individual nodes in the stream (since it's multiple split streams, not a single stream), but - NO for the origin node which must split/scatter the original stream and send the parts across the separate routes, and also - NO for whichever destination node does the unsplit/gather - it has to receive all parts in order to reassemble the stream I.e. the 2 end nodes (origin and destination), must, necessarily, either emit or receive, all of the parts of the stream - and if the XORing is a known algorithm (say we are XORing against a known Wikimedia zip file, or against previous packets), then our GPA stalker can also do these same operations - we're back to having to properly encrypt, not merely split, the entire stream. And we note that in Tor's implementation, it is known that the end point nodes are the primary nodes of interest to GPAs anyway (for statistical traffic analysis). So we're back to having to properly hide (encrypt+decrypt) the multi streams. If we wish to use XOR to "properly hide" the parts, once again, we must begin with either an actual (physically generated pure random) OTP (which must therefore be somehow pre-shared), or agree on a crypto PRNG (e.g. AES) and corresponding session key for XORing each stream - and now we're back to traditional crypto. ---------------------------------------- Stream splitting/ massive micro routing Setting aside OTPs and XORing for the moment, and considering stream splitting, like "RAID striping" of a network stream (or even just a packet): Yes, IQNets intends to maximize multi-streaming or micro-streaming, to attempt to: - maximize usage of many end-user, often low-bandwidth, peer nodes (and similarly route nodes), in order to achieve high bandwidth (compare to Tor which relies on beefy CIA funded "desirable" middle-of-route nodes, since with traditional TCP, your maximum stream speed is the speed of your slowest mid-route node) - provide effectively transparent (to the end user) "node in my route just dropped out" handling - multi-home websites, especially with appropriate content addressing model apps, downloading from multiple servers or sources simultaneously, bittorrent style ("every peer is a server", with incentivization to serve what you dl) - other benefits? Issues to handle include: - micro streams are a scatter gather - the end user's node can do the scatter/ splitting - some node must do the gathering/ joining - server (comms) lib are prime targets for the gather/join step - but at least initially, TCP should work to seamlessly gather, as that is TCP's core design intention - turn a series of packets into a stable stream - UDP packets arriving at unpredictable times and therefore out of sequence, and sometimes not arriving at all (e.g. getting dropped by overloaded routers in the middle) and checksumming to verify any flipped bits, and sending requests to resend any dropped packets, is all handled by TCP, and if you're using UDP in your APP, you're aware of the limitations. - overhead issues for massive micro streaming need to be looked at/ thought about and analyzed in aggregate - e.g.: - my TCP socket is auto-split into many micro routes - the likelihood of UDP packets arriving out of order, shall increase, therefore e.g. a TCP socket on top of this network, shall on average, require a larger 'UDP packet assembling' buffer - what is the marginal impack upon a node, and upon network bandwidth, and latency, for each additional micro route? - UDP protocols which want low latency, can utilize multiple micro routes, and study the latency per route, and drop routes which are unsatisfactory - real time latency/route optimization
participants (3)
-
grarpamp -
jim bell -
Zenaan Harkness