Am Freitag, 16. September 2016 20:11:48 UTC+2 schrieb Chris Laprise:
> On 09/16/2016 09:58 AM, wrote:
> > Am Freitag, 16. September 2016 09:52:40 UTC+2 schrieb Drew White:
> >> If they can get access, whether encrypted or not, it means it's insecure.
> >>
> >> Encryption just takes time to break.
> >>
> >> If you have encrypted files, encrypted with a STRONG password THEN a 2048 
> >> bit cypher, THEN it will probably take about 6 months to decypher it and 
> >> get the data out.
> > I think you need to educate yourself a bit on the topic of encryption. 
> > Encryption is secure if you use it correctly. Too secure actually, it's 
> > much more straightforward to simply torture the information out of 
> > someone...
> >
> > And unless there is a backdoor in AES-256 (which why ideally you would 
> > always use a combination of several ciphers), it is technically and 
> > theoretically unbreakable if you used a 256-bit random key. It's much more 
> > likely that someone will social engineer his way to the data. Matters are 
> > entirely different with current public key algorithms, which may very well 
> > be broken via quantum computers, so I wouldn't bet my money on that 
> > horse... On the other hand those are not the algorithms you use for backup 
> > anyway.
> Ssh may add some security against things like MITM attacks, but you have 
> to trust who you're connecting to as well. From a Qubes standpoint it 
> matters because the non-crypto parts add a bit more complexity, and 
> adding rsync adds substantially more. SSHFS is probably more complex and 
> attackable than both of those together. That, along with TCP/IP itself, 
> is attack surface.
> The way you're describing it makes it seem like any successful attack on 
> one of those components in the dropbox vm could be repeated against the 
> encfs vm. I think most Qubes users would consider that too risky for 
> handling sensitive info, or interfacing with highly trusted vms. It also 
> means you need to keep extra copies on your drive.
> What I described involves no extra copies, and if the dropbox vm becomes 
> compromised then there is very little it can do to attack your other vms 
> that are using the data. Ssh between the dropbox vm and dropbox is still 
> a good idea in this case, and you might even want to use SSHFS or 
> whatever else would allow you to map disk images in that vm. The dropbox 
> vm could be considered 'red' and your client vms (which encrypt and use 
> the data as mounted disk image) could be 'blue' or whatever. I think 
> this is worth a try because its more secure and probably less complex 
> than what you're suggesting.
> Of course, with Qubes its up to the user to weigh the risks and make the 
> decicions. Good luck...
> Chris

I don't disagree with you...

But your approach has several usability downsides. Although I am reconsidering 
this, since in the end I might be able to live with a "once per hour" dropbox 
sync which would open many doors for options like the ones you described.

Thanks :) I will think about it and try it out.

You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
To post to this group, send email to
To view this discussion on the web visit
For more options, visit

Reply via email to