Hi Daniel, Possibly in one of these threads? (search term = 'cloud') http://marc.info/?l=opensuse&w=2&r=1&s=cloud&q=b hth & regards, Carl On Sun, 24 Apr 2016 16:17:54 +0200 Daniel Bauer wrote:

Hi,

some weeks ago there was a thread here about online backup/cloud storage providers. I'd like to read it but I can't find it, probably searching for the wrong words. Anybody knows where the thread is?

Thanks Daniel

(Need approx. 2 TB of online storage space, want to up/download locally en/decrypted files only, don't want to install closed-source software neither give access to my computer to apps of - in terms of privacy - untrustworthy organizations like google, amazon and the like... and hope to find some useful info in that searched thread...)

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Thanks Carl and Carlos. I've got home work to do now :-) Am 24.04.2016 um 16:42 schrieb Carlos E. R.:

On 2016-04-24 16:26, Carl Hartung wrote:

...

Hi Daniel,

Possibly in one of these threads? (search term = 'cloud')

http://marc.info/?l=opensuse&w=2&r=1&s=cloud&q=b

Perhaps, searching my local imap:

Matches both cloud and storage

Subject: Re: [opensuse] Backup Suggestions? Subject: [opensuse] (offtopic) how do you organize your data? Subject: Re: [opensuse] Off Topic - remote back up site in UK

-- Daniel Bauer photographer Basel Barcelona http://www.daniel-bauer.com room in Barcelona: https://www.airbnb.es/rooms/2416137 -- Daniel Bauer photographer Basel Barcelona http://www.daniel-bauer.com room in Barcelona: https://www.airbnb.es/rooms/2416137 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sun, 2016-04-24 at 18:07 +0000, Xen wrote:

Interesting point. A zero-knowledge backup provider should only be allowed to call itself zero-knowledge if its access platform (client) is made or verified (ideally made really) by a third party. Otherwise you have a conflict of interests. You cannot depend on some other party always being able to make the moral high choice. What if law enforcement forces them to change their client without notifying you

warrant canary

? If you have an independent client that is really fully independent and cannot be retracted by any party, meaning it would have to be open source, only then can you say you have a zero-knowledge encryption storage platform.

even if it's independently encrypted by a third party, why would you trust the third party?

In Linux we solve it by encrypting thing ourselves I guess :-/.

In the real world we solve it by encrypting it ourselves, with our own private parameters, but using some open encryption software designed by third parties we trust, since we don't have the expertise to implement encryption software ourselves without introducing bugs. Cheers, Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Dave Howorth schreef op 24-04-2016 20:40:

On Sun, 2016-04-24 at 18:07 +0000, Xen wrote:

...

Interesting point. A zero-knowledge backup provider should only be allowed to call itself zero-knowledge if its access platform (client) is made or verified (ideally made really) by a third party. Otherwise you have a conflict of interests. You cannot depend on some other party always being able to make the moral high choice. What if law enforcement forces them to change their client without notifying you

warrant canary

...

? If you have an independent client that is really fully independent and cannot be retracted by any party, meaning it would have to be open source, only then can you say you have a zero-knowledge encryption storage platform.

even if it's independently encrypted by a third party, why would you trust the third party?

...

In Linux we solve it by encrypting thing ourselves I guess :-/.

In the real world we solve it by encrypting it ourselves, with our own private parameters, but using some open encryption software designed by third parties we trust, since we don't have the expertise to implement encryption software ourselves without introducing bugs.

Cheers, Dave

I don't know what you're arguing against. What you say is completely in line with what I say. About warrant canary, I didn't know about that, thanks. Yet that doesn't feel like any real safeguard, it would either have to be specific to your person, and/or it would need to be visible to you at all times. Further more although it seems legal, that really seems like a breach of the law. The message would need to be posted anew every day. Removal of the message would in theory need active participation, theoretically becoming a problem if law enforcement was really strong there. Furthermore if they really took over they could post the message themselves. Wikipedia tends to agree. "In September 2014,[21] US security researcher Moxie Marlinspike wrote that "every lawyer I've spoken to has indicated that having a 'canary' you remove or choose not to update would likely have the same legal consequences as simply posting something that explicitly says you've received something."" "In March 2015, after Australia outlawed warrant canaries, computer security and privacy specialist Bruce Schneier wrote in a blog post that "[p]ersonally, I have never believed [warrant canaries] would work. It relies on the fact that a prohibition against speaking doesn't prevent someone from not speaking. But courts generally aren't impressed by this sort of thing, and I can easily imagine a secret warrant that includes a prohibition against triggering the warrant canary. And for all I know, there are right now secret legal proceedings on this very issue."" I don't mean independent encryption by a third party and I never said any such thing. I was talking about a third party app, the ones you mention as well. That real world you mention also contains SpiderOak, which cannot be verified to be truly zero-knowledge because its client is (still) closed source. What I mean is that any platform that provides a method or tool to explicity access the data, should not also be the one that enables or designs, introduces or manages, the encryption component to said client. What I mean is that the user interface for the program that is the client to the network, should not be capable of learning about the encryption key to begin with. In the real world, people use services such as this. What you say is correct, but you forget that there are also people using such services with such clients that cannot really be fully trusted. If the client does not actually access the encryption keys, for instance because it uses an encryption plugin that has its own user interface or way of interacting with the user or its filesystem where possible keys are stored, and it if it is theoretically not possible for the client to interface or listen in to that, then you have a zero knowledge solution, but otherwise you don't really have it. Of course if you use your own tools to encrypt, this thing is going to be true. However these clients typically have access to the unencrypted data. That is something that should not be allowed. It is the encryption engine that you control that should access the data and nothing else. This is the modular design you need if you are going to design such a tool for a commercial deployment, and still consider yourself zero-knowledge. Unlikely we will see this but in principle it is not hard or impossible. Yes, the thing you would use is those 3rd party trusted encryption solutions you mention. I was not talking about what Linux hackers do. I was talking about people using commercial solutions on e.g. Windows or any other platform (including Linux). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Daniel Bauer [04-25-16 03:25]: [...]

- The only reasonable solution (to my eyes) is to rent pure disk space somewhere (I found for example https://www.hetzner.de/gb/hosting/storagebox/bx40 ) and to upload self-encrypted files. I guess a program like https://cryptomator.org/ can make that task easier.

I wasn't going deeper into the matter because in the end I decided not to use any online storage. Not because of lack of offers, but because my files are too large. I was dreaming of an online-solution to backup photo shootings, which are between 5 and 40 GB. If my math are right, with my current internet connection the upload of 1 GB would take about 215 minutes (speed test says I have 0.62mbps, telefonica, Spain) and en route any upload would take way longer than the battery of my laptop works. I admit, I took the large way to come to this conclusion :-)

Not quite as handy but a return to the old "sneaker net" might substitute. Largish usb3 drives are widely available. Use one for backup and carry off-site as convenient. <comment> "Better than nothing" </comment> -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Daniel Bauer schreef op 25-04-2016 7:25:

Just to give feedback about my "home work":

- all cloud services that are easy to find (let's say top 25) use their proprietary clients, which means you give full root access to some company. It's like giving the key to your house and car to somebody you don't know. In fact, it is giving complete access to bank accounts, credit cards, tax declarations, book keeping, clients list and private stuff.

Even with "client side encryption" the proprietary, closed source program still has root access plus internet connection and this is such a high risk that I really wonder why somebody uses such programs....

Thank you for your feedback. That was what I was implying as well. Maybe we can one day design a modular framework that allows clients with internet access and logic to perform the upload/sync, to basically be a plugin to another application that is just the GUI to such a backup system. This GUI would then use an encryption solution of your choice. The APIs would be such that only encrypted data (or non-encrypted, as you may want) is ever presented to the network component. It would require a minimum set of features that takes care of increments and versioning. As well as the study of proprietary solutions to find the right feature set perhaps. In a zero-knowledge solution increments are not possible unless they are created prior to encryption and stored on the server in separate files. Most encryption schemes also prevent files that are encrypted twice, to be able to make use of rsync's optimisations. Just saying this because updating large archives is a challenge in this sense. Any such scheme requires availability of the original archive, or information about its contents. If you are truly going to sync with the remote host, the protocol that the platform uses would need access to time stamps and filesizes at the very least, as well as filenames. Could be interesting to design it.

- The only reasonable solution (to my eyes) is to rent pure disk space somewhere (I found for example https://www.hetzner.de/gb/hosting/storagebox/bx40 ) and to upload self-encrypted files. I guess a program like https://cryptomator.org/ can make that task easier.

Yeah seems the only option at present.

I wasn't going deeper into the matter because in the end I decided not to use any online storage. Not because of lack of offers, but because my files are too large. I was dreaming of an online-solution to backup photo shootings, which are between 5 and 40 GB. If my math are right, with my current internet connection the upload of 1 GB would take about 215 minutes (speed test says I have 0.62mbps, telefonica, Spain) and en route any upload would take way longer than the battery of my laptop works. I admit, I took the large way to come to this conclusion :-)

I've had the same problem. What makes it harder is that you cannot rsync update an encrypted archive. For photoshoots maybe no problem. For real system or changing dataset backups, a big problem. That means you maintain the backup locally as well prior to encryption and create differences/increments, or do the same by only keeping a summary contents file, such as tar -g. But then you also need the tools to recreate the original archive from the increments. Anyway, not exactly what I wanted to write, but I'm a bit too sick to be thinking of essential features right now ;-). Regards. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2016-04-25 13:56, Anton Aylward wrote:

When I figure the Risk of the house burning down I realise that I need off-site storage for my backups, mag tape and DVDs. Who am I going to trust? Iron Mountain, a corporation that might go bankrupt or is (potentially, as are all corporations) corruptible or could (silently, since it doesn't use 'canaries') roll over and surrender in bulk as a result of court order or presidential directive, or trust a bank for a safe deposit box?

Store your backup in a fire resistant (insulated) in the basement? Buried in the garden? If you have it, that is. You can even connect by cable to it without removing from the box :-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2016-04-25 14:27, Anton Aylward wrote:

On 04/25/2016 08:09 AM, Carlos E. R. wrote:

...

Store your backup in a fire resistant (insulated) in the basement?

LOL! Underneath he condo's underground parking, perhaps?

Ah! But I thought that all the people in the USA lived in those big and beautiful individual houses. Except for those living in log houses out on nowhere. LOL! :-) You could rent a storage room on the next condo, and run a cable roof to roof. A decade or two ago, we had "illegal" cable TV service that way on some cities here: running the cable roof to roof. At the time there were only 2 tv channels, which soon became 6. No cable anywhere (officially). Just a tiny bit more seriously, each building could use some space on the next building, and run a backup server there (on LAN, not internet). Mutual benefit. You only need to find interested parties ;-)

...

Buried in the garden? If you have it, that is.

Careful, have to find somewhere away from the buried bodies :-)

That would be Felix the cat. :-)

...

You can even connect by cable to it without removing from the box :-)

No, I don't think so. Connectivity means it can be hacked.

Use fibre, and point to point encryption.

A Risk Analysis not only considers the threats and probabilities, but also the cost and lifecycle. A backup buried under the rubble of a burnt building is going to be inaccessible for some time;

True, but it should survive.

under some conditions it may even be irretrievable. Directions for 'buried treasure' are notorious in their ability to be misinterpreted.

:-)

I think there's a good reason that bank safe deposit boxes rank well as a result of a neutral Risk Analysis for individuals and SMBs, and companies like Iron Mountain for larger businesses.

Bank boxes... well, there is that. Store your backup hard disk in there. Rotate once per fortnight. Me, I do have an enclosed garden. I could setup a NAS out there. I haven't bothered. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)