Encryption is Not Enough

toggle-button

Last updated by site.editor on 25. November 2020 - 11:59

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.

A recent highly visible example shows that it's hard to know who's expertise to trust. [discussion] [examples of cryptographic vulnerabilities]

#2: Use of proprietary, closed-source cryptology leads to persistent folly:

  1. "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
  2. 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.

"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."

#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.

With those factors in mind, here's what I look for when reviewing encryption software or devices:

  1. 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.
  2. How much attention to detail does the developer exhibit?
  3. 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.
  4. 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?
  5. Open-source encryption software is much better than closed-source software, particularly if the software has been actively used by government and commercial entities.
  6. 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?

  1. 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.
  2. Is the program offered by an individual author? It is offered by a commercial enterprise. That's good.
  3. 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.
  4. 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.
  5. 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.
  6. Does the software have a backdoor? In my opinion, based on the nature of the product, probably not.
  7. 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: 

Your rating: None
4.5597
Average: 4.6 (134 votes)

Comments

I did not see in the foregoing discussion any mention of FIPS 140-2, the standard requirement for encryption of sensitive but non-classified government data. All official data which requires protection by encryption must be processed by mechanisms which have been certified as 140-2 compliant. The NIST Cryptographic Module Validation Program performs these tests and certifications. This is of more than passing importance because they have reported that as many as 80% of the softwares submitted for testing are rejected; certification certainly goes far toward allaying fears about the encryption. Software meeting this mandate is widely available for public use; for example PKWare, the creators of the ZIP format, sell their 140-2-compliant SecureZIP (along with PKZIP, which is not). Various Microsoft products are and are not compliant; the CMVP website has a list of validated products. Unfortunately, I am not immediately aware of any free products which are validated as compliant; this is understandable, as CMVP testing does involve an expense.

My main concern is on a Windows machine where other people have sys admin rights to read the user directory, malware, etc. All the tools I've seen have you decrypt the volume, which means the information is now vulnerable. For example, I have my USB drive encrypted, but I decrypt it so I can use my portable email client or RSS reader. But this also makes the entire volume vulnerable since it is decrypted. Ideally I want realtime encryption/decryption where the storage remains encrypted, but opened decyrpted at the time needed, and not decrypted for any other user or unauthroized use. The workaround is multiple encrypted containers: some decrypted full time, other decrypted only when needed. Another workaround I'm looking into is a virtual machine where I have more control.

I've done some more product evaluations. Volume/container encryption makes data 100% vulnerable when the volume is mounted. It simply looks like an unencrypted drive when mounted. I'm still trying to find a solution that won't leave my data vulnerable when I'm using my data.

If I understand your concern snakyjake, you are only exposed when the machine is physically available for login by multiple people. I know that is sometimes the case in the workplace. Logging off when you step away would be inconvenient, but should solve the problem.

Yes, you understand correctly. I'm trying to evaluate some folder locking/hiding utilities to see if those kind of apps can keep other people from accessing my data. When I attach my USB drive (using VeraCrypt or similar), I don't want to automatically expose all my data to everyone that has access to the machine. I also don't want search indexing the drive/folder. I want my data to be only my data.

philip,

Thanks for a good and informative article, I have read it with great interest. Since I am in the same boat as lowndesw it luckily all can remain theory for me.

Thanks for a great article, it was a pleasure to read.

One question: PGP Wholedisk Encryption seems to be Symantec Encryption nowadays. Are you sure this should be featured on Gizmo's Freeware site?

And another question: what is your stance on VeraCrypt? Does it fit your criteria for a good encryption program?

Thanks for the questions Emphyrio. It's good to have fresh input. I've annotated the line in the article about PGP Wholedisk Encryption (it's spendy for individual use). It is now Symantec Drive Encryption.

You've also motivated me to take another look at VeraCrypt. It, like TrueCrypt had some problems on Windows 8.1. TrueCrypt is OK on Windows 10, but is not maintained, and more vulnerabilities have very recently been found in it. I'm going investigate VeryCrypt on Windows 10. It looks like a promising replacement for TrueCrypt. However, I am not going to be able to validate it for full-disk encryption.

I KNOW NOTHING about any of this stuff, but find it fascinating and useful in learning about the subject plus the related interworkings of my computers. Almost wish I had something terribly important to hide.

THANKS for another great article!!