Hello. I have recently started using TrueCypt for encrypting information on my PC. Now, after I created a virtual drive, I had to choose an encryption algorithm. I chose AES, since I'm most familiar with it. I did some research on the algorithms, and it seems AES-256 is the most stable and strongest algorithm, although other algorithms are 512 bits and some up to 1080, isn't the bigger the better? Others such as Serpent and Twofish. Now there are some where it's a two way cross between Serpent and AES or a 3 way between AES-Twofish-Serpent. I read that when using a 3 way, the encrypted file becomes more vulnerable. Is that true? I mean, isn't it more secure if you encrypt the file with numerous algorithms over each other, each with a standalone key, or is there a catch to it? Someone care to explain? And one more thing, I don't quite understand the Hash algorithm, is it just a way of mixing the numbers and creating a key, and is choosing the right hash important for the security of your encryption?
Interesting topic bskaram. One small advice my friend. If it happens that you're a CS student. I HIGHLY recommend that you take the Information Security course. You'll find all the answers to your questions.

I also have few comments on what you wrote.

1- TrueCrypt is indeed a good choice. I've been using it for almost 4 years now. But i never worried about the level of security when encrypting my data. (it's private, but ain't important enough to care about protecting it against advanced attacks).

2- You said you're familiar with AES algorithm. Did you do any research about it ? Do you have any advanced information (and perhaps references, books, etc..) about it. I'm asking because i'm interested too.

3- An algorithm that is known and released to public use ain't a good algorithm. (That's only my opinion). Good algorithms are always kept hidden and classified... I presume that all known algorithms nowadays can be decrypted in RealTime.

4- The bigger the better. Unfortunately my friend, this is a common mistake. Choosing a large key ain't always a good solution. And 2 factors must be taken into consideration before choosing the encryption key/method.
a. the sensivity of data to be encrypted:
If data ain't that important, why wasting time and resources on encrypting with large keys and complicated methods.
b. The performance factor: it is essential to know the time required to encrypt/decrypt a message. This depends on the key used.
The longer the key is, the more time is required to decrypt the message. This is not suitable for real-life applications (exp: A UAV flying at 5000 KM away from base and controlled by a pilot. Sending/Receiving encrypted commands/information should be as fast as possible). Also, the processing power of the device sending/receiving data is crucial. For instance, i won't be using DES algorithm on a server (which is a silly choice of course - Low security algorithm on high performance system), nor AES on a mobile device with low processing power.

In my opinion, you should compromise between the 2 points discussed above (performance vs complexity). Which one to prefer over the other depends solely on application you're dealing with.
Georges wrote1- TrueCrypt is indeed a good choice. I've been using it for almost 4 years now. But i never worried about the level of security when encrypting my data. (it's private, but ain't important enough to care about protecting it against advanced attacks).
That's not answering the original poster. For once, I'd love that people on Lebgeeks started helping and answering questions instead of going into useless rants/trolls of this software is better than the other.
Georges wrote2- You said you're familiar with AES algorithm. Did you do any research about it ? Do you have any advanced information (and perhaps references, books, etc..) about it. I'm asking because i'm interested too.
Here's one :)
Georges wrote3- An algorithm that is known and released to public use ain't a good algorithm. (That's only my opinion). Good algorithms are always kept hidden and classified... I presume that all known algorithms nowadays can be decrypted in RealTime.
That's completely wrong. If an algorithm needs to be kept hidden to be effective, that means it is not safe at all. In other words, I only trust algorithms that are considered safe despite the fact that they're public like AES, SHA or RSA.
Georges wrote4- The bigger the better. Unfortunately my friend, this is a common mistake. Choosing a large key ain't always a good solution. And 2 factors must be taken into consideration before choosing the encryption key/method.
a. the sensivity of data to be encrypted:
If data ain't that important, why wasting time and resources on encrypting with large keys and complicated methods.
b. The performance factor: it is essential to know the time required to encrypt/decrypt a message. This depends on the key used.
The longer the key is, the more time is required to decrypt the message. This is not suitable for real-life applications (exp: A UAV flying at 5000 KM away from base and controlled by a pilot. Sending/Receiving encrypted commands/information should be as fast as possible). Also, the processing power of the device sending/receiving data is crucial. For instance, i won't be using DES algorithm on a server (which is a silly choice of course - Low security algorithm on high performance system), nor AES on a mobile device with low processing power.

In my opinion, you should compromise between the 2 points discussed above (performance vs complexity). Which one to prefer over the other depends solely on application you're dealing with.
That's only partially true. The original poster meant to ask if the bigger the key the safer the encryption. In that case, it is true.

However, and this is what Georges says that is correct, the more complex the encryption, the more difficult the decoding. The reason why we don't always use long keys (and mutliple encryptions like you asked) is a performance issue.

Think about encrypting a phone conversation. How aweful would it be if you had to wait for something as low as 3 sec to decode?
bskaram wroteAnd one more thing, I don't quite understand the Hash algorithm, is it just a way of mixing the numbers and creating a key, and is choosing the right hash important for the security of your encryption?
I do not really know much about data security and all this stuff but it happens that yesterday I was reading about how to secure data in ASP.NET MVC and they mentioned something about the Hash algorithm. The book said that a Hash can easily be decrypted using a Rainbow Table which can be easily found for free all over the internet. But in order to make your encryption more resistant, you should use something called "salt value", which will force the attacker to figure out the salt value then generate a totally new Rainbow table based on that value.

Just my two cents.
Edit: Post Deleted.
--
George wroteYou said you're familiar with AES algorithm. Did you do any research about it ? Do you have any advanced information (and perhaps references, books, etc..) about it. I'm asking because i'm interested too.
I'm not a university student. I don't know much about encryption, just some general knowledge. I am familiar with AES, because I researched it a bit.
http://en.wikipedia.org/wiki/Advanced_Encryption_Standard

And thanks for the information guys, you've answered some of my qeustions. So I guess I'll settle with AES...even the U.S government uses it for encryption of top secret information. But I still don't get the Hashes. @Kassem, does it mean if you don't use a hash algorithm, your encryption is useless? And what is it's use if the attacker can find the salt value and generate the proper rainbow table?
bskaram wrote@Kassem, does it mean if you don't use a hash algorithm, your encryption is useless? And what is it's use if the attacker can find the salt value and generate the proper rainbow table?
The way I understand it is that Hash is a form of encryption, so normally if you're using AES (or whatever encryption algorithm you choose), you do not really need to use the Hash algorithm. Moreover, I'm not really sure Hashing can be used for binary data and files. I think it's only used for strings and such. It is usually used for storing passwords and sensitive information inside the database.

Now about the salt, if the attacker figures out the salt value, he'll have to generate a whole new rainbow table which takes a lot of time and resources. So yeah, the salt value is basically another layer of complexity added on top of the Hash encryption.