A few facts
Inconvenient fact #1 - Cryptography is harder than it looks: Not just any encryption program will do. Most any competent programmer could grab the open-source code for a block cipher (cryptographic protocol) -- say AES -- and put together an encryption process to get from password entry to ciphertext.
But there is a special Murphy's Law for budding cryptographers: Somewhere else in the naive coder's encryption process - key generation, random number generation, hash processes, etc. - there will almost certainly be one or more fatal flaws. A skilled hacker can often find and break process vulnerabilities without much effort. Do-it-yourself encryption is much like thinking you could be competitive with Bobby Fischer or Garry Kasparov [more]
As Bruce Schneier puts it in Security Pitfalls in Cryptography:
A cryptographic system can only be as strong as the encryption algorithms, digital signature algorithms, one-way hash functions, and message authentication codes it relies on. Break any of them, and you've broken the system. And just as it's possible to build a weak structure using strong materials, it's possible to build a weak cryptographic system using strong algorithms and protocols.
Just because an encryption program works doesn't mean it is secure. What happens with most products is that someone reads Applied Cryptography, chooses an algorithm and protocol, tests it to make sure it works, and thinks he's done. He's not.
Functionality does not equal quality, and no amount of beta testing will ever reveal a security flaw. Too many products are merely "buzzword compliant"; they use secure cryptography, but they are not secure.
#2: Use of proprietary, closed-source cryptology leads to persistent folly:
- "Even the strongest of the encryption algorithms can be defenseless, if it is implemented with errors, or used inappropriately, and that is the illness of the proprietary software. Microsoft is especially infamous for that, as virtually each of its cryptographic solutions had serious vulnerabilities, often breakable in a trivial manner. One need not venture far for the examples, — Kerberos, encryption of Microsoft Office documents, PPTP VPN, NTLM authentication protocol, SysKey, EFS encryption in Windows 2000, RNG implementations in Windows 2000/XP/Vista. As history shows, that company is unable to learn on its own mistakes, therefore it is better to use anything, but the Microsoft's cryptography, since, even if you would want to, you will find no worse reputation, than the one enjoyed by the Microsoft." ~Mycotopia Forum
- Encrypted devices that work well and are easy to use get high praise from users who know nothing about cryptology. One almost-amusing case makes a good example.
#3 - Operating systems are messy: They leave behind echoes (cleartext) of the data you access or process - swap files, temp files, hibernation files, browser cache files, and other artifacts.
Windows Volume Shadow Copy Service presents a special problem. Even if you wipe the file after encrypting it, the cleartext copy of previous versions remain on the drive. Even though they are hidden, it is easy enough to find and restore them.
Many simple encryption programs simply encrypt from and/or decrypt to a cleartext file. Yes, some of them delete the cleartext file after you close the program, but they may not securely purge the file (make it unrecoverable).
Using a compression -- e.g. Zip -- program for encryption can be particularly hazardous. Unless you can create, open and save files directly in the encrypted archive you'll leave clear-text version of files behind on the host computer. You must purge (not just delete) those working files. You did know that deleted files are not actually erased didn't you?
If you lose your computer, or if anyone - burglar, snatch thief, snoopy co-worker - gains access to your computer, running or not, they are likely to find cleartext echoes of your encrypted data. You may want to use full-drive encryption to prevent that. All those cleartext echoes will be encrypted when your computer is off. Be sure your program also encrypts the whole hard drive when your laptop lid is closed, not just when you turn it off.
- From the TrueCrypt manual (TrueCrypt itself is no longer recommended though):
"System [full-drive] encryption provides the highest level of security and privacy, because all files, including any temporary files that Windows and applications create on the system partition (typically, without your knowledge or consent), hibernation files, swap files, etc., are always permanently encrypted (even when power supply is suddenly interrupted). Windows also records large amounts of potentially sensitive data, such as the names and locations of files you open, applications you run, etc. All such log files and registry entries are always permanently encrypted as well."
- Full-drive encryption may not be though. Some full-drive encryption is vulnerable to attack by someone who can gain repeated physical access to your computer. [Evil-maid attack]
- Best Free Drive Encryption Utility
- 8 Reasons for Full Disk Encryption
- Bruce Schneier , a data-security expert, has recommended PGP Whole Disk Encryption, but it is now Symantec Drive Encryption, a Symantec product. It's no longer free (license is $85 per year), but it's probably good news for the encryption capability.
- Full-Disk Encryption Suites
- Comparison of disk encryption software
- Filesystem-level encryption
#4: Any encryption program can have a secret backdoor: The backdoor may simply be there to assist in recovery and other administrative functions. Some encryption is known to have mandated or coerced backdoors imposed by various government entities. There is just no way to know for sure if that is the case or not for any particular encryption solution. If there is a backdoor for any purpose, it is often easily discovered and exploited by attackers. Game over.
#5: Malware presents yet another threat: If any computer you use to access your data is infected by spyware, the cleartext (decrypted) data can easily be accessed and transmitted to an exploiter over the Internet. Encryption doesn't do a thing for you in this case. Your computer security system (or lack thereof) is what has let you down.
Final worry: Your computer and/or storage devices may be subject to search. It may be better to not have your sensitive data with you if you're traveling by air. Consider storing your data in the cloud (online in encrypted form) or accessing it over a VPN when you need it.
- The encryption must not rely on a proprietary cipher (encryption algorithm): It must use a time proven algorithm that has been extensively reviewed by the cryptographic community. Examples are AES (Rijndael), Twofish, and Serpent, plus combinations of these used in cascade. But that's just the first hurdle.
- How much attention to detail does the developer exhibit?
- I'm highly skeptical of programs offered by individual programmers, or as a feature of software that has another primary purpose. Encryption is naturally intriguing, there are excellent public algorithms available for anyone to use, but inexperienced implementation is almost always fatally flawed. In many cases, there are clear warning signs that these programs are not secure at all.
- Has the product been proven over time. Ideally it has been used for several years with no vulnerabilities being discovered. Even though a new product uses a time-proven cipher, only use will indicate how well it was incorporated by the developer. Has the software has been actively used by government and commercial entities?
- Open-source encryption software is much better than closed-source software, particularly if the software has been actively used by government and commercial entities.
- What evidence is there that the software does have an intentional or unintentional backdoor? Other than access by the entity that injected the backdoor, another hazard is that government entities or criminal hackers can often break the encryption implementation. It is very difficult evaluate this his last criterion often the only positive evidence is the attention to detail that the developer exhibits. See Inconvenient fact #4 above.
My evaluation of Pismo File Mount Audit Package provides a useful example of my approach to vetting encryption solutions.
I like the Private Folder feature of this audit package. It allows you to quickly access an encrypted file that you convert to an encrypted folder using a context menu command in Windows Explorer. The advantage is that you read and write direcctly to this folder, thus avoiding the problem of plain-text residue on your hard drive. But the critical question is the encryption trustworthy?
- Does the program rely on a proprietary encryption algorithm? No, they state that “Private Folder utilizes AES encryption and PKCS5v2 key generation.” So far, so good.
- Is the program offered by an individual author? It is offered by a commercial enterprise. That's good.
- Is it a feature of software with another primary purpose? Encryption is a recently added feature to software that has a more general primary purpose. Not so assuring.
- Has the software been proven over time? The program has been available for some time, but the encryption feature is recent. Also, I was unable to find any reviews by competent examiners. Not yet proven I guess.
- Open-source software is a better choice than closed-source software: Source code is not available for the audit package itself, but source code is available for the core functions that the audit package uses. Good sign.
- Does the software have a backdoor? In my opinion, based on the nature of the product, probably not.
- Conclusion: There are better alternatives.
Fatal backup trap:
Encryption programs that create encrypted "volumes" (files that contain encrypted files) whose file size does not change, and they often intentionally do not change "date modified", even though files in the volume have been changed or added. The purpose is to maintain plausible deniability. But the result can be that your backup system will not recognize that the volume file has changed, and will skip it in the backup. Some encryption products offer an option like, "Preserve modification timestamp of file containers." Unchecking that option will allow the "date modified" to change.
VeraCrypt and TrueCrypt are examples of programs that by default do not change the modified date. However, a few cloud backup services - Dropbox for example - check the hash value of container files, not the date, and if that changes Dropbox stores a new copy of the container file.
Related information on the pitfalls of encryption:
Please rate this article: