Decentralized Storage Comparison
Interesting, useful development. Looking at the table, in the second item below, I see that most of these storage systems use "client side" encryption. I assume that means that the person who enters the data is in charge of the encryption. But I can see the possibility that this information would be not intended to be encrypted, yet the people (thousands? millions?) of them who might eventually participate in storing data would not want to experience negative consequences from storing what, to them, is a mass of what are (to them) unknown documents, potentially of questionable legal origin. Suppose one of the (millions?) of users of this system (ones who want their documents stored) decides to not encrypt some challengable document. (and by "document", I don't mean just text; pictures or video would apply; for concreteness, let's say certain forms of illegalized pornography, or perhaps copies of the famous DNC emails publicized just before the 2016 election.) Would that document appear, in the clear, on the computer of dozens or thousands of people who allow their computers to be used for this Decentralized Storage? Remember, commonly-available hard disks exceed 10 terabytes these days. It is inconceivable that the actual owner of the storage node could reasonably ensure that this system could be "clean" of potential legal and jurisdictional problems. Yet, it is quite conceivable that the powers-that-be might want to harass participants in this Decentralized system? They could do so simply by storing a lot of in-the-clear challengable documents, monitoring their locations, and then legally harassing people whose computer contain that material. In principle, governments may not actually object to the presence of that data, Rather, they might simply use this as a nexus to harass people they otherwise object to. In other words, such harassment could be very selective. One solution (of course) involves encryption, but not necessarily the way you'd expect. Think back to the Vernam Cipher (aka "one time pad") https://en.wikipedia.org/wiki/Gilbert_Vernam What if a challengable document, call it "A", is essentially split up into two: Take random (or pseudorandom) string, the length of document "A", call it "B", is XOR'd (exclusive-or'd) with "A", and the result we will call "C", of the same length as "A" and "B". Then, instead of having document "A" stored, store both "B" and "C", but maybe not on the same storage nodes. Basically, an implementation of a one-time pad. Or, instead of merely two strings, this could be expanded, in principle, to any number. The purpose of this is not to conceal the ultimate information, but to split up that information so that no one operator of a storage node contains enough information that arguably violates the law in the jurisdiction he happens to be at. WIll this work? Laws can be changed, but it would be difficult for a law to prohibit someone from possessing data that could conceivably be combined with some other information, somewhere, in order to regenerate some banned document "A". Jim Bell On Tuesday, January 29, 2019, 11:40:27 AM PST, grarpamp <grarpamp@gmail.com> wrote: https://reddit.com/r/CryptoCurrency/comments/akyslc/decentralised_storage_co... https://i.redd.it/li4f40slbcd21.jpg
On 1/29/19, jim bell <jdb10987@yahoo.com> wrote:
https://en.wikipedia.org/wiki/Gilbert_Vernam What if a challengable document, call it "A", is essentially split up into two: Take random (or pseudorandom) string, the length of document "A", call it "B", is XOR'd (exclusive-or'd) with "A", and the result we will call "C", of the same length as "A" and "B". Then, instead of having document "A" stored, store both "B" and "C", but maybe not on the same storage nodes. Basically, an implementation of a one-time pad. Or, instead of merely two strings, this could be expanded, in principle, to any number. The purpose of this is not to conceal the ultimate information, but to split up that information so that no one operator of a storage node contains enough information that arguably violates the law in the jurisdiction he happens to be at. WIll this work? Laws can be changed, but it would be difficult for a law to prohibit someone from possessing data that could conceivably be combined with some other information, somewhere, in order to regenerate some banned document "A".
There was something called OFFSystem ... https://en.wikipedia.org/wiki/OFFSystem http://offsystem.sourceforge.net/ https://sourceforge.net/projects/offsystem/
Okay, sounds like the same idea, more or less. But I have an excuse for being 15 years too late: I was, uh, occupied at the time. Jim Bell On Wednesday, January 30, 2019, 9:11:31 AM PST, grarpamp <grarpamp@gmail.com> wrote: On 1/29/19, jim bell <jdb10987@yahoo.com> wrote:
https://en.wikipedia.org/wiki/Gilbert_Vernam What if a challengable document, call it "A", is essentially split up into two: Take random (or pseudorandom) string, the length of document "A", call it "B", is XOR'd (exclusive-or'd) with "A", and the result we will call "C", of the same length as "A" and "B". Then, instead of having document "A" stored, store both "B" and "C", but maybe not on the same storage nodes. Basically, an implementation of a one-time pad. Or, instead of merely two strings, this could be expanded, in principle, to any number. The purpose of this is not to conceal the ultimate information, but to split up that information so that no one operator of a storage node contains enough information that arguably violates the law in the jurisdiction he happens to be at. WIll this work? Laws can be changed, but it would be difficult for a law to prohibit someone from possessing data that could conceivably be combined with some other information, somewhere, in order to regenerate some banned document "A".
There was something called OFFSystem ... https://en.wikipedia.org/wiki/OFFSystem http://offsystem.sourceforge.net/ https://sourceforge.net/projects/offsystem/
On 1/30/19, jim bell <jdb10987@yahoo.com> wrote:
Okay, sounds like the same idea, more or less. But I have an excuse for being 15 years too late: I was, uh, occupied at the time.
A similar xor scheme here... http://monolith.sourceforge.net/ Shame they probably do not let people read, even by teletype. People usually better contributors to change when outside anyways.
On Tue, 29 Jan 2019 14:39:07 -0500 grarpamp <grarpamp@gmail.com> wrote:
so freenet is not listed there, and instead there are a bunch of shitcoins/scams like maidsafe - which has been in 'development' since forever.
On 01/30/2019 09:55 AM, Punk wrote:
On Tue, 29 Jan 2019 14:39:07 -0500 grarpamp <grarpamp@gmail.com> wrote:
so freenet is not listed there, and instead there are a bunch of shitcoins/scams like maidsafe - which has been in 'development' since forever.
Yeah, good point. Say what you want about Freenet, that rabbit just keeps going. Content gets split into blocks. Blocks are automatically encrypted in transit, and routed among nodes in a ~random way. Users can also encrypt local storage and temp files. And those are all key features of the best distributed storage systems. What distinguishes them is mainly usability as a filesystem. Such as FUSE, which Freenet just doesn't do. It's basically ftp. Also, Freenet in opennet mode is such a fucking deadfall for the clueless. It's not uncommon for people to install it, come across extreme child porn, and then freak. And the community seems generally hostile to the idea of obscuring IP addresses. However, all of these distributed storage systems are similarly vulnerable, more or less. You are potentially screwed if an adversary can 1) peer directly with you, and get your IP address; and 2) send you file fragments that are (even though encrypted) identifiable by hash or whatever. If you didn't encrypt locally, they may find bad stuff (even if only as temp files). And if you did encrypt locally, they may jail you for contempt unless you reveal the passphrase(s). So anyway, if you use any of these distributed storage systems, make sure that you peer only with people you trust, and make sure that you encrypt everything, locally and in transit. And if you must peer promiscuously, make sure that you obscure your IP address. Use a VPN, at least. And better, use a VPN plus Tor or I2P.
On Wed, 30 Jan 2019 20:51:44 -0700 Mirimir <mirimir@riseup.net> wrote:
However, all of these distributed storage systems are similarly vulnerable, more or less. You are potentially screwed if an adversary can 1) peer directly with you, and get your IP address; and 2) send you file fragments that are (even though encrypted) identifiable by hash or whatever.
Well by running freenet or something like it you are guaranteed to store and forward fragments of 'bad'(LMAO) files. That's the basic design of the system. And that means an 'adversary' like the american nazi govt can persecute any freenet user if they so choose. They don't even need to explicitly send parts of an 'ilegal' file to a particular client.
If you didn't encrypt locally, they may find bad stuff (even if only as temp files). And if you did encrypt locally, they may jail you for contempt unless you reveal the passphrase(s).
in other words, if you live in a police state you are fucked. There clearly is no crpytographic 'workaround' here.
So anyway, if you use any of these distributed storage systems, make sure that you peer only with people you trust,
that may be better but it's not too practical.
and make sure that you encrypt everything, locally and in transit. And if you must peer promiscuously, make sure that you obscure your IP address. Use a VPN, at least. And better, use a VPN plus Tor or I2P.
On 01/31/2019 04:04 PM, Punk wrote:
On Wed, 30 Jan 2019 20:51:44 -0700 Mirimir <mirimir@riseup.net> wrote:
However, all of these distributed storage systems are similarly vulnerable, more or less. You are potentially screwed if an adversary can 1) peer directly with you, and get your IP address; and 2) send you file fragments that are (even though encrypted) identifiable by hash or whatever.
Well by running freenet or something like it you are guaranteed to store and forward fragments of 'bad'(LMAO) files. That's the basic design of the system. And that means an 'adversary' like the american nazi govt can persecute any freenet user if they so choose. They don't even need to explicitly send parts of an 'ilegal' file to a particular client.
Yes, they can probably calculate hashes for fragments of any files. But generally, they do need to peer directly with you. Although some systems enable request forwarding, and nodes can see the names of indirectly connected nodes. But they can't see those IPs, just the IP of the node that handled the forwarding.
If you didn't encrypt locally, they may find bad stuff (even if only as temp files). And if you did encrypt locally, they may jail you for contempt unless you reveal the passphrase(s).
in other words, if you live in a police state you are fucked. There clearly is no crpytographic 'workaround' here.
Yeah, basically. Your only hope is not attracting attention.
So anyway, if you use any of these distributed storage systems, make sure that you peer only with people you trust,
that may be better but it's not too practical.
I agree. But it's what Freenet devs recommend. And not only is it not practical for many new users, it's not very reliable. Because you have no way to know which of your "friends" are state agents, or informers.
and make sure that you encrypt everything, locally and in transit. And if you must peer promiscuously, make sure that you obscure your IP address. Use a VPN, at least. And better, use a VPN plus Tor or I2P.
participants (4)
-
grarpamp -
jim bell -
Mirimir -
Punk