This project has moved and is read-only. For the latest updates, please go here.

Veracrypt with online cloud storage

Topics: Users Discussion
Jan 6, 2016 at 11:09 AM
Hi all,

My partner and I use Veracrypt on our separate laptops and there are a few folders that it would be really convenient to share. I am considering using sync.com as both backup and sharing.

This is the configuration I am considering:
  1. Mount an encrypted file container on each laptop as drive M.
  2. Create a sync.com account, create a folder in the secure storage space online, let's call it: 'NogginsData'.
  3. Install the sync.com Windows app on both laptops.
  4. Nominate drive M on each laptop as the location for the sync folder and create a folder called 'NogginsData' inside each sync folder.
If my understanding is correct, then:
  • files in the NogginsData folder on each laptop are encrypted thanks to Veracrypt;
  • the synced files on-line are encrypted thanks to sync.com;
  • transfers between the laptops and the online storage are encrypted thanks to sync.com.
So far I've tried using the Veracrypt/sync combo on my laptop and it seems to work OK without any error messages (after all, when the sync.com app starts in Windows, the nominated location for its sync folder doesn't exist until I mount the Veracrypt container as a drive).

Questions:
  1. Apart from all the usual concerns about files in RAM, cache, Windows making event logs, etc, are there any security vulnerabilities particular to this combination?
  2. Are there likely to be any performance hits (I haven't noticed anything yet, but then I don't have the facilities/knowledge to do proper measurements)?
  3. Any other observations/criticisms?
Thanks!
Jan 8, 2016 at 10:51 AM
  1. sync.com can see the data unencrypted
  2. As with all sync solutions I think one might run into problems if two people edit the same file at more or less the same time
    3.You have several possible point-of-failures for the encryption (VC, sync.com App, sync.com itself)
Jan 9, 2016 at 8:19 AM
Thanks for the reply, RNfC.
  1. According to sync.com, the files uploaded to their servers are encrypted on my computer, so they never see unencrypted text. The Sync.App can and of course it's not Open Source.
  2. Yes, that is a potential problem. It's very unlikely to occur in my particular context but it is a risk, and Murphy's Law, and all that. I believe that sync have some kind of versioning control, but whether they lock files which are open in one of the accounts I don't know.
  3. True, but hard to estimate the risk. I already put my trust in VC, although I'm not 100% sure I have completely eliminated leakage via RAM, Windows logs, etc.
Jan 9, 2016 at 10:17 AM
Noggin, if you are "normal" user who doesnt care about encryption, i would say using sync.com is perfect for your situation. If you are however using VC and are still worrying for leakage via ram, logs, dumps, etc... then using sync.com is absolutely out of question in your situation :)
Jan 9, 2016 at 10:32 AM
Thank you, Alex. I guess I'm somewhere in-between ...

I do care about encryption but my threat-model is about mundane things like malware or devices being lost or stolen and not wanting my personal life being raked over by some crook or other. I don't anticipate being targeted as a specific individual but don't exclude the risk of general malware getting into my PC and having a look around.

I've done some searches for reviews, but they mostly seem to date from when sync.com first appeared on the scene. This one is more recent though and seems very favourable. Can you suggest any reviews which are more critical, or be more specific about the risks of using sync.com?
Jan 9, 2016 at 6:17 PM
Hi,
  1. Encryption won't protect your private data from malware (when mounted).
  2. They look like they are taking privacy seriusly at sync.com, but I'd never trust any third party. I don't even like that I have to believe veracrypt and especially microsoft windows, which is the weakest point ;-)
If you really need your data stored elsewhere, I'd pick sync.com (or any other cloud except google) in combination with encfs (or encf4win on windows), but share them only encrypted data. Downside of encfs is that your data eat space twice, because one folder is with data you want to protect and other is their encrypted mirror, which you share.
Jan 10, 2016 at 5:35 PM
Hi testoslav,

I only mount the Veracrypt container when I need it, but I can be a bit slapdash about _dis_mounting it promptly. New Year's Resolution.

I take your point about 3rd parties and at root I suppose that's what motivated me to pose the questions above, although I am also just curious about how well the Veracrypt/sync.com combo might work.

The thing is, if I don't use a solution that includes (encrypted) synch, then I might just as well continue what I'm doing now and keep the laptops synched by exchanging encrypted files (not using encfs, but similar). It's relatively tedious to stay disciplined enough to keep all files up-to-date but that's a separate problem of maintaining good practice.
Jan 10, 2016 at 6:21 PM
Just from wording: Just because the data is encrypted on your pc and they dont get the plaintext, that does not mean that your encryption key is not cloud-hosted.
I dont know about sync.com and I will neither say they are trustworthy nor that they are not.
Jan 10, 2016 at 8:05 PM
Just from wording: Just because the data is encrypted on your pc and they dont get the plaintext, that does not mean that your encryption key is not cloud-hosted.

Mmm. Good point, thanks.

I dont know about sync.com and I will neither say they are trustworthy nor that they are not.

Thanks again. Point taken.
Jan 15, 2016 at 2:07 PM
Edited Jan 15, 2016 at 2:10 PM
Why on earth would you want to use he internet to share your encrypted data when you can just create a local peer to peer network? unless you both live in different places and want to share, and in that case your going down a different path, with many different types of data leaks and attacks, and once your data leaves your computer it is now in the hands of a cloud based company (providing it gets there) and its not uncommon for that data to be accessed without your consent or for it to be deleted by attackers.

All local data is encrypted, but what use is that if a public hosted server has encrypted copies and it gets attacked through an exploit? heartbleed anyone? the confidentiality is gone.
Jan 15, 2016 at 2:57 PM
We are not always in the same place, and when we are, it's often the case that only one computer is left on.

Sync.com claim - and it's true that this has to be taken at face value - that files are encrypted/decrypted on the users computers and that they never have the passwords for that encryption. Their claim (as I linked in my 2nd post) is:

"Zero-knowledge" means we absolutely cannot access the encrypted data stored on our servers. Your data is completely safeguarded from unauthorized access, which is the only way you can completely trust the cloud.

You wrote: what use is that if a public hosted server has encrypted copies and it gets attacked but did you mean unencrypted copies?

Sync.com again (about 1/2 way down the page):
2048 bit RSA, 256 bit AES, SSL and TLS encryption
Two-factor authentication
Deletion recovery and file version history
Remote wipe and remote device lockout
Share controls, permissions and user administration


Evidently the encryption is only as good as the passwords: but then I choose them. Sync.com offer deletion recovery.

As I said to randomnameforcode, the integrity of sync.com has to be taken on trust, but since they've been around for a couple of years and with a claimed 100,000 customers as of Sep 2015, any problems will soon come to attention.
Jan 15, 2016 at 8:58 PM
Edited Jan 15, 2016 at 9:36 PM
Data in transit will use SSL/TLS with certificates = asymmetric encryption, data in transit should be secure, and data at rest will use AES = symmetric encryption, of course you could also send data already encrypted too which if intercepted should be ok.

Attack: Possibilities depending on the setup:

1.If your entering sending a password over an SSL/TLS connection to decrypt the data otherwise you won't have access to it over the net (even if decryption is done on your system you still need to send the password) which sounds secure, as the connection is encrypted, but not quite, all it takes is an exploit like heartbleed http://heartbleed.com/ or you could use that exploit to get your password.

The problem is many websites still use OpenSSL for SSL/TLS as its free (unlike BlackboxSSL/TLS) and many servers are still left unpatched today.

Anyhow even if no exploit was used, SSL/TLS encryption strength is deliberately weakened for the mass surveillance systems in place, so with all the above in mind that's what I meant when I said " what use is that if a public hosted server has encrypted copies and it gets attacked"

2.If the data is downloaded to your system first and then you decrypt it on your system then your password will be fine unless the server gets hacked and sends out malware, the server will always have a copy of your shared data and every public facing server is vulnerable to attacks of all sorts and as mentioned earlier your password could be got through a hacked server sending out malware in the form of updates etc, and your system already trusts the sync app, and you prob installed it logged in as admin, that's half the battle.

It's entirely up to yourself, but as you know, nothing, absolutely nothing is safe on the Internet, thousands of zero day exploits are taken place now and most have no idea.
Jan 15, 2016 at 10:03 PM
OK Paul, you make a lot of points that I will need time to digest. I won't pretend that I understand everything that you say, but I will state that it prompts me to learn more about what you are describing, so thank you for your input, which I respect.

(Sigh) so much to learn, so little time.

Thanks for taking the time to reply. Appreciate it.
Jan 15, 2016 at 10:09 PM
Folks, it's over a week since I started the thread and you've given me much food for thought. My original queries were 'open questions' which did not expect definitive answers. I appreciate very much the responses that you have made: thank you all.

So I propose to close this thread with this post. I'll wait a few days in case anyone wants to post a follow up, but then I'll mark this reply as the 'answer' to my question. (If I'm allowed that is: I wonder if I'll be blocked from answering my own question? We'll see.)

Thanks again and good 2016 to you all.

Rob
Jan 16, 2016 at 11:42 AM
Just one thing came to my mind - if you store your encrypted volume on a cloud, you cannot believe in a change of the password, because of older copies. When you change password, only header is modified, so if somene has copy the old container and knows the old password, he can unlock your new container without the knowledge of the new password, because your password only protects header with "internal password", which protects the data (pardon my french if it is too simply said, I don't know the correct terms).

So when you work with group of people and one becomes distrusted, you should create the whole new container with a new password.

You will also have to avoid 2 or more people opening the same container, or you will get many confilicted copies. This is the hardest part, that's why we abandoned the idea of sharing the vc container and we use encfs.
Jan 16, 2016 at 12:25 PM
If I understand you correctly you are discussing the possibility of storing the entire container file in the cloud, which is not what I am proposing. It would be very bandwidth heavy to synch a container of several GB. So it is individual files that will be synched, files that are normally stored inside containers on our laptops and only exposed to view when the container is mounted as a drive.

But your point about changing passwords is a powerful one. I think that existing files (including earlier versions) on the sync.com servers might get decrypted then re-encrypted when the password changes - but I don't know. I'll try a few experiments and/or ask support at sync.com.
Marked as answer by Noggin on 1/18/2016 at 12:20 PM