Yup, I read those articles especially Schnier's, such as brute force combining different words, and converting often used modification like "l" to "1". I still believe my algorithm is relatively safe. But it's not usable in other language speaker and even in same language still of course my password doesn't make sense to other people, and even when some passwords are stolen still adversary can't see the rule easily, unless lost passwords are certain amount and he made good guess. I can change password length too according to needs. The problem is when I forgot password and have to re-generate by the algorithm, it takes a bit of time (several to 10 or so seconds) as its bit complex, and for some sites I may need to "test" several (not many) times to find exact password. This is why I still use password manager like LP and Norton ID safe, but I once experienced all my passwords are lost in Norton and my last backup of them was old, so I don't want to solely rely on password manager. However, I think what Schnier proposed is also quite secure i.e. Use e.g. your favorite song, say, "It's a little bit fanny..." then "ialbf..." and "decorate" it as you like.
Schneier's favourite approach is reasonable, though you may over-estimate the entropy - simply because a lot of people have the same favourite songs come to mind, and they can be programmed into the cracking tools (probably already are...) I'm happy with having both LP and Password safe (for different things), and I also backup into a spreadsheet on an airgapped FDE box, which acts as my certificate generator and store as well.
Wow, thank you Yuki. Great read. Your English is excellent for a non-native speaker and better than many native speakers I know.
Tho song is one example, it's possible. That depends on how you decorate the password base. More complex decoration requires more time to generate, but once you're accustomed you'll find your generation time decrease. When I firstly made my current algorithm, it took maybe 30 sec or so, but now usually less than 10. Also you will find as long as you always use the algorithm, it's hard to forget it even when quite complex.
Still plodding along with this, been busy at work so havent had as much time as I would like. About 9 pages now. Do we have any iOS people out there who can handle the iOS side of things. I have never even picked up an iphone so probably the worst person to tackle it. I have no problem leaving it out but given there are a lot of iphone users might be worth covering. DeBoetie: You still good to handle the Windows side? In the next few weeks ill tidy up the wording and get some images in there.
Another thing that you might want to cover. The encryption is only as secure as the OS it runs on. With file, disk, and drive encryption, security and privacy are inseparable. If a user has data that justifies strong encryption, they should put just as much effort into the strength of their security package. The conventional default-permit, "let someone else figure out what to detect and block" solutions are inadequate.
Yup agree one should never skimp on the level of security and privacy in general especially in encryption,some great info on this excellent thread I bet so many people are using there names or dob or as part of their own unique password. But as suggested above all this does is demonstrates that you are linked directly to the device ! I was watching a documentary once and an adversary questioned a user if he was username mike1987, his reply was No sir the adversary then asked for his name which was Mike, and then his date of birth to which he replied 1987. I have got one password idea which is quite hilarious and I don't think it would be easily crackable however for me to discuss it would reduce its security or maybe that should just be the disclaimer around here
Tho I have iPad mini, I think I'm not right person to write about iOS encryption as I know little, sorry. I think it depends. I believe this driekus' plan is not limited to techy people or someone who want bullet-proof security, but rather more focused on those who don't much intimate with encryption. It's clear that most of such people don't want to be bothered by HIPS, and they won't care about backdoor in OS. Actually, most people I talk about encryption in another place are not that, they care about at most common key logger which can be prevented pretty easily by so-called common sense security, but not OS backdoor and not likely to use classic HIPS. Most of their threat models don't include police, corporate spying, or other advanced attack except just a little fraction of (paranoid―as a praise―) people. So we have to careful about what word we use in final writing. Definately we don't want to overwhelf newbies by making them to think if they don't employ strong control encryption is useless. We have to be flexible in thinking and being open in many values, just as my 2 cent. One have to compare/balance cost-effectiveness by considering how much the contents are important and how much security is needed while how much effort, knowledge, inconvenience meet them except paranoid like us. This is why I sometimes recommend Encfs for someone with explanation about its limitation after clarifying their needs and circumstances.
I've popped my proposal for the EFS section below, sorry for the delay. Bitlocker coming RSN! While I remember, it might be useful to note the role of the TCG Opal standards in SSD encryption which are used by W8 for Bitlocker and Secure boot. Compliant SSDs will hardware encrypt Bitlocker out of the box. >>>>>>>>>>>>>>>>>>>>>>>>>>> Windows (business editions) - Encrypting File System (EFS) EFS is a file, folder or drive encryption facility for NTFS provided and supported by Microsoft on business versions starting with Windows 2000. It relies on a certificate held in the user certificate store, and uses AES by default for encryption itself in Windows 7. In Windows 7 on, EFS supports ECC to add compliance for US government agency data protection. https://technet.microsoft.com/en-us/library/dd630631(v=ws.10).aspx From the user's point of view, the process is transparent, with the key generation and encryption being very easy to achieve and decryption is transparent. Although administrators can create recovery keys (useful in a business context), from XP onwards, it is not required to implement this form of recovery (and so the user can then protect their files from the machine administrator). An overview of EFS operation is provided here: https://technet.microsoft.com/en-gb/magazine/2006.05.howitworks.aspx The key management process is described here: http://windows.microsoft.com/en-gb/windows-vista/create-a-recovery-certificate-for-encrypted-files It is possible to install the same EFS certificate on your account on multiple machines, so that EFS encrypted files can be read on all accounts. It's also possible to use smartcards, obviously you have to arrange for cases where that card is lost or stolen. It's also possible to share files between users by adding their public keys to the file, but that key management is obviously painful. The preferred MS solution for this (for Office type documents) would be the Rights Management solutions under IRM (which also encrypts with certificates, but does much more in respect of permissions and distribution. Suggestions for file system areas to encrypt and best practices are discussed in http://technet.microsoft.com/en-us/magazine/2007.03.securitywatch.aspx EFS can not encrypt all files because the user does not have ownership of those, and necessary processes have to access them independently. Consequently, it cannot protect swap or registry files for example, as FDE would. Bitlocker is Microsoft's solution for FDE described elsewhere. In terms of use, I find it valuable in instances where FDE is not available or desirable, where it offers a completely transparent encryption of important user data such as mailbox files, documents etc. In addition, provided the account is well protected, it offers the ability to store secrets for other programs. Finally, even where FDE is deployed, if this is a multi-user system, EFS provides the ability to transparently encrypt files so that other users, including the administrator, may not decrypt them. I do not use it as a means of transport or backup security, it's essentially local to the machine. I'd characterise it as a useful situational tool, with medium security. Positives Transparent to the user, very easy to use. Easily applied/unapplied using explorer context menu. Free on suitable editions of Windows Provides ability to protect user data from other user accounts including the machine administrator - which applies whether FDE is implemented or not. Works on systems where FDE is not implemented or desired Performance is better than FDE because not all files are encrypted. Windows accounts may be secured with two-factor authentication (e.g. Yubikey), and also not shared with the administrator, so that account attacks are harder. Negatives Proprietary, not cross-platform Restricted practically to protecting the local user's files only (this can be a Good Thing!), or their account on other machines Doesn't protect some areas like FDE (e.g. swap, deleted files etc.) Like most file and folder encryption functions, leaks information in filenames and folder structures (unlike FDE) Vulnerable to Windows account vulnerabilities or weak account security Work is needed to select areas for encryption Some file areas cannot be encrypted with EFS due to use of impersonation (typically for browser sandboxes, and Sandboxie), or Temp files. Although encrypted file sharing can be done between users, it requires them to exchange their public certificates and apply them to relevant files. When EFS protected files are saved on a network file share, they will normally lose their encryption (although it does warn you when this happens). WebDAV can support EFS protected files. In common with FDE, EFS provides no protection from remote attack where malware is running in the user account.
And now for BitLocker. Don't know if this is too long/detailed or has too much implementation specifics (though sometimes the devil is in the detail). Obviously welcome comments/corrections/amplifications! Windows (business editions) - BitLocker BitLocker is Microsoft's FDE and drive encryption solution, available in Ultimate and Enterprise editions of Vista and Windows 7, and Pro and Enterprise editions of Windows 8 (and also some versions of Windows Server). Other versions (such as Windows 8 RT) provide limited BitLocker features for the device. XP or Windows editions without BitLocker support can run "BitLocker To Go" software on encrypted volumes in read-only mode. BitLocker works with GPT partitions, including on the system (Windows) drive, including swap and hibernation files. In addition, it supports Fat16, Fat32, ExFat as well as NTFS, so is suitable for encrypting USB sticks. It can also apply to hardware RAID, but not software RAID. UEFI bios is also supported. Bitlocker uses AES encryption (128 bit default, 256 bit may be selected in policy), backed by CBC and in Windows 7, the Elephant diffuser. In Windows 8, this diffuser has been removed, see https://www.wilderssecurity.com/threads/has-bitlocker-been-weakened-in-windows-8.369873/ for views of this weakening. It is claimed that its removal is because crypto-accelerated hardware cannot support it, and FIPS only environments do not allow it. But this is at the expense of seriously weakening encryptions where TPM-only is used. Note that on system drives, there is a 100M Windows partition that is not encrypted by BitLocker, and cannot be so. This has concerned some as a potential leak/mechanism for exfiltration, I'm not aware of any attacks as such. A userful FAQ for BitLocker drive encryption in Windows 7 is given here; http://technet.microsoft.com/en-us/library/ee449438(WS.10).aspx#BKMK_HSRequirements And for Windows 8: https://technet.microsoft.com/en-gb/library/hh831507.aspx A good guide for setting up Bitlocker with TPM is discussed here: http://allen-conway-dotnet.blogspot.co.uk/2010/01/how-to-set-up-bitlocker-full-disk.html And without TPM here: http://www.howtogeek.com/howto/6229/how-to-use-bitlocker-on-drives-without-tpm/ Dislocker software running on Linux is reported to be able to read BitLocker volumes given the Recovery key, I have not checked this (http://theevilbit.blogspot.co.uk/2014/04/using-dislocker-to-mount-bitlocker.html). I had a very weird problem with enabling BitLocker on a 4TB GPT drive, solved by setting the partition size to 3815174MB, which loses a little capacity. This is a bug that may have been fixed. http://superuser.com/questions/591749/bitlocker-wont-initialize-on-a-4tb-drive-with-4k-sectors One advantage of BitLocker is that disk drive letters do not proliferate as volumes/partitions get added. With some other FDE approaches, extra drives are created. As with any FDE, backing up prior to implementation, and carefully backing up and storing recovery keys is essential. Whereas previously, you could boot into a different OS and inspect the disk to recover files, this is no longer possible, unless you have the recovery keys. Of course, this makes disposal of disks when they have failed more straightforward. One of the major advantages of BitLocker is that it is the only native FDE on Windows systems drives (as opposed to enterprise commercial solutions), which is completely transparent to the user, if the system supports TPM 1.2 (and that capability is supported and enabled in the BIOS). If so equipped, prior to the encryption process, a Security Device, Trusted Platform Module 1.2 will appear in the Device Manager. The keys are stored securely on the TPM. Of course, various other combinations of TPM, PIN and USB startup key are supported. If a pin is used, care must be taken with keyboard characters. Also, depending on the motherboard/BIOS, the startup USB might not be correctly identified at boot. If a TPM chips isn't available, a USB startup key is required (and can be set by Group Policy editor). Other drives may also be encrypted with a password, and if the system drive is also encrypted, these drives may be automatically mounted without subsequent password entry. Facilities are also provided to temporarily suspend BitLocker protection (for example, when altering things which will trigger TPM events). Best practice is suggested to be TPM + PIN. Again, with TPM, boot system integrity can be checked, so that the disk is not accessible if certain early boot components or boot configuration data has been altered. On popular retail desktop motherboards, a TPM header is often available, and a TPM module may be added (cost around $20-30). On Windows 8, there are some additional factors. First of all, if you set up BitLocker from a Windows Live account, the system will automatically backup your Recovery keys to the cloud. You . May. Not. Want. This! Clearly, setup from a non-cloud admin account is required if so. Secondly, as mentioned above, Windows 8 has removed the Elephant Diffuser completely from the encryption, there is no option to choose it. For suitable SSD drives, conforming to MS eDrive standards (which include the TCG Opal 2 and IEEE-1667 standards, along with suitable versions of UEFI and TPM), Windows 8.1 BitLocker will use the drive accelerated encryption. MS have announced that, from 1st January 2015, TPM 2.0 will need to be used for Windows 8.1 hardware certification, there are some additional privacy/licence/DRM concerns with TPM 2.0. There is a reasonable case for combining eDrive and TPM support with Bitlocker and Secure Boot, because the system drive is protected as well as being less vulnerable to boot attacks and rootkits. Regardless of hardware or software encryption, I'd use AES-256 given the lack of diffuser. Concerning the proprietary nature of BitLocker, and the existence of backdoors, there has been much speculation that there is a backdoor in BitLocker since 2006 (and likely before)! MS designers have strenuously denied this, and MS engineers said that they was asked to insert such, but refused. http://blogs.msdn.com/b/si_team/archive/2006/03/02/542590.aspx Nominally, BitLocker code is available for corporate/large government inspection under NDA, but no information regarding this inspection has emerged. Vulnerabilities of keys in powered-on-memory have been demonstrated, and in this regard all the caveats listed in the Truecrypt documentation apply just the same. Recently, side-channel attacks on Bitlocker (via the TPM chip) were reported as part of the Snowden revelations: https://firstlook.org/theintercept/...ies-power-analysis-exposed-exploit-bitlocker/ A discussion of this is the Schneier post: Can the NSA Break Microsoft's BitLocker? https://www.schneier.com/blog/archives/2015/03/can_the_nsa_bre_1.html In a way, I see this as good news, that is to say, if BitLocker were trivially breakable, then there would be little reason to go for side-channel attacks on TPM which require physical presence at a switched on machine. My view is that - regrettably - the real vulnerability is with the "terrifically weak endpoint security" which can be remotely subverted, and the data collected off the encrypted disk natively, or else the passphrase captured with KSL. This of course, applies to all FDE, although the boot process is harder to apply KSL to. Additionally, with admin access, the memory of the system (where the keys are stored), would also potentially be vulnerable (or compromised versions of the encryption programs substituted etc). Overall, I see BitLocker as a valuable and easy to use protection for normal commercial threats and standard adversaries. It is supported and allows for easy disposal of obsolete or failed disks. Combined with a TPM, it can be completely transparent, which is very useful on laptops where a strong password entry on every boot might be intolerable.. Of course, it does not preclude the use of other encryption options as well or in parallel (e.g. Truecrypt), particularly in systems where there is no page file or hibernation, and account security is strong. Positives Fully supported and free (on relevant editions) solution for Windows, very widely used; reliable in my experience. It is very common in commercial environments, and may satisfy legal requirements and avoid litigation in case of breach. You are unlikely to be fired for implementing it, it is a reasonable CYA facility. Provides reasonable protection in case of disposal of disks Supports GPT on system and other disks In conjunction with TPM, can be fully transparent to the user, and protected by TPM startup protections PIN and usb startup keys can be added to increases security - FDE is effectively supported with multifactor Drive letters are kept transparently, no additional drive letters used If system drive is encrypted, other drives can be automatically mounted Allows encryption of different media and filesystem types, so USB drives can be encrypted easily, and read by other Windows computers. Negatives Windows only, not available on home editions (although BitLocker To Go is available for Windows, and Linux software can reportedly read it with Recovery key) Propriety software (but then, so is the rest of Windows); perpetual rumours of backdoors Works best in conjunction with TPM chip which may not be available on some machines; without TPM, it's USB startup key only, which (for example) is liable to be stolen with the laptop Performance impact is normally in single %age digits (unless hardware acceleration is used) - but this is typical of other FDE.
Thanks deBoetie, I dont think it is too detailed. For Bitlocker it is important to have detail as it is likely going to be the main encryption choice for PC users. Now that I have all the details I am going to put it all together and will put it up here for additional edits before creating a new thread. Thanks for putting in the work here deBoetie and Yuki.
I could use some help on the table. I have a good grasp on the Linux but the other stuff I dont feel confident on the ratings. Anyone want to chip in on some ratings or make other comments on the content?
I'll have a look and read the material again now it's assembled, thanks for your work. While I remember, Truecrypt is the only facility that provides for plausible deniability in this list, for people who want that, with the hidden stuff.
Howdy all, New user and first post, so forgive me if I haven't yet settled in. Thought I'd mention these two options for discussion. OTFE (Discontinued) [FDE?] {container] Has an explorer module that can by-pass the need for admin rights. https://en.wikipedia.org/wiki/FreeOTFE Rohos Mini Drive 1.8 (Freeware version) [container] http://www.rohos.com/products/rohos-mini-drive/ Again, can by-pass the need for admin rights. Just thought I'd mention these as it seems this topic doesn't exactly mention that most encryption set ups 'need' admin rights of some sort or another. As far as security/privacy goes, I don't have the brains enough to figure that out.
Welcome to the forum Slink. There are a ton of encryption solutions and the goal here was definitely not to cover them all. We are going open a new thread with the finished document. I think it would be a good opportunity for people to review products that they use. A good opportunity if you use either one of them regularly.
How about some hard drive self defense ? I would assume an attacker would remove the hard drive from the PC it is in and install it in a system where it could be attacked so what if the encryption app detected when it was being brute forced and after so many unsuccessful attempts it goes into hostile mode and runs an attack on the system it is in ? There are all kinds of offensive things it could try to do to the hardware in the system it is in and even other devices attached to it. Also I think it would be nice if encryption apps had two passwords, one of them would appear to decrypt the drive but at the same time overwrite sensitive data with something innocuous or misleading, so that defensive password could be given up to an adversary who has some leverage over you.
Such self-destruction function will only work on hardware-assisted encryption system, as 1) sensible attacker will firstly copy your hard drives and attack copied one. 2) they can customize the encryption software so that it doesn't have auto-erase function. I myself suggested that before and deBoetie and Palancar kindly pointed out them.
