Neowin: New OnionShare 2.2 update makes it easy to share files and host sites on the Tor network

[Zenaan Harkness]

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 at gmail.com> wrote:  
>  
>  On 10/17/19, jim bell <jdb10987 at 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...