Thanks for the response @yuki regarding EFS. A robust stance does not treat any control as either good or bad in isolation, and they need to be context-aware. So, for example, while I do not rely on EFS for more valuable data, it does have a very useful function for me, and I am well aware of its limitations. In my context where I want transparent and easy to use encryption on devices which may get stolen, and where the account passwords are strong, and where I do not have a TPM (for Bitlocker), then EFS is a very handy tool to have - it is the only way of getting transparent encryption associated with the account. Sure, I can use other technologies (and do), but then they require me to separately enter strong passwords and/or have keys of various kinds - which is more awkward, isn't going to fly with some users, and introduces vulnerabilities of their own.
Thanks very much for the ideas here and in associated comments. Agree completely that the host has to be a minimal vulnerability, and like the idea of read-only kernels and suchlike on DVD etc. But a thought occurred to me: a simple hypervisor IS something that is stripped down and hardened (most internet servers run on such these days) - so maybe the thing is to have a read-only hypervisor, one that also detects attacks when running. I know this is behind the thinking with Qubes, although the read-only kernels only apply to the guests.
Well here is my starting point. Still work in progress, but getting there. Hard Drive Encryption Introduction Encrypting your information is the cornerstone of maintaining your privacy. Some of the common reasons it is good to encrypt your data are: Protection of your information if your device is lost/stolen Protecting your information if your device requires repair or replacement (I received a refurbished Surface Tablet where data from the previous owner was easily recovered) Protecting important files where required to by law or good practice (eg. Medical records) Protecting files if you wish to encrypt them for the cloud (this will be covered in another tutorial) Protection against law enforcement access to your device (just because you do not want them to access your material it does not make you a criminal) Protection against state level (government) access to your files Of all these threats, state level access is the most challenging to prevent. In many cases governments can utilize tools to force the company that manufactures the encryption to provide access or backdoor. We have no way of knowing what backdoor access has been granted. Even if the company has not knowingly provided backdoor access state level actors have the resources to plant operatives within companies to ensure that backdoors exist. Open source software is more trustworthy, however operatives could be operating within the open source community. Even if the state did not have a backdoor they could apply coercive techniques to force you to provide a key. Despite questionable effectiveness at the state level it is well worth encrypting your data as most threats you will encounter can be stopped through effective use of the techniques outlined. Encryption Understanding the mathematics behind encryption is not necessary to use it effectively, however, a knowledge of the basic theory helps us select the right method for our purpose. Key Definitions Plain Text = refers to the unencrypted version of the file or file system Key = generated from the password entered by the user (this is kept secret) Algorithm = the mathematical formula used to encrypt the data Ciphertext = the encrypted version of the file or file system The goal of encryption is to take your file/drive in plain text and convert into ciphertext. To do this the key is combined with algorithm to change the plain text into ciphertext. The algorithm used to encrypt and decrypt the data and is not secret. Use well proven publically available cryptography that has been audited. Common recommended algorithms include: AES/Rijndael Twofish Blowfish Triple DES Serpent If you are interested in learning more about cryptography I would recommend the work Bruce Schneier (https://www.schneier.com/) Password Most encryption techniques utilize some type of password that must be entered to access the encrypted information. The strength of that password is critical. My recommendation is for most purposes you have a password of length of around 64 characters randomly generated. How can the average person remember a password of that length? I recommend the use a yubikey, a usb device that emulates a usb keyboard and can be setup to provide static passwords. Simply press the button and it inputs the static password string. (https://www.yubico.com/) The device is small and I keep on my person at all times on a lanyard around my neck. Relying on the Yubikey is dangerous if it is lost or stolen. The solution to this problem is to memorize a smaller alphanumeric string that you enter before or after the yubikey string. Strong passwords counteract the weakest part of an encryption algorithm, the people who use it. In some cases strong passwords are not possible because the device does not have usb and/or entering a strong password is impractical. For example Android devices have a screen lock with a password the same as what encrypts the device. Entering a secure password every time you wish to use your phone will drive you mad and test your memory. Shorter passwords are used, but remember this compromises the security significantly. For this reason I am always careful about the types of information stored on my phone. You may notice that biometrics are not included. The reason is that it offers very weak protection. In the event of arrest or even questioning by law enforcement the officer can compel you to open the device by force. In the US they can compel you to provide your fingerprint but not necessarily your password(http://www.zdnet.com/article/virgin...hone-with-your-fingerprint/?_escaped_fragment_=#!). Encryption Types Full Disk Encryption As the name suggests, full disk encryption (FDE) indicates that the entire volume or drive is encrypted. One of the challenges is that FDE encryption usually requires a small boot partition that is unencrypted if your operating system is on the encrypted partition. The boot partition contains the algorithm and software necessary to decrypt the encrypted partition. The only exception to this rule is hardware based encryption that is found on many SSDs, in this case a boot partition is not necessary. Encrypted Container Rather than encrypt the entire partion, an encrypted container as its name suggests is a container designed to hold the information you want encrypted. Anything stored outside the container is not protected. Typically the container is mounted using a software package and is assigned a drive letter. Assessment Criteria 1.) Ease of setup + - Difficult to setup without high level technical knowledge, knowledge of command line required ++ - Solid computer skills required and knowledge of partitions and how they work +++ - Basic computer skills required, knowledge of how to follow basic instructions(execute programs, desktop shortcuts) 2.) Protection against low level threats (reasonably computer literate person off the street) + - Little to no protection ++ - Some protection that can be bypassed with significant effort +++ - Strong protection that cannot be bypassed 3.) Protection against medium to high level criminals and suitable for protecting sensitive corporate/health information + - Little to no protection ++ - Some protection that can be bypassed with significant effort +++ - Strong protection that cannot be bypassed (that we know of) 4.) Protection against law enforcement and low level nation states + - Little to no protection ++ - Some protection that can be bypassed with significant effort +++ - Strong protection that cannot be bypassed (that we know of) 5.) Well resourced nation states + - No protection ++ - Some protection although given closed nature of the product we are unsure whether secret backdoors exist +++ - Moderate protection with code that is open source and well established The Candidates Full Disk Encryption 1.) Windows a.) EFS b.) Bitlocker c.) Diskcryptor 2.) Linux a.) Ubuntu built in encryption b.) LUKS/dmcrypt 3.) Android a.) Android inbuilt encryption 4.) Mac OSX (will only be included if somebody can help) 5.) iOS (will only be included if somebody can help) Container Encryption 1.) Cross Platform a.) TrueCrypt b.) Intel SSD c.) EncFS
@driekus Looks good, only thing I might add is Diskcryptor for Windows. It's FOSS so likely a safer solution than Bitlocker. And correct me if I'm wrong but Ubuntu's built-in encryption is LUKS/dm-crypt so no need to write both
@driekus Great! Some findings: -As to encryption algorithm, why no Serpent? -iOS, same as Android 5.0, adopt FDE by default. By default user have to set 4 digit passcode, but you can change this from setting if you want to use strong passphrase. OTOH, use can completely disable passcode too (Anyway I don't trust Apple much...) -EncFS is actually cross platform. It works on Linux, BSD, OSX, Windows (dokan library is needed), and Android too. Also it's bit different from other container type encryption, it's actually file-based encryption but those fileｓ & folders are in one virtual file system which can be mounted like container. So adversary can tell how many file is in it, and what each file size is, tho file names are also encrypted.
Diskcryptor also supports GPT which Truecrypt does not, although there may be issues with W8.1. There is no Linux support. I evaluated it briefly and was favorably impressed, though I decided on TPM with Bitlocker for what I wanted.
@driekus - thanks, I'll think some more on this, some immediate observations: Latest versions of Android support nfc as a second factor, which is what I'd do if I had a smartphone(!) I'd reference Diceware as an option for long strong passwords. They can be remarkably easy to remember and OK if you're good at typing! I find they are easier to remember long-term than various conventions about adding decorations etc. and those may not be as strong as you think. The main alternative is a shorter string of random characters that you construct some kind of personally meaningful story from. Either way the entropy has to be sufficient. It's useful to read up about the techniques password crackers use, that can be quite sobering and they are very very effective at pretty much anything that's non-random or is based on known phrases or words on your computers or communications. I think it's important to note the importance of header backup or equivalent.
Excellent suggestion on diceware will put it in. I know that I am a little over the top when it comes to pure random passwords. Diceware is a good middle ground. Even used webcam and audio techniques to generate entropy and overcome limitations (probably not suitable for general audience. As for NFC second factor authentication, do you have a link or reference? Very interested in this one as I currently used an Android mod to use NFC to unlock phone, but it does not behave as 2FA.
Serpent omission was oversight on my part.Will add it in. I agree with Android and OS you can set a strong password but it does make it quite painful to use. The risk with longer password is that I found it painful to use with a short lock screen timeout. I will need to cover this in more detail. If you do use container encryption on Android or iOS I can see a short password for lock screen and long one for container. Changed EncFS to cross platform
I will add Diskcryptor for Windows but still keep Bitlocker in there. For some people Bitlocker will be more accessible. Ubuntu's FDE is LUKS/dmcrypt but really only applies to main OS. Wanted to cover LUKS/dmcrypt for encrypting mounted volumes as many linux users do use it for their server (at least paranoid nuts like me)
I wouldn't say Diceware was middle ground - it can be adapted to whatever entropy you desire, and it has the merit of being fully random (it doesn't matter if your adversary knows the wordlist - as long as you stick to the random). I trust the throwing of physical dice in a technology free space and never having the passwords stored at any point in a computer, quite a strong mechanism. And in use, I find it very practical to remember and reliably type a set of master passwords with entropy of around 120 bits. Having standard words makes it easier - for me. Regarding the use of nfc in Android authentication, that was something introduced in KitKat 4.4, but I found documentation on it extremely sparse, and got most practical information on how it worked from YouTube videos. Seems to be that you can combine the pin with an nfc tab, but that has to be more or less kept there to persist the unlock. My notion was to combine this with the Yubikey nfc-based OTP for Lastpass. But I haven't gone that route simply because I can't get my head into the tiny screens and don't trust smartphones. I certainly think Bitlocker is a useful technology to include, because it is the ONLY supported mechanism for Windows, that, with a TPM, allows for password-less boot and FDE. I'm happy enough with it for standard commercial theft threats. Of course, integrity is also dependent on your account authentication, but with good passwords and Yubikey HMAC-SHA1 authentication, it's pretty strong.
I like the Veracrypt project. It's located @ https://veracrypt.codeplex.com/ It used Truecrypt as it's base for it's code. The developer has increased the encryption standards to make brute-forcing volumes impossible for the next 10 years. It's also backwards compatible with Truecrypt volumes making it a viable option for all current Truecrypt users. I would argue that Veracrypt is 10 times better than the last stable release of Truecrypt.
OK done the linux section. After writing the Linux section I understand that how my knowledge of Windows EFS, Bitlocker, EncFS and potentially TrueCrypt is. Is there anyone willing to collaborate and write something similar to the level of detail below? Its for non-commercial purposes and you will be fully credited. Looking for details on the encryption, references to installation, summary of pros and cons.
Great work indeed! I can take on EncFS part if you don't mind and can correct my poor English, as it seems maybe no others here have experience on it especially on Windows. For EDS, Bitlocker, and TC there must be more suited person. Pardon me for nitpicking. Typo: Mistake: Using SHA1 for this kind of encryption software is no problem. I already explained it here, but in short, vulnerability in SHA1 or any hash algorithm is no relevant to those encryption software, it only matters on authentication and modification checking. TC, dmcrypt, or any other decent file or drive encryption program use hashing only to delay bruteforcing, so you can even safely use completely broken MD4 if you can increase repetition count, or IOW it need not necessary to be hash if there's other way to delay bruteforce. If you're not yet convinced, you can ask Schneier (or any other genuine crypt expert), he knows this. Note in you quoted link, he carefully said: Generally, crypt vulnerability or attack tend to be misunderstood even by techy people as it requires deeper understanding to crypt. I've been seeing & correcting them in a local community but 2 misunderstandings repeated many times are this hash thing and vuln in AES.
I'd give the EFS bit a go. Don't mind reflecting a bit on Bitlocker too, but will be parochial. If I could suggest some add-ons to the Linux bit (your work is never done) - there are sometimes good reasons for encrypting the Home directory only. This can be done at the stage of user account creation and retrospectively; and for some, it's good-enough (particularly since I believe the swap is default encrypted these days anyway, and in any case, I normally run swap-free). At least you're not faced with per-boot password entry. This is also the way some pendrive Linux distributions work (and work very well since the kernel is effectively read-only on storage). The persisted bit (which is ALL the customised data) - is encrypted (normally I think with luks/dmcrypt).
Thank you Yuki, your help would be greatly appreciated. I can easily tidy up any English, it is the knowledge and understanding that is important. I have learnt a lot in writing this, part of my motivation for doing it. You have given me a very valuable lesson when it comes to SHA1. Always was under the impression that SHA1 would be eventually useless for all applications. You also saved me from re-encrypting all of my LUKS drives with SHA512. I will still leave the manual LUKS/dmcrypt section in as it is useful for encrypting mounted drives. As I have learnt more I am starting to come to the conclusion that using strong encryption tools like luks/dmcrypt, Truecrypt, etc is probably more than enough to stop entities such as the NSA. It is not the crypto that is weak, it is the humans that operate the crypto that are weak. We browse the internet (with scripting usually on), open email attachments, and do many other insecure things. All much easier targets than brute forcing crypto. If the NSA targeted me, seizing my hard drives and brute forcing my encryption would be very very tough. Easier route would be to compromise my phone/computer, intercept all of my emails, find my PGP keys and read all of my communications. At that point they would realize most of my PGP emails are my server notification and emails from my wife. They could probably do this with minimal work and leaving me unaware. I am sure that is what they are investing their money on, not brute forcing encryption. Thanks again Yuki
Thanks deBoetie, EFS and if you can manage Bitlocker would be very appreciated. I will add the home directory section, I understand there may be some times when it is the best option.
I'll write & post about EncFS. One suggestion: about password length, 64 char can be overkill depending on crypt program's key size. I'm not familiar with LUKS/dm-crypt but thought it allows you to change key size and default value is 256 bit, but I don't know if it firstly generate header key and then decrypt volume header for master key, it's how Truecrypt works. Anyway, if password is random enough and if the key generated by password is 256 bit (Truecrypt case), then more than 256 bit password won't make it much more secure. If attacker can brute force such long password, he can brute force key itself. If you can use capital letter, small letter, numbers, and all symbols, 1 char is equivalent to 6.6 bit. So 39 char ≒ 256 bit. But the password may not be random enough, so it's good to add some more length. Thus practical length for 256 bit key will be around 45-50 char. This need not to be necessarily included in the article cuz when you chose Yubikey long password won't be problem, but maybe worth adding as a reference for those who don't use Yubikey.
Cool thanks Yuki, one point I didnt cover was that Yubikey is limited to lowercase characters and numbers so that you dont use the full character space to get 6.6 bits of entropy per character. I calculated 64 characters based on approximately 4 bits per character. In reality it is probably closer to 4.5 bits but 64 characters makes it safe. If you have to remember the password 64 characters is excessive but Yubikey you can good go higher without any problems.
I was thinking to purchase Yubikey, but that limitation to small letter and numbers is deal-breaker for me as a kind of password manager, as I want to keep my password algorithm even when I use password manager. But maybe it's still worth buying for 2FA.
Now I completed encfs writing. @driekus, you can freely edit, remove, or add sth to this. Or can make request if any. I massively used link code, but if you don't like it I'll edit them. Hope this can contribute a bit!
Not sure if you're referring to actual password managers, but the Yubikey can work with Keepass and Password Safe with a non-static HMAC-SHA1 approach with no internet connection required, then it is genuine 2FA against remote threats and KSL. My feeling is that the Yubikey static is fine if combined with a decent entropy password - but this then does not need to be quite as long. But I've never been fully comfortable with the static for FDE because I find it easy enough to remember a few really strong passwords so I don't need it, and I think the risk of keystroke logging is smaller. But I don't think there's much benefit in 2FA for that situation. I think it's better just to have a target entropy rather than length, so I have to remember longer passwords (lower case only plus digits) with Diceware to get that entropy, but I still find that easier to remember and type than more obscure character-random ones. It's also more robust against different keyboard variants which is an important factor in FDE.
Sorry, I didn't know Yubikey well so quite appreciate your information! As to length and entropy, I completely agree, and anyone who use his/her own algorithm to generate password have to ask his/herself about its randomness.
It's completely sobering to read some interesting articles about how the cracking tools and the crackers are able to routinely and quickly crack what individuals think as "clever" and uncrackable - WRONG! Stuff like fancy keyboard proximity, ANY words or phrases on the user's drive or to do with the user, plus of course the standard wordlists and prioritised "known" favourite passwords. Doesn't take long typically. The only defence against this, in my opinion, is to abandon clever and go with the entropy (by rolling dice or other mechanisms).
