Am Freitag, 16. September 2016 20:11:48 UTC+2 schrieb Chris Laprise: > On 09/16/2016 09:58 AM, mara.kuens...@gmail.com 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 qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e7d495ec-116c-4079-bc54-2266d7c4f286%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
