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).