It depends on what you want to crypt with it and how you will want to access the data.
At this stage of my research, I like TrueCrypt. It's OpenSource, has great algorithms, mountable volumes, etc., etc.
So far I have only tried PGP 8, Roboform, and TrueCrypt.
The reason I haven't tried CryptoSuite or Axcrypt yet was because I need mountable volumes. Try several programs and see what you like the best.

It depends on what you want to crypt with it and how you will want to access the data.
At this stage of my research, I like TrueCrypt. It's OpenSource, has great algorithms, mountable volumes, etc., etc.
So far I have only tried PGP 8, Roboform, and TrueCrypt.
The reason I haven't tried CryptoSuite or Axcrypt yet was because I need mountable volumes. Try several programs and see what you like the best.

Click to expand...

Devinco,
What are mountable volumes? and why would one need them? What did you think of PGP 8, I've heard good things about it?

Snake oil at its worst. Sentence like "XorIt uses the XOR encryption method (also known as Vernam encryption) that can have keys the same size as the file to be encrypted" would be funny if these people did not seriously mean it. And the fact they can't even tell the difference between true one-time pad and XOR is just ridiculous. One-time pad is unbreakable encryption, but it can NOT be achieved on a regular PC, nor it is usable for practical purposes. XOR, on the other hand, is one of the weakest algorithms in existence and it takes less than a few seconds for a PC to break it.

With one-time pad, you need a TRUE entropy source to build a key, something that certainly a PC doesn't have; certainly Windows, with its absolutely pathetic random number generation, is as removed from true entropy as it gets. True random noise can be achieved with VERY few sources, one is radioactive decay... I can't see where you would attach that to a PC. With one-time pad, you can't use the same key more than one time, EVER... the key has to be stored in a secure, inaccessible area so it has to be removed from the PC every time (and its disk storage area securely deleted, e.g. overwritten for instance with Gutmann's methods). It has to be exactly the same size of the data to be encrypted.

So, let me repeat this, YOU can't EVER use the same key twice, you have to remove the key, shred its storage area, and store the key in a secured inaccessible place, and the key has to be purely random and exactly the same size as the message. What good is that? You might as well remove the original message and store that in a secure place. And which one of this absolutely necessary steps (true randomness, secure deletion, and secure physical storage of the key) does that software implement anyway? None, of course, unless you expect it to be able to implement radioactive decay and to build an impenetrable steel case and to put the new key in it every time you encrypt something.

From what I understand, there are two basic types of encryption programs (some do both). File encryptors and mountable volumes. Different programs and people call them different things, but they mean basically the same thing.

File encryptors work like a compression program similar to WinZip in their usage. You select the data you want to encrypt (pictures, music, programs, etc.) and it creates an encrypted file on your hard drive. If you want to access the files inside, you enter your password and it decrypts the files onto your hard drive where you can then work with them and then re-encrypt them when done. This leaves a trace of the data on the HD after you are done.

Mountable volumes add convenience. The intial encryption process is the same. You select files to encrypt, but now you choose to make a mountable volume. The encrypted file is the same.
But when you want to work with the files inside, you enter a password and a new drive letter is created. Lets say your hard drive is C: after "mounting" the encrypted volume, you will also have a drive D:. This new drive is fully accessible. you can read files, write files, and even run programs from within this mounted volume. You can choose the drive letter as well.
When you are done with the files, you tell the encryption software to "unmount" the drive. The extra drive letter disappears and the files are once again encrypted without leaving traces on the hard drive that the file encryptor would during the decrypt-re-encrypt process. Easy to use once you get the hang of it.

The main reason to use mountable volumes is ease of the encryption decryption process and accessiblity to your data. It also may add to security by not requiring an unencrypted copy of the file to be stored on the hard drive while working on the files. Some file encryption programs have viewers within the program so you don't have to save unencrypted files to your hard drive. But nothing beats the convenience of an accessible drive like a mountable volume. Being able to run a program from within a mounted volume can also add (just a little) to that individual programs security.

Your question about why would one need them was about mountable volumes (answered above), but I would like to take this opportunity to (climbing upon soap box) expand it briefly to why one would need encryption software.

The common misconceptions are:
I don't need encryption software because I have nothing to hide.
I don't do anything illegal, so what's the point?
Or even better, I know all that, but it's too much hassle, so why bother?
I'll give you just one reason (there are a million others) why.
Tax Software. If you use it, your SS number is sitting there on your computer's hard drive right now unencrypted ready to be viewed by crackers who can make it past your defenses. And it doesn't even take a cracker. Just a thief who steals your computer.
I think EVERYONE should use encryption software. It's easy to use, it's secure if implemented well (by the software programmer and you), and it's fun (you get to feel like a spy even when you're not).
(suddenly Devinco loses balance and falls off the soap box with a crashing thud)

Anyway, PGP 8(paid version) is very good, easy to use and has three parts:
PGP Disk which lets you create mountable volumes.
PGP Keys/email for creating encrypted emails (note: it only encrypts the contents of the email, it does not encrypt the connection.)
PGP Wipe to securely erase files.
I like it and still use it today. The paid version is not open source (but based on it). I would trust it, I've heard only good things about Mr. Zimmerman.
I did have some problems with editing files on a PGP Disk (mountable volume) on a Direct CD formatted CDRW. I have not come up with a solution to that yet.
Here is the link to them: PGP
The new desktop home 9.0 looks good feature wise. $99
The desktop pro 9.0 has a neat feature called full disk encryption. There is even an option for Alladin eToken security.
It is not cheap though at $199, $279 with eToken.
I personally wouldn't go for a subscription type thing that stops working one year later. Software should keep working after one year and if you want the new improved version, then pay for the upgrade. This is not the same type of constantly updated program like an AV or AT that would justify subscriptions. The prices I showed are for the non-subscription versions (use the program indefinately and upgrades for 1 year).
I can't comment about the open source free version or how it compares to the paid version, perhaps somebody else can shed some light on that and provide a trusted link.
I also couldn't find info on upgrading 8.02 to 9.
Maybe someone can comment on their experience with the PGP Desktop Home 9.0 and Pro.

But you don't have to spend a lot to get great encryption.
Right now I like TrueCrypt.

I've also heard good things about AxCrypt (File Encryptor).
I also hope to try CryptoSuite in the future when I have more time.
I don't think you can go wrong with any of the 4: PGP, TrueCrypt, AxCrypt, or CryptoSuite.

I've also recently learned that having enough RAM can increase security.
Not because you can run more security programs, but because you can get rid of the Virtual Memory swap file (paging file) that has been saving unencrypted copies of your files on the hard drive. I've gotten rid of the virtual memory swap file a long time ago (Windows XP Pro, 1.5GB), but it was for performance reasons. That was a real eye opener that I got from the TrueCrypt Manual.

And lastly, do the research before you install just any program on your computer and find out a trusted place to get the program from. All it takes is one malware infected program to be installed and you are done for (mitigated by your level of layered security). Many security related anti-spyware programs are in fact spyware themselves. This can also apply to other security apps as well. I even inspect programs from trusted sources just in case something slips by. If you have all the security programs, you still need to use them or it won't make any difference.

There is a lot of great info on encryption here at Wilders as well, just give it a quick search for some good reading. And just because a post is old, doesn't mean the security concept or idea is outdated. Programs will change and improve, but newer does not necessarily equal better.
(The soap box is calling me again, I'd better go!)

The definition of best will change as technology progresses down the road, but for now, anything > 128-bits depending on how safe you think you want to be for however long that remains to be seen - i.e. until it is cracked.

PGP Desktop 8.0 thats what ive used previously pretty good software for encrypting stuff you have dont know of other viable alternatives...

Click to expand...

GnuPG, the open source equivalent to PGP. It does NOT securely delete files (but you can get Eraser for that, here, it has better 'shredding' capabilities than PGP as it uses Gutmann's method), and it doesn't have a visual interface (but there are front ends for that, i.e. for Thunderbird you can get Enigmail, for Outlook Express and general file capabilities WinPT). I haven't tried WinPT, but Enigmail works perfectly. There is a lot of GPL or BSD-licensed security software around.

The definition of best will change as technology progresses down the road, but for now, anything > 128-bits depending on how safe you think you want to be for however long that remains to be seen - i.e. until it is cracked.

Click to expand...

Well, for symmetric algorithms regarded as secure (AES, Blowfish, Serpent) 128 bits seems the minimum standard for real security. Public key encryption (like PGP/GnuPG) is a whole different matter, keys have to be WAY bigger than that, 1024 bits or more.

XOR, on the other hand, is one of the weakest algorithms in existence and it takes less than a few seconds for a PC to break it.

Click to expand...

If you want I can provide you with some files encrypted with XorIt and you can back up that statement with some proof. I can even make them use the same key file to make it possible.

Before calling my software "Snake Oil" you should look up more on OTP keys. You would then learn that there is no need for a "TRUE entropy source" at all, just a decently random file. Providing you do not use it twice then it is unbreakable. Perhaps you should read your own quote as Bruce Schneier says much the same.

I'm not a cryptoanalyst; to say "I challenge you to break it" doesn't make your software look any better. Perhaps (although I doubt it) it would take me a long time to break it, but it would take nothing for somebody with true deep knowledge of cryptosystems. NOTHING.

Before calling my software "Snake Oil" you should look up more on OTP keys. You would then learn that there is no need for a "TRUE entropy source" at all, just a decently random file. Providing you do not use it twice then it is unbreakable. Perhaps you should read your own quote as Bruce Schneier says much the same.

Click to expand...

"The caveat, and this is a big one, is that the key letters have to be generated randomly [...] Using a pseudo-random generator doesn't count; they always have nonrandom properties".

Bruce Schneier on One-Time Pads, Applied Cryptography, page 16.

Incidently, XOR is not an algorithm.

Click to expand...

"The simple XOR algorithm is really an embarassment; it's nothing more than a Vigenère polyalphabetic cipher [...] there is no real security here. This kind of encryption is trivial to break, even without computers."

Bruce Schneier on XOR, Applied Cryptography, page 14.

Your software is snake oil, and that's all there is to it. Perhaps you should submit to real cryptography engineers, they sure would like to have a laugh. The most your software can do is hide something from your little sister, certainly not from "hackers".

Please do not make personal comments, this thread is interesting and does not need them.
I am sure that one of the crypto experts that visit here will add their comments but based on facts and not vitriol.

Perhaps you should submit to real cryptography engineers, they sure would like to have a laugh. The most your software can do is hide something from your little sister, certainly not from "hackers".

Click to expand...

Well, yes of course it's not secure. XOR is the easiest "encryption" to break!
I tell you why: Because you know EXACTLY the XOR KEY on special positions in a file!

Example (that even the author of this program understands about what we are speaking here)

If you XOR 00h (Zero) with the XOR Key the result will be ALWAYS the Key Byte! There you have the first weakness! Now lets continue this story...

Assuming you encrypt a executable - DOESNT MATTER WITH WHICH KEYFILE - it would be possible to reconstruct your keyfile step by step. Takes probably some time (and is useless to prove, just believe me, we deal DAILY with such encryption in Viruses...)

For instance you know that the First 2 Bytes in a executable are always "MZ"... right.... the difference is the first 2 bytes xor key. Then you will most likely have "This Program cannot run in dos blablabla".... The next point to start to collect more information about the Key.... And the bummer comes now:

Once you reconstructed this PE Header (because you know there what has to come where... even without knowing this executable!) you have the header of this XOR Key.... If you see that another executable was used as key it's easy to extend this key. Or Bitmap - almost every file has a fileheader with well known structures and offsets.

The problem is here always that you might use a file as Key which is available on every other machine! After such small inspectations with these header things you could even try to organise such a file if you don't have it!

Make a google search for "X-Raying" and Antivirus, and you will see HOW EASY it is to break XOR. ;-) Even if you have a very long key - based on this fact that XOR with 00 ALWAYS is the key you can start to rebuild the keyfile.

If you XOR 00h (Zero) with the XOR Key the result will be ALWAYS the Key Byte!

Click to expand...

Not true. If you have a null then at a position either the file or the key is null at that point. This is true for most encryption. Besides, where does that help you if the key file is not a stream cypher?

Quoting Bruce Schneier on OTP is like quoting Bill Gates on open source. But you have me curious. Here is a file that is not impossible to decrypt.

OTP encryption has its problems, that I do not deny. But it does have the huge advantage that one cannot just press a button and wait for it to be decrypted. Even if there are the clues that you mentioned it will take a while to decrypt it. This file has those clues, several big ones in fact.

Wow! This thread has surely escalated in complexity, but I like it and I'm learning a lot as a result. Keep it up.

Devinco said:

I've also recently learned that having enough RAM can increase security.
Not because you can run more security programs, but because you can get rid of the Virtual Memory swap file (paging file) that has been saving unencrypted copies of your files on the hard drive. I've gotten rid of the virtual memory swap file a long time ago (Windows XP Pro, 1.5GB), but it was for performance reasons. That was a real eye opener that I got from the TrueCrypt Manual

Click to expand...

Devinco,
Not to discount all the relevant information that you've offerred, but on the above quote can you give me more information. What is the threshold, in terms of system capabilities, at which someone can eliminate the paging file for performance reasons? My system is pretty stout, so I would consider eliminating the paging file, but are there any negative aspects to doing so?

Not true. If you have a null then at a position either the file or the key is null at that point.

Click to expand...

You don't get it - do you? Do you think i'm stupid? I'm working in this area for around 10 years. Your reference please? The point is THAT YOU CAN REBUILD THIS KEYFILE BASED ON KNOWN FILESTRUCTURES! To prove to you that i know about what i'm speaking - your "register function" in your XOR program has a bug. I'm telling you this because i saw this in the first minit without even take a closer look to your "encrypter" - that is work expierence!

Let's sum it up guy - before you're telling me that i do not know about what i'm talking - take a closer look to your program yourself

Attached Files:

And here, in Screenshot 2 we see that EAX gets compared with 80h - HUH?

If you take a closer look to the first routine you will recognise that regardingless what you input EAX will be always 128 ( equ 80h ) when you input a 128 byte string! Meaning this condition is then True and "Thanks for your support!" Before you start to try to educate people from things where you have no knownledge you should accept the fact that in a forum - where you advertise as a guest your program are always people which might have better knownledge then you. ( There are lot's of good encryption guys here, and i'm sure everyone would agree )

Attached Files:

So let me get this straight. You were investigating my registration routine. Why? Is this some new decrytion technique that 10 years in security has taught you? Seems to me like Cracker skills to me.

You are wrong about the routine. Did you actually try it out? I just did and it will not accept any 128 byte string. It used to work like that though but cracker activity forced me to make it slightly harder to crack. But it still is easy as I would rather spend time on the program itself than a registration routine. If you looked further into the code you would have noticed that in the code decrypt routine itself there are several further tests, any of those can clear the accept flag. I programmed it that way to make it confusing for crackers. One of the advantages in programming in assembly.

I never said you were stupid, and I apoligise if I seemed rude. I was not trying to educate at all, I was just defending my program when a user told me about the "Snake Oil" line. Since I just seem to be annoying you and others I will go.

Not true. If you have a null then at a position either the file or the key is null at that point. This is true for most encryption. Besides, where does that help you if the key file is not a stream cypher?

Quoting Bruce Schneier on OTP is like quoting Bill Gates on open source. But you have me curious. Here is a file that is not impossible to decrypt.

OTP encryption has its problems, that I do not deny. But it does have the huge advantage that one cannot just press a button and wait for it to be decrypted. Even if there are the clues that you mentioned it will take a while to decrypt it. This file has those clues, several big ones in fact.

Click to expand...

_________________________

Quote Inspector Clouseau: "and is useless to prove, just believe me, we deal DAILY with such encryption in Viruses..."

No freakin way do I just 'take somebodys word for' ANYTHING.

PROVE IT.

Point is the integrity of both product and developer have been called into question by two posters -one who claims to crack daily such encryption.

The developer has issued a challenge, and the seconds are ticking. If people honestly have best intentions in wallet, then this question will be resolved in this topic.

I've read countless reports over time that the PF should be about 1 1/2 times your RAM. If you have around a Gig of it or more, then unless your into heavy graphics artwork etc you most probably don't need one ! Try disabling it for a few days etc, and see if it works for you. Don't forget to keep saving your files though, just in case you have a crash.

As for encryption i have used Axcrypt often, and can highly recommend it.

If you decide to stay with a PF then it's good practice anyway to wipe it frequently for Security/Privacy reasons.

Here's a couple of suggestions for you. One dedicated to the task, the second includes this and numerous other security etc tweaks also. I use the second one.

. . .

Clear Pagefile on System Shutdown

As an added security precaution it is possible to clear all data that has been written to the page file so it cannot be retrieved. The downside to this tweak is that it may substantially increase shutdown time depending on the amount of data in the page file.

The xp-AntiSpy is a little utility that lets you disable some built-in update and authentication 'features' in WindowsXP.

For example, there's a service running in the background which is called 'Automatic Updates'. I don't know what this service transfers from my machine to other machines on the internet, especially the MS ones. So I play it safe and disable such functions.

If you like, you can even disable these functions manually, by going through the System and checking or unchecking some checkboxes. This will take you approximately half an hour. But why wast time when a little neat utility can do the same in 1 minute?

This utility was successfully tested by lots of users, and was found to disable all the known 'Suspicious' Functions in WindowsXP. It's customiseable, but comes up with the Default settings, which are recommended.

The developer has issued a challenge, and the seconds are ticking. If people honestly have best intentions in wallet, then this question will be resolved in this topic.

Click to expand...

If you would understand XOR encryption and what Inspector Clouseau was talking about you would also post the original file.

One of the most important rules of cryptography is that the algrithm is only considered secure when you cannot derive the key or the algorithm if you have both the original and the encrypted data. AES and Blowfish for example have this feature.

So please, provide us the original data file.

XOR encryption is extremely weak when you are not using one-time-pads. Are you using one-time-pads?

I did decode DOS viruses that used XOR encrypted on-the-fly back in 1992 already with x-raying. Really ooooooooooooooooooold technique...

If you want a reliable and secure encryption program, use TrueCrypt. It's open source and uses known and reliable cryptographic algorithms. Don't trust any closed source software for encryption.

htt_ //www.truecrypt.org/

[/PARANOID MODE ON]
Because Blowfish and AES are already a few years old I would even consider those insecure by now. The NSA surely has found methods to break them by now. Same applies to PGP/RSA with keys below 4096 bit.
[/PARANOID MODE OFF]

Say that you have a 5 MB file that you absolutely want to keep secret. So you use your XorIt program to encrypt it with a 5 MB key. Let's assume for the sake of the argument that the key is perfectly random. Now you have a new 5 MB key file that you need to keep secret in order not to compromise the original file. Whatever method you use that keep this new 5 MB file secret you could just as well have used on the original file. Do you consider this a problem with your program?

No, why should I? It is a limitation of the OTP encryption method, not the program. The limitations as well as the advantages of OTP are well known. In short, unbreakable encryption providing you keep the keys secure. If you are an expert then you would already know this, so I don't see why you are asking me. I have just written a XOR encryptor that can be used with OTP.

But to answer your question, OTP is not useful all situations. OTP encryption is usefull the passing of pre-planned transfers. It is also good if you encrypt a file and store the OTP at another location. This is how it has been used for almost 100 years. These days with USB keys and portable hard drives you have other options.

Stefan, positing the original file does not make any sense. The method is not secret, the file and the code are. The method is not "closed source" and there is no alogrythm to prove or disprove. The method is;

Source XOR Key -> Encrypted file

(Yes I am using OTP. Using a stream-cypther to XOR the files would make little sense. But I have specially designed this file so it can be decrypted.)

Every encryption method can be broken, except OTP. That is the use of the method. It may be a pain to use. but the results make it worth it.

Andrew Glina (AKA Sinner. I only used the Sinner name to highlight I am the author.)