Mutual off site storage security? [RESOLVED]

[-=GGW=- $ol!d $n4>|e]

Hello, unsure whether this is best posted here or on OTW happy to move or remove and repost if this is the wrong section.

My brother and I are thinking about secure ways to set up off-site storage for eachother. The baseline is a raid 1 NAS in eachothers homes that is externally visible. (were not tied to any hard drive format etc but would like for the enclosures to be fairly cheap and have redundant / reliable error checking and notification of any failure)

We're both out of our element when trying to figure out how to encrypt the hard drives securely though. Ideally we would like to have a scenario where if one location is comprimised, those with access can not view the information hosted there as off-site storage for the other.

Any breadcrumbs to follow or suggestions would be welcome!

[bunder]

Once zfs gets all the bugs worked out for encryption and raw send/receive, it might be a viable option... but it requires zfs on both sides. I guess you could technically get the same done with tarballs and ecryptfs.
_________________

[msst]

[Hu]

Please describe your threat model in more detail. There are a few common scenarios:

1. "Compromise" means that a standard burglar powers down and takes the storage. He inspects it at a later date looking for personal information to use in furtherance of other crimes (identity fraud, blackmail, unauthorized access to existing financial accounts, etc.) or sells it to another criminal who will do so.
2. "Compromise" means that the location is raided by the government and the hardware is seized. Prosecutors later search the drive for information used to incriminate
   1. the owner of the hardware or
   2. the owner of the data
3. "Compromise" means an unauthorized individual gains remote (and likely undetected, at least for a few days) access to the fileserver, enabling him/her to upload/download any unprotected content at will.

Scenarios 1 and 3 are the most popular, but have very different solutions. Scenario 2 is a variant of scenario 1, but is harder to fight because of the non-technical resources that most governments can use.

[szatox]

I think the solution you want is "encrypt data on your end, send the encrypted version off-site"
This will keep you covered against most cases of compromised off-site, since access to the remote site only is not sufficient for the potential attacker to understand your data.
The downside is, encrypted data that can't be understood by the remote hardware can't be handled in any smart way, so you don't have many corners to cut for sake of efficiency.

[-=GGW=- $ol!d $n4>|e]

Apologies for the ambiguity of the question. Here's the scenario better explained.

The goal is to have storage that is

1) Off-Site
2) Publicly Discoverable
3) encrypted
4) efficient to synchronize and access each file / document individually
5) has reasonable warnings of approaching hard drive failure and redundant copies

5) The storage is protected / reasonably resilient with respect to.
- The case where the off site storage location is burgled
- The case where a bad actor obtains access to the off site storage location and network traffic between
- To some extent the case that the government seizes the off site storage.

Now I know because I reside in the U.S. its a false sense of security to think data is not obtainable by the government. I believe you can be charged for withholding evidence if you withhold the encryption key to encrypted data. There are also super computers the government may or may not have at it's disposal that may or may not be able to break standard encryption. However, being reasonable secure against external visibility would provide some barriers or protections in that the government force must both prove it is your storage beyond a reasonable doubt and prove that they have reasonable suspicion of the data there-in to warrant forced disclosure. Given the deterrence, it would be nice to be as protected against government intervention as possible

Also, I just want to add for the sake of it. There's nothing super nefarious about what I intend to store but I've become aware of how much self censorship I've been doing just talking through insecure channels to those I know online that the more secure I am in my data, the more true I'll be to my curiosities and ambitions. Just knowing my data is not safe affects what I store and that sucks!

Hopefully that clarifies things and thanks for the feedback so far. I've considered the encrypting locally and transferring to the remote destination however, in that instance. Talking at the scale of ~2Tb of data over consumer cable speeds, it's not very realistic / wouldn't be kept up to date in a reasonable time frame. I've considered hashing the file names and then encrypting the contents and sending each one of those but I'm unsure of what sort of security concerns that brings about or to what extent that weakens my encryption, It definitely lowers the starting entropy available for any encryption algorithm for each file.

I'm unaware of ZFS's buil't in encryption capabilities or the existing bugs but am digging into that now! For the most part I've stuck with ext4 prior to that reiserfs, prior to that ext3. I did a small stint of btfs but found it super unstable. So, as far as experimental fs are concerned, i'm very worried about data corruption.

[1clue]

I hate to be "that guy" but have you considered dropbox.com?

[msst]

For most of the things you want any simple remote unix box with (full-)HD encryption and a ssh installation will do. Most linux based NAS can even do this easily.

[gentoo_ram]

There is a package called 'duplicity' that is designed to do the type of encrypted off-site storage I believe you are looking for. I have used it in the past. It supports incremental backups as well.

http://duplicity.nongnu.org

[-=GGW=- $ol!d $n4>|e]

thanks all for your feedback i've ended up going with the solution for msst for my on site backup and using duplicity for offsite. Really helps a lot to get feedback from you guys about what is actually sane.