Snake Oil Encryption at its very worst!
Written: Oct 06 '00 (Updated Oct 11 '00)
|
Product Rating:
|
|
|
Pros: ease of use
Cons: Outputs appear weak, Author makes several mistakes in recommendation, poor password process
|
|
|
| bdolcourt's Full Review: Secure |
Ever since PGP 2.6.2 was released, I have been fascinated by cryptology: the study of concealing information. After I downloaded the program, I set about learning everything I could about at art that at times seems like Voodoo. I certainly wouldn’t be considered an expert; the programming is far above me. I do, however, have a strong understanding of the concepts, actions and the potential pitfalls involved in securing information.
This product, Secure, first garnered my attention as I was looking for firewall software. I saw this product listed under encryption products. Since I wasn’t familiar with it, I thought I would checkout the product page. Every since then, it has drawn my ire. This product is simply snake oil. It violates many of the fundamental “rules” of encryption products. The design of Secure is secret. That is its flaw. It is only through detailed examination that the security of an encryption product can truly be assessed. In addition, the threat model used to build Secure is flawed. A flawed threat model yields a flawed product.
Background
There are certain things that must be understood in order to understand my problems with Secure. The first, What is the idea of strong encryption?
Strong encryption is not your everyday code. Strong encryption is resistant to all current (and hopefully future) forms of cryptanalysis. Strong products have been designed to resist differential cryptography (comparing how different plaintexts are encrypted, then using the differences to discover the key), linear cryptography (watching how individual bits change as the encryption process occurs), differential linear cryptanalysis (the combination of the two), and brute force (trying all the keys).
One must always assume that the “other side” has perfect information. You must assume that they know what product you are using and that they have some way of getting the encrypted file. Internet traffic is easy to intercept, computers are easy to access, most programs leave headers or other characteristics all over their files, basically, assuming that the other side knows everything is not an unreasonable assumption.
Key length is a great way to add security to a product. Every additional key bit requires twice the amount of time to break in a brute force attack. If it takes longer to perform a brute force attack then the information is good for, then the product is secure (assuming there is no other attack besides brute force). For example, the IDEA algorithm, with a 128 bit key, using a computer the size of the earth, would still require 1 billion years to try all the possible keys. That is the kind of security I’m talking about when I say strong encryption.
Now, I present, SECURE
The Easy Stuff
I’ll talk about the program’s interface. The program is simple to use. Using a file tree that looks very much like Windows Explorer, one selects the file. Type in your password twice, click encrypt, and your file is “unreadable.”
When I say unreadable, I mean that when I opened the resulting file, except for a brief header, I couldn’t read it in a text editor (I encrypted a text file). The encrypted file was a binary and was non-executable (just as the sparse instructions said it would be). The original file was removed.
Decryption is exactly the same. Select the encrypted file. Type your password twice. File is decrypted. There did not appear to be any errors.
Now that that is over, the attack!
There are two major parts to any encryption program, the algorithm and the implementation. Both have potential pitfalls that can reduce or even eliminate a product’s security. The security of a strong, cryptographically secure algorithm can be completely undone via a poor implementation.
The algorithm
The algorithm of any encryption product is the heart of the program. It is the mathematical function used to mix up the data so as to be unreadable. The algorithm is a key. The key is secret information that is mixed with the unencrypted data (plaintext) using the mathematical transformations of the algorithm. The resulting random looking data (ciphertext) is your encrypted file. Realize, plaintext and ciphertext do not have to refer to text only. Any type of file can be encrypted.
The first, glaring problem with secure is that the author does not disclose the details of the algorithm. No one can tell what is going on inside the program. This alone is a reason not to use the program. Encryption algorithms are interesting beasts. It is very hard to make one that does not have flaws or that can’t be snapped in half outright. Just because the author of the program can’t break the algorithm doesn’t mean it is secure.
From Bruce Schneier’s counterpane newsletter:
“Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can't break. It's not even hard. What is hard is creating an algorithm that no one else can break, even after years of analysis. And the only way to prove that is to subject the algorithm to years of analysis by the best cryptographers around.”
First off, you probably want to know who Bruce Schneier is. He is one of the founders of Counterpane Internet Security, a security company that evaluates security programs and internet security. He is also the author of “Applied Cryptography,” one of the defacto standard texts of cryptography. He is also the creator of Blowfish (an encryption algorithm which used to be quite popular in UNIX applications) and Twofish (a finalist for the US government’s Advanced Encryption Standard). He has published numerous papers on the subject of cryptography and cryptoanalysis. Basically, he is one of the guru’s of cryptography.
Who is Scott Wenger (the author of Secure)? The answer is that I don’t know. The only way I found his name, was associated with a mechanism for purchasing Secure. I actually got more relevant hits when I used mis-spellings of Schneier’s name, than I could for any possible combination of search terms using Wenger’s name and 4 separate search engines. What that basically means, Wenger is no expert. He hasn’t published on the topic of cryptography as far as I can tell.
I have found no evidence that anyone besides Wenger has ever examined the algorithm for strength and security. Is that significant? It sure is. Encryption algorithms are very fickle things. Take DES, the digital encryption standard (soon to be replaced with the Advanced Encryption Standard). Many people have tried to improve the strength of this algorithm by making various modifications. Almost unilaterally, any change made to the algorithm made it less secure. This is true for many algorithms. Small changes can make a secure algorithm insecure. Making a secure algorithm is very hard.
Since Wenger refuses to release the source code and refuses to allow his program and algorithm to be examined, the security of it can never be verified. I refuse to trust my things to some guy, without credentials, who says “Don’t Worry!”
This doesn’t mean that I know nothing about how this program works. The Secure homepage tries to explain in a very superficial way what the program does. It claims to develop a “key,” the length of the plaintext message, which is then used encrypt the file. This sounds like a Stream cipher.
A stream cipher creates a pseudorandom keystring that is then added, generally, through a bitwise XOR, to the plaintext, generating a ciphertext. Computers are actually incapable of creating random numbers. What programmers do, is use functions that yield enormous stings of numbers, then provide them with some form of input that sets up the function to generate. This yields a stream that looks random, but is repeatable. The input used to set up the generator is the password entered by the user.
At the urgings of Mobiprof, I started to run some basic analysis of the program. I encrypted known plaintexts (16.5 K of 1's, 2's or 3's) with known passwords and then compared the results using a hex dump of the file.
First, I encrypted the same text twice using the same password, spaced around an hour apart, with computer being restarted in the middle. The two binary files were equivalent. What does that mean? It means that there is nothing hidden going on in the background. The program is not selecting a key at random and then encrypting that with the user's password. The user's password is what is used to generate the key string.
Second, I encrypted the same text, using a 20 letter password. The password was the same except for the last letter was incremented by one. The hex dump was revealing. The only difference between the two ciphertexts occurred every twentieth hex block. Moreover, the difference was predictable. If the password varied at the sixth position, the ciphertext varied at the sixth position. What does this means? This program is highly susceptible to differential cryptography. The keystream varies by a predictable amount at a predictable position. The change is directly related to changes in the password. Variations have no effect on adjacent blocks.
Just to confirm, I encrypted different, but similarly structured files with the same password (strings of 2's and 3's instead of 1's). Save for 4 differences (in a 400 byte file), the files were exactly the same. By knowing some of the structures and the behavior of the compression system that this program uses, one can probably recover keybits by differential analysis. The difficulty in analyzing the program comes from not knowing how the compression works. It is kind of scary to think that the security of the program comes from the compression system of the program and not the encryption part of the program. Once it is clear how the compression works, differential cryptoanalysis should break the system, or at least yield some keybits.
Third, several passwords are equivalent. The program interprets aaaaaa exactly the same way as aaaaaaaaaa and as aaaaaaaaaaaaaaaaaaaa. Any password with any repetition may not generate a unique keystream. This program has a whole class of passwords which cause keystream collision. That just makes a brute force attack easier by eliminating some of the more random passwords.
The fourth observation is the most interesting. The program is quickly able to realize if the password is correct or incorrect. This is before the decryption takes place. To learn this, I encrypted a large, 7.9 megabyte file (It was latest version of PGP, I felt there was irony there). The encryption and decryption each took over a minute on my computer. It only took a few seconds however, for the program to determine that I had entered the wrong password. In the headers, there appears to be a 64-bit checksum of some form. This may very well be the program's weakness. In a brute force attack, one need not do multiple decryptions and then verify the plaintext, one only needs to check the password against the checksum. That will certainly speed up any brute force attack.
Depending on the strength of the one-way function the checksum uses, it may be possible to reverse the system and determine likely passwords from the checksum alone. 64-bit is not that much, it may be possible to brute force this system without too much trouble (especially if someone has a large amount of computing power and memory). Also, programs like CRC-32, which generate a checksum, were designed to catch accidental mistakes in copying and file transfer, they were not designed to resist cryptographic attack. It is not too difficult to reverse such a program and get possible inputs from the output. Even some of the common cryptographic one way functions (hash functions), such as MD5, are starting to show their wear. Collisions have been found by attacking the hash from the input and output and finding common internal states. MD5 is 128 bit function and was designed with cryptography in mind. This checksum is 64 bit and who knows how it was designed.
Basically, my analysis shows that there are several ways to approach attacking this algorithm; each of which will yield some results. While independently, each may not fracture the algorithm in half, they combine to make it far easier to attack the system than by brute force alone. That is the mark of weak cryptosystem.
Part of the problem with my analysis is that I have to speculate about some parts of the system, because the way this program works is secret. Some might argue that a secret algorithm is best. If no one knows how the file is encrypted, then no one will know how to decrypt it. Unfortunately, that is a flawed assumption.
Since the program is available, it is subject to reverse engineering. A person can take the executable program and return it to source code. This is a tedious, but not a difficult process. There was a group notorious for reverse engineering products, called the Masters of Reverse Engineering. This year, a student reverse engineered the DVD encryption scheme and discovered that it is very easy to decrypt DVDs (they are encrypted you know). People don’t just reverse engineer things to be malicious. The student who broke the DVD code just wanted to write a DVD player for UNIX...first he had to learn how one works on a Windows based machine. Expecting that the secrecy of the algorithm is going to enhance a product’s security is dead wrong. I would make a significant bet that at least one person or organization has already reverse engineered Secure.
Copyright and patents aren’t an excuse for non-disclosure either. From Cryptogram again:
“Any company that won't discuss its algorithms or protocols has something to hide. There's no other possible reason. (And don't let them tell you that it is patent-pending; as soon as they file the patent, they can discuss the technology. If they're still working on the patent, tell them to come back after they can make their technology public.)”
Implementation Problems
There are an enormous number of pitfalls in the implementation of an encryption program. There are several famous (and notorious) examples of products that used good algorithms, but made a mistake when implanting them. One particular program actually stored the key with encrypted file. Another one saved the key to disk. With multitasking, one must be sure that the key is never saved in the swapfile. Does the delete wipe and overwrite the file, or does it just mark it to be overwritten by the OS. Is Secure properly implemented, I don’t know. Without looking at the source code, no one does. “Security is a chain. It is only as strong as its weakest link (Schneier, Secrets and Lies).” If there is one break in the chain, the entire product falls apart. The average professional programmer makes one mistake in every 45 lines of code. One bug that gets through can break the whole thing. The only solution is to constantly examine a product for holes and bugs. Without this “constant vigilance (Rowling, Doomspell Tournament)” product security is questionable at best.
Just as a note, constant vigilance may not be enough. Earlier this year, a serious implementation flaw was found in PGP (most need not worry, it had to do with key recovery, a feature that most people don’t use). One of the most examined encryption products in history was found to have a serious error. So many people looked over the program and so many people missed it. It just goes to show how carefully a product needs to be examined. I’m not being hyper paranoid; I’m being realistic.
In my opinion, Secure makes a gross error. The program does not appear to “hash” passwords. Hashing, is running the password through a one-way function, then using the output of that function as the actual password. This allows the user to enter any length password they want. The password (often called a passphrase at this point), is then hashed down to the length the algorithm uses for encryption.
The reason hashing is good, is based on information theory. Analysis of English, has shown that each letter provides 1.3 bits of randomness. Each ASCII character requires 6.2 bits to represent it. In order to have 124 bits of randomness in your password, you need at least 96 characters. Secure only allows 20 characters: 26 bit encryption if you use real words. Excellent password selection can compensate (you would have to use randomly generated passwords, which brings up an other issue I don’t want to touch). Hash functions get around this problem by turning whole phases into passwords.
Here is what secure has to say about the matter:
“A very advanced and sophisticated encryption algorithm does not compensate for a poor choice of password.”
This is absolutely wrong! Advanced programs might not “compensate,” but they do help you create strong passwords from ordinary language. Secure does not. In fact, the 20 character limit is a liability. It virtually guarantees that a user is going to select bad passwords. How many people really use random passwords. I don’t mean random capitalization or random punctuation---those add some security, but are still easily broken via a brute force attack. I mean truly randomly generated passwords. Few people do...I can remember something like “The quick brown fox jumped over the lazy dog” I can’t remember &93BCldmNgvbyA@d)84#. A good program facilitates password selection, not hinders it like Secure does. For this reason alone, this product should be avoided.
As for not hashing a password:
“So, most cryptographic software will convert a passphrase into a key through a process called ``hashing'' or ``key initialization.'' Avoid cryptosystems that skip this phase by using a password directly as a key.” ---Martin Curtin (http://www.interhack.net/people/cmcurtin/snake-oil-faq.html)
Basically, on this flaw alone, Secure should be avoided.
The Threat model and other notes
By now I think it should be clear that this product should be avoided. Since the algorithm is proprietary and has not received a public review, there are too many questions about its security. Plus, it has a serious problem with its implementation by limiting password length and not hashing passphrases. This ignores all the other implementation questions. It those reasons aren’t enough, here goes the rest.
From the Secure help file:
“It is strongly recommended you use the same password for all the file you encrypt with the SECURE program.”
This is laughably wrong. If you really want a file to be secure, you never want to use the same password, especially for a streamcipher. The plaintext can be recovered. How? A streamcipher XORs the keystream with the plaintext to yield the ciphertext. To undo the process, the ciphertext is XORed with the keystream to yield the plaintext. One can take the two ciphertexts and XOR them together. This removes the keystream and leaves the two plaintexts XORed together. This new file looks like gibberish, but the two plaintexts can be extracted from each other using statistical attacks. The attack is even more devastating if some of either message can be guessed. Because of the highly structured nature of computer programs and textfiles, guessing some of the pieces isn't too hard. Once once plaintext has been broken, the keystream can be determined. The rest of the encrypted files will soon fall. This attack will break the system far faster than brute force guessing of the password. The fact that the author suggests using the same password indicates that he has no idea what he is doing.
From the secure website:
“However, steps have been taken to minimize any vulnerability to the brute force attack. These extra precautions include requiring a minimum password-length of six characters and by prohibiting command line arguments.”
The password length has been dealt with. The command line argument security is a joke as well. Reverse engineering will get around that security measure so fast, that it shouldn’t be considered a security measure at all. Once the algorithm is known, anyone can implement it. Believing that this will help resist brute force is idiotically stupid.
This actually brings me to the idea of threat model. The threat model is a statement of who and what the program is trying to protect against. Secure never says outright who and what it will protect you against, but it does imply that it is the strongest encryption product ever made. Clearly the threat model is flawed. If you do what the author recommends, you will actually make yourself vulnerable to attack by a competent cryptographer. The “features” that make the program “more” resistant to attack won’t be anymore than a minor hurdle for competent cryptographer either. If they can’t properly build a threat model, they can’t properly evaluate the product’s security.
It gets worse. Secure says that Secure encrypted files can be sent as email attachments. This is true, but there is no method for securely transmitting the password to the other person. As mentioned above, you can’t agree to use the same password without compromising the security of the system. Just another example of how the author of this program has not properly written the treat model when evaluated the security of this product. There are methods of securely transmitting a key through email, using public key cryptosystems…Secure does not implement them.
The last thing, again from the Secure website:
“The SECURE program greatly exceeds 400-bit encryption.”
This is just not correct. While the system may use a large key when setting up the algorithm, the absolute maximum size password that can be entered is 124 bits. If you include all possible 8 bit characters, then the theoretical maximum key length is 160 bits. That is only theoretical, the real max length is still 124 bits.
I think that Wenger is making a mistake when he evaluates the length of the key. Based on reading the website, it appears that he is confusing the key (password) with the keystream (what the program generates). He is saying that the keystream is over 400 bits. He is right, but then so is this opinion. Adding one more bit to the keystream does not in anyway add to the security of the ciphertext. No matter how long the keystream is, this program can only really have 124-bit security.
I also think that it is clear from my analysis, that the password is directly going to generate the keystream. There is no internal key and there is nothing strange going on behind the scenes. The only secret key is the user's password, which is 124 bits.
What it all means:
This product is snake oil, pure and simple. The algorithm appears weak and is subject to various types of cryptoanalysis. The integrity of the implementation is unknown. In addition, the author neglected to include a function that is considered essential to an encryption product (hashing). If you use this product, you are almost certain to have a poor password. That really doesn't matter however, because a good cryptographer can probably recover the plaintext by comparing adjacent memory positions. If that isn’t enough, the author has demonstrated his lack of understanding of computer security by recommending action that will defeat his own program.
This program might protect your files from being viewed by your sibling, spouse, or other random person. This program will not stop a determined cryptographer who is fully versed in cryptoanalysis. If you need higher level security that will stop a competent cryptographer, such as to protect sensitive business files, financial information, or personal information, this program won’t do it. You need something like PGP. If you don’t need this higher level of security, then why would you spend $60 on this program? The same type of stuff is available for free. Even PGP is available for free to individuals. Forget buying this junk, get something good, for nothing.
Just one last thing as an example: Proprietary Security Products are just bad.
Even the intelligent fail when behind the scenes work is kept secret. From Crypto-Gram:
“…Microsoft developed its own Point-to-Point Tunneling Protocol (PPTP) to do much the same thing. They invented their own authentication protocol, their own hash functions, and their own key-generation algorithm. Every one of these items was badly flawed. They used a known encryption algorithm, but they used it in such a way as to negate its security. They made implementation mistakes that weakened the system even further. But since they did all this work internally, no one knew that PPTP was weak”
Recommended:
No
|
|
|
|
Epinions.com ID:
bdolcourt
|
|
Member: Bram Dolcourt
Location: Valhalla, NY
Reviews written: 33
Trusted by: 35 members
About Me:
After graduating in Chemistry from Brandeis and a short EMS career, I'm a Medical Student.
|
|
|
- Add to My Yahoo!: 
- Add to Google Homepage: 
© 1999-2009 Shopping.com, Inc.