Re: [qubes-users] Special (Secure) Browser Frontend for Qubes?!

2016-11-02 Thread mara . kuenster
> Does your proposal really harden agains a real threat, or is it
> something that should be done only because it could be done?
> 
> Btw, thank you for taking the time to write us your proposal and
> replying to our e-mails.

Well honestly "proposal" is probably too much credit for the time I spent on it 
so far and I mainly wanted to probe for the idea more. I think I am going to 
write a true proposal that can actually be reviewed and your input definitely 
helps to guide that effort, which is also why I asked that question in the 
first place.

And I am not actually sure I will address a threat model, since it doesn't 
really do more than you can do manually. It is really more about regaining the 
convenience while maximizing the additional privacy and security Qubes OS 
technically provides, you see... But I agree that it is required to be much 
more specific and clear but I can't do that so quickly in a mail, so I will 
take this conversation and address the issues raised in a more structured 
manner ^^.

Thanks & Cheers

-- 
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/4c300108-99c2-46db-b68d-981ce97cea1b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Special (Secure) Browser Frontend for Qubes?!

2016-11-02 Thread mara . kuenster
Hi Simon,

> several AppVMs, each one dedicated to a different activity, or as I 
> prefer to refer it myself: to different sensitivity levels.

See my reply to Alex, maybe that explains why this is exactly what I was 
talking about ;).

> - You may have a dedicated Firefox instance still having the infamous 
> Flash plugin installed when you need to access some websites requiring 

Yes but this could and would be all included in this dom0 browser interface.

> - Use (X)KeePass in a separated, isolated and dedicated AppVM. I suggest 
> you to create a "Web" or "Firefox" group, and then create a different 

I am using UNIX pass, but it has the same flaw. If you copy passwords this way 
they won't automatically get purged from the AppVM, which under the assumption 
that any AppVM is completely compromised at all times, is not much of a big 
deal, but still it would be nicer if the password was cleared or even better 
never copied to the clipboard...

Which is why my idea would be to host Mozilla Sync Service in each AppVM and 
the let the dom0 browser fill this Sync Server with the passwords belonging to 
the corresponding identity... 
 
> website: you will *not* open this link in the same AppVM but instead 
> copy/paste it in your "Random surf" AppVM. Would this site be malicious 

Yes but people WILL click the link. It's not a sane assumption to make. Besides 
it is incredibly annoying to operate this way. I am not some prime target of 
the NSA ^^, and I doubt many of the people using qubes will be... So you want 
to be safe, but you still want the convenience... The right way is to block the 
link, unless it refers to a white-listed domain for this identity. Or even 
better, pipe it back to dom0 and open it in a new tab & AppVM under the right 
identity... (this kind of integration is what I am proposing)

> password database is to first hack the forum, and use it as a pivot to 
> then be able to hack your computer and get access to your file system. 

How he does it is basically immaterial to me as I assume that all AppVMs are 
evil all the time. The point is to separate them properly so only one identity 
gets compromised. I want to add that it is generally unlikely that a disposable 
AppVM with the right configuration will actually be compromised, but it helps 
to assume them to be to get a better picture of the impact it would have and to 
minimize that impact.

> (https://addons.mozilla.org/en-US/firefox/addon/secure-login/) so 
> Firefox does not dumbly automatically fill any password field without 

Yes this looks good.

> like uMatrix or NoScript which allow to better control third-party 

Thanks for uMatrix, I didn't know that one. But yes this is pretty much what I 
imagined also to happen, just in dom0 (which is more trustworthy to me), not in 
an AppVM.

> It *may* be possible to implement a way to handle different AppVM in 
> different tabs instead of different windows, but I'm not sure to see any 
> real advantage of this.

The advantage is the same as going back to IE6 times when each tab was its own 
window and having windows with several tabs in addition to this madness. I 
don't see how you can not see the advantage of having all browser tabs over all 
AppVMs organized in a dom0 browser interface as tabs in comparison to having 
tons of floating windows with sub-tabs each ;).

> instance, personally I set it to not display reduced windows in the 
> Alt-Tab menu, so I can focus on the window I am currently working with.

I don't think any of those suggestions really helps with the problem. All in 
all I think Qubes OS in general lacks a good UI for what it is doing, but I 
also understand that you have to start somewhere. But in the end the way Qubes 
does AppVM and identity management at the moment is truly terrible, but it 
works. All I want to do is to come up with a plan to improve it ^^.

> be useful to have them volatile on a day-to-day basis, and turn them 
> non-volatile only to update Firefox's modules or save a change in its 

I think the Mozilla Sync Server could be of help here...

> To be honest I did never investigated this, I'm not sure what the 
> concrete threats there are. 

Are you so sure that your AppVM doesn't have an unique fingerprint that 
potentially could be exposed via a malicious website, browser extension or the 
browser? In that case, even using the same base template for disposable VMs 
could be a privacy disaster (I am not sure Qubes OS has taken any steps, like 
maybe "Tails", to actually mitigate fingerprinting in disposable VMs)

On top of that have you ever tried to use Panopticlick? Even tails gets more or 
less uniquely fingerprinted primarily via the non-standard browser window size 
when it is maximized and also because it seems to apply some uncommon browser 
settings that maybe only tail users have...

> UUID you really should just use the same UUID as a lot of other people 

That requires you to know the UUID, also UUID was more a token for 

Re: [qubes-users] Special (Secure) Browser Frontend for Qubes?!

2016-11-02 Thread mara . kuenster
> And that's why you can use many appVMs in the first place. You share the

But that is not the point. First of all, unless your life depends on it, it 
will be very unlikely that you are actually paying enough attention to where 
you use which identity. A click on the wrong link can already screw it up 
because then site X read the tracking data placed on site Y and site X 
shouldn't know about what you were doing with Y... So you need some sort of 
white-listing to technically prevent those mistakes. Yes this can be done in 
different AppVMs and that is exactly what I am proposing here. It's about 
making what you describe much more convenient without a single drawback in 
security.

> There's little actual reason to use a hard-separate identity for each
> and every web service you visit; first because they don't usually talk


> to one another (i.e. amazon does not ask facebook for your info, nor
> does this happen the other way around) 

Um, that is a bold statement, do you have any data to back that up? Maybe 
Amazon indeed doesn't talk to Facebook (yet), but no one is stopping them 
either. Facebook definitely has an interest to read your Amazon visits because 
this way they can link your true identity to your fake profile... for instance.

> are, in fact, the very same entity (fb and whatsapp, gmail and youtube).

True, and for those you will want to use the same identity (it get's 
complicated quite quickly which is why I am proposing to aid the user with this 
chore).

> Third because you usually want to present a "brand" identity of yourself
> around the web. Think of your personal blog or github account presented
> on your linkedin profile: this is a reinforcement of your "brand"
> identity, so you would like to share the connection between your github
> and your linkedin identities.

Maybe, but here we have the same issue again. I have other things in my head 
than trying to remember which sites shares what data with whom and which 
idenity I have to use where and which AppVM to start for it, it's just 
insane... This needs to be much simpler.

> And that's actually the point why I'm replying to your e-mail; this is
> an idea as bad as it gets. The main reason why dom0 does not have
> networking, and should not have, is to prevent exposing data on *all* of
> the VM at once. As a side effect of this, the less software there is on
> dom0 the better.

I think you entirely misunderstand my proposal or maybe I wasn't clear enough. 
My proposed "dom0" browser has no network at all. In fact, it can't do anything 
you couldn't do manually already. The point is to automate it. This dom0 
browser frontend will know which identity belongs to which domain and which 
AppVM should be used for each identity and what your passwords & cookies were. 
It also feeds this data to each AppVm on startup so they can completely be 
disposable... The "real" browsers still run in AppVMs.

> TL;DR: first, do you really actually need to separate each and every
> identity you use? second, once you realize that many identities can
> co-exist (and indeed, sometimes you would like this to happen) do you

What do you mean by "co-exist"? If I use them at the same time in the same 
browser/VM I might as well just use one single identity because there is no way 
to know if either of them wasn't compromised or linked in ways I didn't want. I 
don't see how identities can co-exist (I am also not talking about sign-in 
data, I am talking about fake "me"'s, fake people so to speak who consume 
services to protect the real identity; I simply see no use case of why you ever 
want to share identities within the same AppVM or browser/site).

> really need that many isolated VMs? third, why would you need to move
> this complexity in dom0?

Because dom0 is the only place where this can meaningfully exist. Think of it 
as a different way of organizing the AppVM windows (not in the XCFE panel's, 
but instead as real tabs in a dom0 browser) and a lot of infrastructure code to 
help you with identity management.

Cheers

-- 
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/1f43fe6b-39dc-4898-ba5b-b066c4e1be84%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Special (Secure) Browser Frontend for Qubes?!

2016-11-01 Thread mara . kuenster
Hi,

I am using Qubes daily for a while now. One thing I think is really missing is 
some sort of identity management. This is most visible when browsing. You shop 
something on Amazon, then go to check some Facebook updates and look at 
WhatsApp. Then you browse Hacker News click on this link and that link, end up 
on Wikileaks by accident then look at which club to visit in the evening... Yes 
this is shit.

But convenience often wins over security/privacy. Not only do you have to 
assume that all sites you visit within the same VM knows everything you did in 
there, but also you have to assume they know all the passwords for all the 
other sites you visit there and basically have full control over that VM. If 
you don't assume that, then why are you using Qubes in the first place...

I think what would solve this dilemma is a custom dom0 browser layer. The way 
this can work is as follows:

* Each identity consists of white-listed domains and HTTPS certificates (like 
amazon plus all its garbage), bookmarks, history, it's own password & auto-fill 
store and basically everything else like it's own cookies and the works.
* Trying to visit a non-white-listed website will simply not work without 
switching identities properly or using a special disposable identity 
* Two identities are never used on the same VM
* You always use a new VM for each tab (there is potential for optimization, 
like sharing a VM per identity as long as this identity has at least one tab 
still open)
* Each VM is disposable (no home file system sharing) and get's the 
corresponding identity auto-copied on boot (only the essentials for Firefox)
* The browser gets installed after launch, so no kind of tracking can take 
place here via installation UUIDs etc.

So the core feature of this dom0 browser is basically identity management and 
the usual tab-based browser gui with history, settings, etc. But in contrast to 
what we have now, this dom0 browser will also manage the VMs that run the 
actual browsers and blit their page view into its dom0 tab.

Is there anything like that under development? Or how would you solve this 
issue?

Cheers

-- 
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/22581429-6e04--a8db-e287d122765b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Qubes on a dedicated server

2016-09-30 Thread mara . kuenster
Am Freitag, 30. September 2016 15:05:31 UTC+2 schrieb Patrick Schleizer:
> Does anyone ever try this?
> 
> Did it work? Any experiences?

Why would it not work? But the question is rather why use Qubes OS?
If it's a dedicated server, you should look into XenServer, which basically can 
be thought of a Qubes-Server OS ;) and is widely deployed in data centers 
across the world.

-- 
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/010cb2bb-73e7-483a-8cad-425dcb42767e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Switching from UEFI to BIOS after installation...

2016-09-25 Thread Mara Kuenster
Hmm yeah with that I managed to boot through BIOS mode, unfortunately the VMs 
don’t start (randomly, different ones fail on each boot attempt). So basically 
something seems to go wrong. The disks get decrypted and I can login with the 
manager etc. but the system is more or less a complete failure ^^. When I go 
back and boot in UEFI mode, everything works just fine…

This seems kinda odd xD.


On 25/09/16 23:27, "Marek Marczykowski-Górecki" 
 wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, Sep 25, 2016 at 02:22:49PM -0700, mara.kuens...@gmail.com wrote:
> Hi,
> 
> I just discovered that AEM needs a BIOS boot. 
> Is there a way to install grub into the MBR of an USB drive after Qubes 
was already installed in UEFI mode? If so... How? Like any other Linux 
distribution or does Qubes need something special?
> 
> I would want to avoid re-installing Qubes if possible.

Just installing grub2 package and calling grub2-install should be
enough. At least in theory...

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJX6EEvAAoJENuP0xzK19cshs0H/3YSRCfl4eTGRiZaYgor1cOb
lLfywbI5WMlJnICZkvpj5cwd3Ar1MxfEAHkWv+yvqPq9YH+80yxYPv3QyyrMsA8t
IfwWJXLFc0Av5L3wkO5CN7BrKdLlbQf4J/LAb/QEWpbTKz9odLxoXLPkuNOKgm3/
r5yWbkQOisGuHiK66ao6Hdn1pCCthLub1+4dA/vtSzai/37rv5LFOU1TbwLktd+J
JmglqpA5WUNqmgX2QtzILWTOhdeHPb0CepGv61x58g2SP4OqOVUKs6cqETZkjLCc
0BX8haa/D8/gWoFjU3/+Af4xKBWom8uWJG7H0dBee7e6pbUqtigYoQGGWixeeFc=
=QEHr
-END PGP SIGNATURE-




-- 
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/BCDEB0A1-CE53-477C-B439-E101059087BA%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Switching from UEFI to BIOS after installation...

2016-09-25 Thread mara . kuenster
Hi,

I just discovered that AEM needs a BIOS boot. 
Is there a way to install grub into the MBR of an USB drive after Qubes was 
already installed in UEFI mode? If so... How? Like any other Linux distribution 
or does Qubes need something special?

I would want to avoid re-installing Qubes if possible.

Thanks!

-- 
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/9bc6c0b8-bc24-4b1b-b39b-26bae14004d1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Encfs + Dropbox: How to keep your cloud files secure?!

2016-09-24 Thread mara . kuenster
Am Sonntag, 18. September 2016 04:52:52 UTC+2 schrieb rac...@gmail.com:
> > So for me, EncFS seems the way to go
> 
> I looked into using EncFS with Dropbox, but from what reading I did it seemed 
> that EncFS was (1) old and not well maintained and (2) insecure whenever an 
> attacker can see more than one version of the same file (that is, see the 
> same file before and after a modification). Version 1.8 supposedly fixed some 
> of the issues but this issue about being able to learn about a file's 
> contents when it changes remains (as far as I can tell from reading around). 
> Since Dropbox can always see files before and after modification (that's kind 
> of the point of it), EncFS seems like an insecure choice to use with Dropbox.
> 
> So I'm still looking for a good solution for encrypting a single folder that 
> will be synced.
> 
> Of course, Dropbox itself would be considered a security risk by many who are 
> interested in Qubes. Myself, I'd put up with it if I could localize it to a 
> dedicated AppVM.


Okay I have now installed Qubes OS on my work PC which also supports VT-d :), 
so I had a chance to look into this more deeply.

I see that EncFS is old and maybe not fully secure. Unfortunately there don't 
seem to be good alternatives. Also the vulnerability primarily focuses on 
manipulation, not decryption. Since I only push to Dropbox, but dont fetch 
anything, this is unlikely to be a problem. Also the data I am pushing is not 
that important. It's personal but I am not a dissendent or something, so I 
don't "really" have anything to hide. I don't think EncFS is a security hole, 
unless some state sponsored actor really takes a liking to you... They would 
also need to have access to dropbox in the first place, which isn't easy. I 
actually trust Dropbox enough that I don't believe they will go trough the 
trouble of breaking my EncFS encryption ^^. Like... What for? I doubt I am on 
any NSA list yet... Well on the list you get on for googling Snowden and 
downloading Qubes OS, okay, but that's probably a list with millions of entries 
;).

I tried the block-device approach, it doesn't work. Dropbox can sync only the 
"changed" blocks, yes, but for that it needs to scan the entire 200 GB file for 
changed blocks which is a freaking nightmare, power-consumption wise... 

So my current setup is:

1) Dropbox VM: Runs dropbox and keeps a local copy of 200 GB EncFS files (only 
encrypted)
2) Vault VM: No internet connection. Has a plaintext copy of the 200GB EncFS 
files. 

Now I just mount the Vault VM's loopback device with the encrypted EncFS files 
inside the dropbox VM and issue an rsync command to update the dropbox VM's 
local copy. Then dropbox will updated the changed files...

Not exactly as smooth as I expected but I guess that's the price you have to 
pay for maximum security ;)

-- 
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/5558f917-8de4-4442-907d-3c7cef41f6fc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Encfs + Dropbox: How to keep your cloud files secure?!

2016-09-16 Thread mara . kuenster
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.


Re: [qubes-users] Encfs + Dropbox: How to keep your cloud files secure?!

2016-09-16 Thread mara . kuenster
Am Freitag, 16. September 2016 09:27:26 UTC+2 schrieb Raphael Susewind:
> IMHO the safest option is indeed to use a split-dm kind of approach, as
> suggested before: create a loopback file in the dropbox VM, expose this
> via qvm-block to your working VM where you then do all the encryption
> (using standard LUKS) and can either mount the thing right there or -
> for extra security - expose to yet another VM, again using qvm-block:
> 
> dropbox VM: loopback file -> /dev/loop0 -> exposed with qvm-block to
> crypto VM: /dev/xvdX -> dm-crypt -> /dev/mapper/plain -> exposed to
> work VM: /dev/xvdX -> mounted somewhere and used as usual...
> 
> The only caveat is how Dropbox behaves if you have a file in it that
> serves as backdrop for a loopback device - any thoughts on this?
> 
> Raphael

I dont have any references at hand, but back then when I decided to go with 
EncFS, I also looked at the block-device method. IIRC, Dropbox theoretically 
does handle giant files very well (actually it's pretty irrelevant what you 
store), but there were problems with syncing obviously (try accessing this 
device on multiple machines) and also with write-through and general integrity. 
It just had a lot of quirky corner cases and while EncFS + Dropbox isn't 
perfect for syncing either, it has worked flawlessly for over two years now 
(with daily use)...

So for me, EncFS seems the way to go, unless you unmount the file system and 
flush it before activating dropbox but that is kinda unstable from a human 
error perspective...

-- 
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/5be67da3-dc2f-49ae-be29-14263c81a1cb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Encfs + Dropbox: How to keep your cloud files secure?!

2016-09-16 Thread mara . kuenster
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.

-- 
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/43d896a3-aee4-40ef-ae98-fff3e522c798%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Encfs + Dropbox: How to keep your cloud files secure?!

2016-09-16 Thread mara . kuenster
PS: SSH alone is of course not very ideal, because this could mean I am running 
rsync of the dropbox qube. Instead I could use SSHFS to mount the dropbox 
qube's folder in encfs and then use the rsync of the encfs qube to sync the 
files via SSHFS. This is like super indirect, but probably safer?!

-- 
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/6cd48d49-5ce5-49ee-9fae-66ed81290cc8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Encfs + Dropbox: How to keep your cloud files secure?!

2016-09-16 Thread mara . kuenster

> > Hi,
> >
> > I just installed Qubes OS and I feel its freakin awesome!
> >
> > I am trying to set it up the way I want and one thing on my list is having 
> > a dropbox vm that provides simply just the cloud storage... I would like to 
> > run the actual encryption on a different qube because I dont at all trust 
> > dropbox.
> >
> > How would I setup a qube that runs dropbox and exposes its filesystem 
> > securely to another qube that runs encfs which in turn can then be used to 
> > safely store & view cloud files via qubes OS standard file sharing 
> > capabilities?!
> >
> > My idea was to run NFS on dropbox qube and connect to NFS with the encfs 
> > qube, but that's in several unfortunate.
> >
> > 1) I don't trust NFS
> > 2) NFS is unreliable in combination with EncFS
> >
> >
> > I want to get rid of the network connection...
> >
> > How would you solve this?
> >
> > Thanks a bunch!
> >
> 
> The operative word here is 'expose'... There is probably no secure way 
> to share something as complex as a filesystem, which is why Qubes has no 
> built-in file sharing capabilities.
> 
> You could use qvm-copy-to-vm or the equivalent in the context menu of 
> the file browser... but that copies whole files between vms.
> 
> You could also create one disk image per vm on dropbox, and somehow set 
> them up as loopback devices in the dropbox vm. This allows you to 
> 'share' data to client vms as disk blocks using qvm-block, which is far 
> less risky than sharing filesystems. You would also have to encrypt the 
> disk images in each client vm to make this truly secure.
> 
> Chris

What do you think about this:

Encfs-Qube contains plaintext & encrypted files and has a cron job that runs 
like every hour. This job will SSH into dropbox-qube and run Rsync to project 
all the changes onto the dropbox-qube (but ignores all the changes inside 
dropbox, which would also be nice in case dropbox deletes everything or 
modifies encrypted files etc.)

Dropbox-Qube just contains the public SSH key and see only encrypted files...

Is SSH + Rsync reasonably safe? Or do I have to assume an attacker could easily 
break into the encfs domain once he compromises dropbox? Remember that Rsync 
will not promote any changes in the dropbox domain back to the encfs domain... 
It will discard all the changes inside dropbox instead.

-- 
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/6b1267b3-9295-4104-9d73-89e3b072667c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Encfs + Dropbox: How to keep your cloud files secure?!

2016-09-16 Thread mara . kuenster
@Chris

Thanks I will think about this block-level approach.

@Drew

I don't agree... Storing encrypted files on dropbox IS secure in the sense that 
nobody in the world will be able to decrypt them (as long as the encryption 
step is not exposed to the dropbox process, which might be compromised). Of 
course dropbox can delete all your files instantly, but that is another matter. 
I use dropbox as cloud backup and if they delete everything it doesn't really 
matter, unless I lose all my own backups at the same time.

-- 
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/6a05a5f4-beba-40ed-be49-ad484ed8deaf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Encfs + Dropbox: How to keep your cloud files secure?!

2016-09-15 Thread mara . kuenster
Hi,

I just installed Qubes OS and I feel its freakin awesome!

I am trying to set it up the way I want and one thing on my list is having a 
dropbox vm that provides simply just the cloud storage... I would like to run 
the actual encryption on a different qube because I dont at all trust dropbox.

How would I setup a qube that runs dropbox and exposes its filesystem securely 
to another qube that runs encfs which in turn can then be used to safely store 
& view cloud files via qubes OS standard file sharing capabilities?!

My idea was to run NFS on dropbox qube and connect to NFS with the encfs qube, 
but that's in several unfortunate.

1) I don't trust NFS
2) NFS is unreliable in combination with EncFS


I want to get rid of the network connection...

How would you solve this?

Thanks a bunch!

-- 
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/7a5fc95d-8fe8-4c00-8e53-94ae4d660456%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.