It's easy to google and get lost in all the information out there, always wondering what is true and accurate. The best way of course is to talk within a community and learn from those that are in the trenches. With that said, as is \ should be standard for the tinfoil \ conscientious security users out there, a good old fashioned audit is in order! (Forgiveness if a thread like this already exists, integrate where necessary!) So first question is, how do y'all feel about VeraCrypt? An offshoot \ cousin of TrueCrypt, that alone tends to make me feel iffy on the whole program, but I'm curious as to what current users think. I've also read good things about BestCrypt as well, though they're not open source, so there's that. Secondly, is it a good idea to have two separate programs for whole disk encryption and then file \ volume encryption? The question being, is it better or counter productive to rely on more then one program for your various encryption needs? Thanks in advance!
"how do y'all feel about VeraCrypt?" Truecrypt is audited, Veracrypt isn't. "is it better or counter productive to rely on more then one program for your various encryption needs?" Depends what you must mostly assume. If one product is better or equal to another product, having two is counterproductive. It also implies more upkeep, code and surface area; perhaps, one updates and becomes malicious. However, of these two products, we may not know which has less vulns/backdoors or will become malicious etc. Granted this, and all the apparent likelihoods, I would suggest using two vendors if possible and also suggest to continue using both FDE and file encryption in general. Concrete examples: Safe bet while being hyper-usable is using self-encrypting SSDs with a native OS FDE like Bitlocker, then using Truecrypt for the file encryption. Add authentication hardware like a TPM and smartcards and you have extremely strong protection. You could also double encrypt file-in-file, but I would use TC first because, again, it is the only consumer implementation that has been properly vetted. If using the suggested TC, I would also not use Veracrypt for doubling up file-in-file or FDE/file combo for that matter because VC would likely contain the same bypasses as TC. Safer would be onetime pads/passwords on a physically secure air-gapped, tamper evident computer running from non-writable media. This, however, is not very feasible or usable for most.
I think I've moved "beyond" TC/Veracrypt in terms what I want - not what's available! I've stuck with TC, but can understand wanting to move to Veracrypt or Bestcrypt depending on an individual's threat model. Anyway, I think the fundamental flaw in all container/FDE solutions for me is that once you've opened the container/disk, all the files in it are open at least for read by any process running in the user address space - no escalation required. Sadly, the computer itself cannot normally be fully trusted, and what I would like to have happen is a separate disk subsystem with two-factor and/or physical confirmation of file access (configurably). That way, a rogue or malicious program could not access or damage any file unless the user had agreed to the access.
Who wouldn't want your scenario? That "wish list" has nothing to do with encryption though. The encryption issue pretty much resolves the risk for data AT REST on a cold media (computer, external, flash, etc.). For that purpose I had used TC for a decade or so. I recently moved to VeraCrypt because the code has repaired the few blemishes discovered in the TC code. NONE of the code discoveries were catastrophic for data AT REST, which is my concern. The VC headers are much harder with the application of PIM. Data AT REST is solidly secure with either of these fine products. Back to your wish list. Sadly, I know of no such creature. For now best case is attempting multi-hop tight tunneling and confining workspace activities to TEMPORARY virtual space. Realizing IF something gets in your system it will be confined and destroyed upon closing the temporary virtual space holding it at the end of your session. Its a poor answer to your "wish list" but its all I have for now. TAILS or any Live approach has value too, but candidly for daily surfing its too much hassle to keep configuring stuff from scratch. I use Live/TAILS several times a year, especially when I am at a coffee shop without access to some of my personal network tools.
@Sordid - Okay yes, TC and it's issues \ auditing \ controversy! I had posted about it way back when, like everyone was nervous and surprised. With that said, considering what happened with it, what was the end result? I researched a bit and tended to find those that are either advocating for another approach \ program, the tinfoil hat types (myself lightly among them), and the overly technical types... So clearly I'm not sure! Either way great information and appreciate the level of your knowledge on the topic. @deBoetie - Yeah, I'm still wary of using TC for sure. However should one only consider programs that have been audited? VC hasn't as sordid said and can't tell if BC has been or not. @Palancar - Great stuff, definitely food for thought regarding at rest and active data. Now with an encryption volume container... You open it, use \ access \ write the data, depending on what it is and what you're doing, and then close the VC. Now when the VC is closed, the computer and or any potential malware is unaware of those files \ volume right? (I don't doubt that I'm not asking the question right but hopefully you get what I'm saying!)
@Palancar - completely agree about the utility of TC and other for stuff at rest. I guess what I'm trying gently to do is to rattle any assumptions that this makes the data safe when "live". I'm not that concerned about the recent bugs found in TC because they are about live operation, and I know that for many reasons, live operations are vulnerable - so I take other precautions. As far as secure storage subsystems are concerned, I don't believe there are such systems for retail purchase - yet. For one thing, I'm researching how to build this for myself; for another, one of the consequences of the over-reach of the IC is that there is a flourishing market for such things, and they will be available in a couple of years, I have no doubt. Part of that development, I think, will be finding ways of monetising security enhanced open-source product (e.g. hardened kernels, RNG, secure storage systems etc), it's not easy at the moment to square that circle, and to get people to open their wallets for what is very hard and painstaking work. E.g. grsecurity. It's my view that the road to more secure clients and communications will take around 10 years.
guest Results: https://opencryptoaudit.org/reports/TrueCrypt_Phase_II_NCC_OCAP_final.pdf Breakdown by pro: http://blog.cryptographyengineering.com/2015/04/truecrypt-report.html Use a USB...
The whole file system on a USB stick is vulnerable while inserted. That's the vulnerability I want a control for - that currently any program gets to access any file (short of various RBAC, which can be subverted anyway if escalation has happened).
Good encryption mathematically prevents true data loss granted no brute is possible; this is the point of encryption. It's at rest until you open it. Just use different passwords for each container. So the USB idea is "ghetto." Think of the media as keys. My tax returns don't need to be on my computer to be enumerated....exfiltrated and bruted. So that disc is in a lock box OFF my main HDD/network. As to file groups on a HDD or "key" that are frequently accessed, they will be eventually opened by you and seen as cleartext by said potentially subverted system. So I'd say you have a bigger problem outside of disc access/RBAC/encryption. One idea that others have employed is a "usb-pc-stick" like USB armory or cottoncandy. You push them into your usb and you can screencast/mirror or vnc into them. You then use a secondary device (phone/small KB) to access the usb sticks UI so all the host ever sees is a casted image.
Thanks, I understand the limits (and I can't see many attackers waiting till you'd opened all your documents!), and indeed, I think the way this is going is specifically having a UI/rendering box/separate process address space processor which is physically disconnected from the internet and maybe behind a data diode (I think this is similar to the vnc approach you reference). Perhaps Wayland will provide more opportunities for doing this. Similarly, the keyboard/mouse entry processor. Then add two-factor for encryption/decryption on different processors again (so process address space attack doesn't work), and that would be pretty solid. In the short term, probably Qubes is going to be the closest a person will practically get to that.
