Encryption Software

[dallen]

What are considered the best encryption softwares on the market? Which is the best?

[Devinco]

Hi Dallen,

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.

[Pilli]

Hi Dallen, I have moved your post from the CryptoSuite dedicated support forum to here where an open discusion of this sort is better placed.

Thank you. Pilli :)

[no_can_do]

Try hacking files scrambled with this soft:

http://www.sinnercomputing.com/XorIt.htm

[dallen]

{QUOTE-> Hi Dallen,

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. <-QUOTE}
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?

[TNT]

{QUOTE-> Try hacking files scrambled with this soft:

http://www.sinnercomputing.com/XorIt.htm <-QUOTE}
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.

More from Bruce Schneier here http://www.schneier.com/crypto-gram-0210.html#7

Please don't use that software. Please.

[Devinco]

Dallen,

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 (http://www.pgp.com/)
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 (http://www.truecrypt.org/).

I've also heard good things about AxCrypt (http://axcrypt.sourceforge.net/) (File Encryptor).
I also hope to try CryptoSuite (http://www.ghostsecurity.com/index.php?page=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!)

[lotuseclat79]

{QUOTE-> What are considered the best encryption softwares on the market? Which is the best? <-QUOTE}
Hi dallen,

* Data Encryption (Files, network) - (freeware)
Blowfish: http://www.schneier.com/blowfish.html - Block cipher:
64-bit block, Variable key length: 32-448 bits

* Stronger encryption functions than MD5 (128bit) and SHA-1:
Whirpool(512bit): http://en.wikipedia.org/wiki/WHIRLPOOL
Ripemd(160,128,320bit): http://en.wikipedia.org/wiki/RIPEMD-160
Sha-2(256,512bit): http://en.wikipedia.org/wiki/SHA-2

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.

Checkout post #13 and #14 here (http://www.wilderssecurity.com/showthread.php?p=561538#post561538).

-- Tom

[Siro]

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

[TNT]

{QUOTE-> PGP Desktop 8.0 thats what ive used previously pretty good software for encrypting stuff you have dont know of other viable alternatives... <-QUOTE}
GnuPG (http://www.gnupg.org), the open source equivalent to PGP. It does NOT securely delete files (but you can get Eraser for that, here (http://www.heidi.ie/eraser/), it has better 'shredding' capabilities than PGP as it uses Gutmann's method (http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html)), and it doesn't have a visual interface (but there are front ends for that, i.e. for Thunderbird you can get Enigmail (http://enigmail.mozdev.org/), for Outlook Express and general file capabilities WinPT (http://www.winpt.org)). I haven't tried WinPT, but Enigmail works perfectly. There is a lot of GPL or BSD-licensed security software around.

[TNT]

{QUOTE-> 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. <-QUOTE}

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.

[Sinner]

{QUOTE-> 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. <-QUOTE}

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.

Incidently, XOR is not an algorithm.

[TNT]

{QUOTE-> 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. <-QUOTE}"In the world of cryptography, we assume something is broken until we have evidence to the contrary. (And I mean evidence, not proof.)"

http://www.schneier.com/crypto-gram-0302.html#4

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.

{QUOTE-> 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. <-QUOTE}"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.

{QUOTE-> Incidently, XOR is not an algorithm. <-QUOTE}"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".

[Pilli]

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.

Thanks. Pilli

[Inspector Clouseau]

{QUOTE-> 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". <-QUOTE}

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.

8^) H.B

[Sinner]

{QUOTE-> If you XOR 00h (Zero) with the XOR Key the result will be ALWAYS the Key Byte! <-QUOTE}

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.

hxxp://www.SinnerComputing.com/Misc/XORFileA.X

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.

[dallen]

Wow! This thread has surely escalated in complexity, but I like it and I'm learning a lot as a result. Keep it up.
{QUOTE-> 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 <-QUOTE}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?

[Inspector Clouseau]

{QUOTE-> Not true. If you have a null then at a position either the file or the key is null at that point. <-QUOTE}

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 ::)

Screenshot #1 shows your Registration Verify (called before your mistake comes)

[Inspector Clouseau]

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

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 )

[Sinner]

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.

[justdoit]

{QUOTE-> 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.

hxxp://www.SinnerComputing.com/Misc/XORFileA.X

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. <-QUOTE}
_________________________

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.

DECRYPT THE FILE.

[StevieO]

Hi Dallen,

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.

Registry Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

Modify/Create the Value Data Type(s) and Value Name(s) as detailed below.

Data Type: REG_DWORD [Dword Value] // Value Name: ClearPageFileAtShutdown

Setting for Value Data: [0 = Clear Page File Disabled / 1 = Clear Page File Enabled]

Exit Registry and Reboot

http://www.theeldergeek.com/clear_pagefile_on_system_shutdown.htm



xp-AntiSpy

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.

http://www.softpedia.com/progScreenshots/XPAntispy-Screenshot-3593.html

. . .


StevieO

[Stefan Kurtzhals]

{QUOTE-> 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. <-QUOTE}

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]

[Magnus Mischel]

Sinner, I have a question for you:

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?

[Andrew Glina]

{QUOTE-> Do you consider this a problem with your program? <-QUOTE}

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

[TNT]

{QUOTE-> 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.

DECRYPT THE FILE. <-QUOTE}You obviously are completely unaware of such things as "known plaintext attacks", "chosen plaintext attacks", "adaptive chosen plaintext attacks", etc. These are fundamentals of modern cryptography (and for the testing of algorithms' strengths).

In fact, your entire post screams "I have no idea what I'm talking about". Sorry.

[Andrew Glina]

Well this debate has got silly. Since no one has accepted and completed my challenge then I can't see any point in coming back here. People seemed more interested in insulting OTP and even my program in preference to trying to achieve a possible decryption. Perhaps the reason why you didn't try is because you didn't care, but if you didn't care then you should have just ignored the initial post about XorIt (not written by me incidently). Instead with claims like it would take "less than a few seconds for a PC to break it" and 'XOR is the easiest "encryption" to break' I though that there might be something that I could learn here about XOR and OTP encryption. I was wrong and I am annoyed that I have wasted my time.

I have removed the file from my site. For the record, the file was a JPG encrypted with a Windows Service Pack. I was hoping that someone could use header methods to decypt enough of the start to ID the key file. Hardly unbreakable, unlike a true OTP key, but I chose that as a key file to highlight there there are other options for key transfer. If the file is not the KFC secret spices all you need to do is make it really hard. Another method of generating long keys that are decently secure is using a Blum Blum Shub generator.

[Inspector Clouseau]

Do you really think we do not know this already? By the way this picture was created by Adobe ::)

As i told you before - HEADERS !
And to prove it here are some explainings on your file:

[Inspector Clouseau]

Story continues.... here we have a original jpg file:

Again, some comments regarding your encrypted file.

[Inspector Clouseau]

Encrypting files with executables and known file structures is the weak point !
Nobody says that a one-time-pad is unsecure! But as you can see this encryption with this "environment" is EASILY breakable. Sure it takes some time - time which i do not have right now to decrypt parts of the file by hand (even without having this executable !!!!!!!!!!!!!!) because i have to take care of numerous new bagle worms and downloaders at this time. But i think this short lesson should be enough to prove my first comment "you can always decrypt files based on known filestructure with XOR" - as long as you use 2 filetypes. If you use REALLY HIGHLY RANDOMIZED DATA ( just the Rnd function / randomize is NOT SECURE FOR THIS! ) this becomes of course much more difficulter. But with 2 known file structures it's a easy game and you will probably always win this game if you know exacly how the fileformats are looking and what comes where and where you have "variable" byte sequences. ::)

Enough now, back to work.

[no_can_do]

No apology necessary. It is obvious from your posts that you are young and inexperienced. If you were wise you would have recognized the unique opportunity that was presented here to the Wilders community. Why did you, TNT, not decrypt the file in seconds as you claimed possible? Although full of confidence (and boasting of experience), HappyBoy also failed to decrypt the test file. This topic will forever be a testament to both of your inability to do so.

@Andrew

First, congratulations for displaying evidence of your products successful implementation of unbreakable encryption.

Second, when I first contacted you for clarification of your programs function in regards to TNT's original posting I had no idea you would post in this topic, nor was it my intention for you to do so. And I certainly did NOT expect nor desire for you to to be subjected to personal attacks from children.

Finally, I would suggest you take legal action against wilderssecurity forums and the Eset mod in particular for the screenshots detailing reverse engineering of your programs registration section.

Once again, thanks for helping me understand the complex subject of OTP/Vernam encryption..

Lyn

[_Lyn_]

"Sure it takes some time - time which i do not have right now ..."


Somehow, I knew that was coming LOL.

[TNT]

{QUOTE-> First, congratulations for displaying evidence of your products successful implementation of unbreakable encryption. <-QUOTE}

Psssst... Inspector Clouseau just broke it.

Anyway, if you believe this product works, just use it and put all you secrets in there. But don't force use to accept this kind of 'product' as secure, because we know better.

Cryptography is a scientific matter; this 'XorIt' for all it's been said and done, might as well be called vodoo.

[TNT]

{QUOTE-> "Sure it takes some time - time which i do not have right now ..."


Somehow, I knew that was coming LOL. <-QUOTE}

What's your point? What do you think the point of strong encryption is, to defend against a challenge thrown at random on a few people on a forum who have absolutely nothing to gain by spending time trying to break it (no money, no job promotion)?

[Andrew Glina]

I did seriously consider it actually, but three reasons make it impractical. 1. Different Country, 2. I don't know his real name, and 3. I can't be stuffed. Besides, he did not reverse engineer it anyway as he was wrong. (Is is a crime to attempt to reverse engineer software?)

I am quite astonished though that Inspector Clouseau is boasting that he has worked out that it was a JPEG and an executible after I had already mentioned on the forum that it was. Perhaps if I told him it was Service Pack 4 for Windows 2000 he will boast that he deduced that too. Inspector Clouseau, I will say it again. I chose an executable and a image file as you boasted that you could decrypt a file based on a PE header. Thus I gave you one. You failed to do this in the time you claimed. I will say it yet again; I chose the filetypes as they were weak. I wanted you to decrypt the file. As I said;
"...But I have specially designed this file so it can be decrypted..." You failed the challenge. I was planning to give you a second challenge, an hard one, after you decrypted the first. After all, I though since you deal with this type of encryption daily you would pick that it was an executible, work out what one, and then decrypt the whole file.

Inspector Clouseau, if you want a real challenge with a time frame (what ever you want) just ask. Otherwise I consider my point proven that XorIt can make completely secure files and cannot be decrypted in a few seconds. (Even when bad keys are used.) But honestly, I recomend you either ignore this post, or just continue the mindless retoric as the point does not need to be proven at all anyway. Several sites including...

http://en.wikipedia.org/wiki/One-time_pad

...and...

http://www.ranum.com/security/computer_security/papers/otp-faq/

...agree anyway. I will try to remember to check this site again in a few days but I will not post any further replies unless you accept the challenge.

[TNT]

{QUOTE-> Inspector Clouseau, if you want a real challenge with a time frame (what ever you want) just ask. Otherwise I consider my point proven that XorIt can make completely secure files and cannot be decrypted in a few seconds. (Even when bad keys are used.) But honestly, I recomend you either ignore this post, or just continue the mindless retoric as the point does not need to be proven at all anyway. Several sites including...

http://en.wikipedia.org/wiki/One-time_pad

...and...

http://www.ranum.com/security/computer_security/papers/otp-faq/

...agree anyway. I will try to remember to check this site again in a few days but I will not post any further replies unless you accept the challenge. <-QUOTE}

I know about One-Time Pads, clearly much more than you. I said it once, and I'll say it again: if you honestly think your product is secure, please ask the opinion by people like Bruce Schneier, or Matt Blaze, or D.J. Bernstein; show us the source (remember, security should only reside in the key, which for OTP must be COMPLETELY RANDOM as said in the texts you quoted but did not bother to follow). Or put a money prize on your site for anyone who breaks it (you should not be afraid to do so if you product is really 'unbreakable').

Your challenge as it is, is utterly worthless. You can take a piece of a file, apply a simple proprietary bijective compression and it would be just as "hard" to identify it without even using a key.

And for the "I'll sue him" part, don't make me laugh. You're the one who should be sued for selling a product that does not do what it claims.

[_Lyn_]

@ Inspector Clouseau

All you found were the headers Andrew and i knew were there. So you knew it was a jpg? So did I. Guess that makes me an expert too!

This file was a test of persons abilities to decrypt using a common file as key. Of course it is possible to gather info from headers when using such keys. Of course in practice you wouldn't want to use known servicepack.exe to encrypt whistleblower.xml. It is not a random key! But fact remains you still did NOT decrypt the file. You examined headers as did i. Now that you are aware of this lets move forward.

TRUE: The strength of encryption is only as secure the files themselves.

Anyone with basic knowledge of XorIt can create files that are unbreakable. Here is example: I suggest it is best to encrypt both source + key, then combine the two. You will NOT be able to decrypt it in billions of years without the encrypted keys that only exists on DVD in my possession.

Do you now understand???

@TNT:
You do not know what you are talking about. I ask you one last time: why did you not decrypt XORFileA.X?

[TNT]

~snip....removed info not meant for public knowledge....Bubba~

Now you know what you're dealing with.

[Brian N]

haha, busted! ;D ;D

[herbalist]

I didn't see Scramdisk mentioned so I'll ask. I've been using 3.01R3 on my 98 unit for some time. I like its ability to encrypt partitions or entire small drives and the ability to put it on a floppy for use in other computers.
I know it's been around for a long time. It was recommended to me years ago by an individual (now deceased) who tested such programs for deliberately planted weaknesses and back doors. At that time, he said it was one of the best. Has Scramdisk 3.01 itself ever been proven vulnerable or weak or does it just have compatibility issues with a newer OS?
I also use PGP 6.5.8ckt08, which works very well on win 98 and with the other software I use. What's your opinion regarding it and the PGP disk component that comes with it?
Rick

[dallen]

{QUOTE-> Finally, I would suggest you take legal action against wilderssecurity forums and the Eset mod in particular for the screenshots detailing reverse engineering of your programs registration section. <-QUOTE}Lyn, as if that is your name, there is no reason to introduce bogus legal threats into this thread. It has deviated far enough from the topic I posed and does not need unsubstantiated legal threats.

[TNT]

To put an end on this, I will quote some of the text on Wikipedia that the author of the software (unwisely, I'd say) linked to:

"Vernam's system was a cipher that combined a message with a key read from paper tape. In its original form, Vernam's system was not theoretically unbreakable — this came only later when Joseph Mauborgne recognized that the key tape needs to be completely random."

"Despite the strong proof of security, the one-time pad has drawbacks in practice: it requires perfectly random one-time pads"

"All too often people are misled by the presence of "random number generator" functions in computer programming languages and assume they can be used to make an unbreakable encryption system using the one time pad principle. Such functions are almost always pseudorandom number generators, and cryptographically weak ones at that."

"Many vendors selling proprietary encryption schemes use "one time pad" as an advertising slogan. Such systems often fail to meet the exacting standards needed to be a true one time pad. Most are just another stream cipher, but have not been subject to extensive review of standard methods. See: snake oil cryptography."


From the Snake Oil section:

"Cryptosystems based on one-time pads for which the key material 'pads' are generated or expanded by the software cryptosystem, by the operating system, or provided by the vendor. While the one-time pad has a proof of security, it is argued that a system based on the one-time pad would be too impractical to be of any use for most applications. The one-time pad requires large amounts of truly random key material, which then needs to be transferred securely to the recipient of the encrypted message. A truly random sequence cannot be identically reproduced, hence a pad generated at both ends, rather than generated at a single point and transferred, cannot be random. Moreover, it is also argued that many applications claiming to use the one-time pad are, upon close inspection, generating the key using deterministic methods, losing the proof of unbreakability."


From the Snake Oil FAQ: http://www.interhack.net/people/cmcurtin/snake-oil-faq.html#SECTION00057000000000000000

"A vendor might claim the system uses a one-time-pad (OTP), which is provably unbreakable. Technically, the encrypted output of an OTP system is equally likely to decrypt to any same-size plaintext. For example,

598v *$_+~ xCtMB0

has an equal chance of decrypting to any of these:

the answer is yes
the answer is no!
you are a weenie!

Snake oil vendors will try to capitalize on the known strength of an OTP. But it is important to understand that any variation in the implementation means that it is not an OTP and has nowhere near the security of an OTP.

An OTP system works by having a ``pad'' of random bits in the possession of both the sender and recipient, but absolutely no one else. Originally, paper pads were used before general-purpose computers came into being. The pad must be sent from one party to the other securely, such as in a locked briefcase handcuffed to the carrier.

To encrypt an n -bit message, the next n bits in the pad are used as a key. After the bits are used from the pad, they're destroyed, and can never be used again.

The bits in the pad cannot be generated by an algorithm or cipher. They must be truly random, using a real random source such as specialized hardware, radioactive decay timings, etc. Some snake oil vendors will try to dance around this issue, and talk about functions they perform on the bit stream, things they do with the bit stream vs. the plaintext, or something similar. But this still doesn't change the fact that anything that doesn't use real random bits is not an OTP. The important part of an OTP is the source of the bits, not what one does with them."

[Andrew Glina]

You guys. First I will claify one thing, I have no intention of suing anyone, and I think Lyn was joking anyway. If Inspector Clouseau wants to act like a cracker then that is his problem and it is in no way the fault of this forum.


To Inspector Clouseau

I thought it was obvious that there were only two people who weren't on the Dark Side here; Me and Lyn. I have gone by the name of Sinner or Andrew Glina and I made it clear when I switched my name.

TNT

Interesting selective quoting of Wikipedia. You have selected all of the negative comments you could find. But don't worry; I do not match the description of Snake Oil;

1. I make it clear that for absolute security you need a unpredictable file (even though a service pack will do)
2. While I in a new Beta version of CryptIt (but not XorIt) provide a stream cipher generator using RC4, I do discourage using if you want absolute security. (It was a requested feature and I try to please my users)
3. I do not make any claim that the file can be decrypted without the transfering the key.
4. I do not provide any keys.
5. I do stress the the file must be unpredictable, especially in the new Beta of CryptIt.
6. I do not have any secret algorithm. This is it in pseudo code of the routine.

10 Load File and Key
20 XOR One DWORD with another DWORD
30 Incremement memory pointer
40 Goto 20

or in assembly

mov edi, [hBlockA]
mov esi, [hBlockB]
xor eax, eax
inc edi
inc esi

I do not understand why TNT and Inspector Clouseau are so convinced I am trying to be decietful, and to be honest I find it quite offensive. The only reason why I persist in this silly debate is because I know I am right and I think that you guys have just accidently grouped me in with the "Easy OTP" club. But, I make no such claims. If one of you actually took the time to look at the software you would discover this as it is the honest truth.

Surely you must acknowledge that there are some people in the world who have a secure source of OTP keys, even if they make it using the scrabble method. Surely you agree that it is possible to write a program that uses these unprovided user generated OTP files and simply XORs them with their original file. That is all that XorIt does. The program is 30KB! How could it do any more!

Please give me a chance and stop automatically insulting my work without giving it a fair chance.

[_Lyn_]

TNT, I have posted more than double the #'s of posts @ wilders over the last years than your nick' -all_anon. Iam known (or have been known) by different names across many bbs. Is a posters identity more important to you than the information/opinion they are providing for benefit of others? Many people choose not to register for different reasons. Registration is not required @ wilders, so what is your point? If you disagree you should bring the issue before Paul, who has far more complete records of my ip than you or Inspector Clouseau dream of.

In case you missed it, the first part of the dallens question is about which encryption soft are *considered* the best, the second part which *is* the best. A loaded question, but nonetheless, since I do have an opinion i wanted to share with dallen - and other visitors to this thread - i decided to add it as i frequently do. In response to dallen's question I posted as no_can_do for i believed it impossible to decrypt a file created with XorIt, which evidently turned out to be TRUE. Must I go into irrelevent details such as individual posting style? ? I simply posted "try hacking a file scrambled with this soft" and provided a link to Andrews program. I used the word *scrambled* so that even a novice like yourself could understand, and learn this encryption soft is DIFFERENT FROM OTHER SOFTS: With XorIt there is no password to be cracked!

Due to this posting of Inspector Clouseau: "and is useless to prove, just believe me, we deal DAILY with such encryption in Viruses.." I posted as justdoit because it is inappropriate he is asking people to have great *faith* rather than use his supposed skills to prove otherwise. I will call to account ANY soft dev, ANYWHERE when i see statements like that, and you should too. Hence, "justdoit" instead of making excuses. Get it? Good.

After your amazing non-response in #26 I identified myself again as no_can_do so that you, TNT, might know that no_can_do and justdoit are one and the same poster. Apparently you are not good at detecting subtleties, for bottom of (what i thought to be) my final post #31 is the name "Lyn". As it happens while i was typing my reply to your #26, both Andrew and Inspector Clouseau had posted! When i seen Inspector Clouseau was "too busy" to decrypt the file (even tho he examined headers) I posted #37 using my real name, Lyn, to identify myself, as i did at the bottom of previous post.

Busted? Hardly. I provide my name. This is something i have never done on public forum. Here I have given you a clue. The onboard experts have better odds to determine who iam than skills decrypting a decryptable file created by XorIt. Hopefully this clears up any confused minds.

Lyn

[TNT]

Glina, I am not attacking you (I do not even know you), I am attacking your methods. You come here playing "the guy who just made OTP unbreakable encryption possible on your PC" (and with a pay-for product, let's not forget) when the truth is far from it. OTP encryption is not something you can define yourself, it's a known (and impractical) form of encryption that can't be achieved via software only.

You throw at us a file claiming "you can't break it" to prove some point of some kind, but the truth is, it does not prove a thing. I don't even bother accepting challenges of this kind, because you could have used a hardware entropy source, or you could have gone on http://www.random.org or http://www.fourmilab.ch/hotbits/ (by the way, this is not 'secure', at least not in a real way, as the data is downloaded in clear text, and it would only be as secure as the SSL connection even if you could download it over that) and got the random data you needed to create the OTP key. How would we know? And do you honestly think that asking a couple of people in a public forum (and who have nothing to gain whatsoever in spending time trying to decrypt a file) automatically means you built unbreakable encryption? And that people should honestly encrypt all their bank data and social security numbers in a high-risk environment, without fearing that for months or years expert criminals who make a living on stealing such things would ever be able to decrypt it?

More, if you were serious about your program, you would have described at least the methods of creating the entropy pool for your program (for I hope you don't mean for people to use the rnd function) and you would have NOT claimed that it was OTP unbreakable encryption anyway. That's honesty I'm talking about, buddy.

[Andrew Glina]

Dear TNT

You are attacking me personally as you are saying that I am decieving my customers. In your last post you implied that I was dishonest. You do not need to know someone to insult them. I only gave the challenge as you challenged the security of XorIt. I did not start this. I only came to this site as you dismissed my program as "Snake Oil". If someone comes out with a claim that something can be done in seconds, then they should have something to back it up. I gave you and Inspector Clouseau a chance by making a easy challenge. You constantly claim to be an expert, yet you have offered no proof either.

I already have explained over and over again how I generate the entopy pool. I don't. It is as simple as that. (Due to this interesting debate I am considering writing one though.) OTP works best if each person uses their own method for generating the OTP. That is a fact. Providing the OTP is unpredictable then it is unbreakable. That is a fact. OTP is achievable via software only. I have not seen this proved otherwise. A system is seen as secure until it can be defeated.

(Mentioning the fact that I charge for my software is absurd, even ignoring the fact that it only costs $7.50 USD. I used to be freeware and have a "donate" button on my site like most open source and other "free" programs. But in my opinion this is little better than begging. I do not charge for upgrades and I offer free support to even non-registered programs.)

I have been nothing but polite on this forum and I wish you would offer me the same courtesy. There are no need for insults.

[Andrew Glina]

Thanks to your warm welcome I have decided to stay. I love you guys.

[Jason_R0]

{QUOTE->
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.
<-QUOTE}

The encryption you use isn't really a true OTP, since the key isn't random....


{QUOTE-> I already have explained over and over again how I generate the entopy pool. I don't. It is as simple as that. (Due to this interesting debate I am considering writing one though.) OTP works best if each person uses their own method for generating the OTP. That is a fact. Providing the OTP is unpredictable then it is unbreakable. That is a fact. OTP is achievable via software only. I have not seen this proved otherwise. A system is seen as secure until it can be defeated. <-QUOTE}

I also noticed your software doesn't provide the ability to only use data "one time" , as the whole thing with "one time pads" is that you use the key data "one time". Funny that you name your program "XorIt" but then come in here and say it is using "one time pad" encryption....

If you used a real symmetric cipher like RijnDael, even with a weak password someone like myself wouldn't be able to come along and view a part of the plaintext easily. Which is possible with your software if the user mistakenly uses a file to XOR their data which is weak. Sure someone could run a "brute force password" crack and discover the weak password, but if the file format was custom, it would take more work to get a password bruteforce to start happening, than it would be to open up a hex editor and simply take a look at the file.

Someone who doesn't know much about encryption can easily type in a 12 character password, and be relatively secure with a known secure algorithm. Someone who doesn't know much about encryption, who uses your program, can easily select the wrong file and be under a false belief that their data is relatively secure, when it isn't.

On your webpage (http://www.sinnercomputing.com/XorIt.htm) I noticed you are using the pagefile to encrypt an EXE. What if you were using the pagefile to encrypt a TEXT file. There are a lot of 0x00's in the pagefile, how much of the text file would be visible in a hex editor without any work? Even you, the author of XorIt, are showing people how to use the program incorrectly.

If the police raided your home and found your DVD of xor-keys, or simply selected every file on your hard-drive as a possible key file for encrypted files, how long would it take them to decrypt all your encrypted files? I think it would be quicker than the time it would take them to extract a long password from your head.

Tooting your own horn because some random people on a forum somewhere can't break your easy encryption doesn't make your program secure. You know there are severe weaknesses in your program, you have shown yourself being vulnerable to them, aswell as offering a weakly encrypted file for people to test here. It would take me about 15 minutes to put together the exact same program you are offering on your webpage, I just don't know why you are offering it for sale...

[Andrew Glina]

{QUOTE-> I noticed you are using the pagefile to encrypt an EXE. <-QUOTE}

Very true. That is a mistake I will try to rectify soon. I was in a hurry when I made that screen shot so I just used the first big file I found. Thanks for reminding me of this. I don't tend to give my screenshots a second glance. But why are you saying that the key isn't random? Since I don't even provide a key, how can you say it is not random?

I do not recall saying that XorIt is using OTP encryption, I said it can use OTP encryption. There is a quite large difference. A vacume cleaner can be used to fill up an air matress, but it is not its prime function. XorIt is a file XORer that can be used with any file you want, including One Time Pads. What else would XorIt need to do to support One-Time keys? Delete the file on the second time it was used? If so, how would it know this?

XorIt was a requested program. Someone wanted a program that could do Vernam style encryption that can be used with a Blum Blum Shub generator. That is why I wrote it. He asked me as the available ones were too slow. He did not like the avalible encryption options and others feel the same way.

I fail to see why I am being questioned on the pros and cons of OTP encryption. I came here to defend my program, not to "tout my horn". Instead one person decides to act like a cracker and try to find bugs in my registration code, and the rest see me as Mr OTP. I never claimed any of that. I just objected to my program being labled as "Snake Oil". It was TNT who first mentioned OTP. XorIt claims to use Vernam encyption which is where the cipher is the same size as the plain text. Not as secure as OTP, but close enough for a lot of cases.

But it does seem that I will lose this debate and there must be a never ending stream of Security Experts who hate the concept of OTP. I am not a securty expert, and I have never claimed to be. I suppose this is the price I pay for being a open minded developer.

[Devinco]

{QUOTE-> 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,
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? <-QUOTE}

Dallen,
Well there are really two threads going on in this one. One at the programmer level and one at the average user level (I am happily in the latter group). Personally, I just want the program to keep my stuff safe and be easy to use. It is great to learn some of the nitty gritty details of encryption because it will help you make a better choice on what to use.

Just to add to what StevieO said, Windows XP really is much more at home with 1 GB plus RAM, page file or not. From my experience, I would say 1 GB is the threshold where you could start to consider turning it off.
If you are not editing large photoshop pics or doing video editing, you should be able to turn it off at 1 GB without consequence.
I have been using 1.5 GB RAM with no page file for a long time without a problem, even with multitasking, lots of security programs, photo editing, etc. I have not tried video editing without a page file, but that would work best with 2 GB anyway. The worst problem would be a program crashing (simply end task) or unlikely, windows would freeze (reboot).
Try it, you can always switch it back if you doesn't work for you.
If in the unlikely event that you can't boot into windows normally because of some odd program you load at start up, you could reboot into safe mode and turn the page file back on.
It's low risk, but if you want to be extra careful, you could do a backup first.

[Andrew Glina]

Can I join your discussion Devinco? Mine seems to be going nowhere.

[Jason_R0]

Hi Andrew,

just some quotes from your webpage :-

{QUOTE-> Most file encryptions use methods that mathematically hash a password to a much larger number and rely on the time taken to reverse this process to prevent unauthorised decryption. <-QUOTE}

Not a bad start...

{QUOTE-> Providing the key length is 128 bits or greater this method works well for most purposes, but since these methods do have predictable patterns they can be cracked. CPUs are increasing in speed at a fast rate and these encryption methods can be beaten given luck and/or enough computers. <-QUOTE}

So now you're saying that every symmetric encryption can easily be cracked/broken? Hmm maybe you know something that the rest of the world doesn't, if so quite a few people would be interested in your findings. Rinjdael broken? TwoFish broken? Interesting, especially since if a 128-bit symmetric algorithm cannot be "broken" and only bruteforced, its theoritically impossible to recover the plaintext/key. Regardless of how many computers you put to the job.

So now after putting down everyone else's implementation, lets see what your program can offer us. :-

{QUOTE-> XorIt uses the XOR encryption method (also known as Vernam encryption) that can have keys the same size as the file to be encrypted.Thus, if you are encrypting a 5MB file, then you can have what is in effect a 40 Million bit key! This is virtually unbreakable by any computer, especially when you consider that the file must also be checked with each combination to see if it is decrypted. To put is another way, since XorIt gives no pass/fail results brute force methods are difficult to implement. In fact, if you use a good key file that is the same size or larger than the source and do not reuse the key file then it it impossible to decrypt the file, no matter how fast the computer is <-QUOTE}

Virtually unbreakable hey...

{QUOTE-> Furthermore, the key file can be anything - a program, a swap file, an image of your cat or even a music file. <-QUOTE}

You tell people to use insecure "key files" to protect their plaintext files, just after saying that its virtually unbreakable? How is that possible? Your claim of "virtually unbreakable" might be true if you told them they would need a close to 100% random key data, but you don't. You should also mention that you don't provide the option to generate something which might come close to resembling random.

Saying that your program can be used to do OTP is like me saying Windows can be used to do OTP, provided you have the software to do it. You can't do OTP with just your program.

[Andrew Glina]

If the key file is unpredictible then the plaintext cannot be decrypted. There is no need for the file to be random. It just needs to seem random to the hacker.

I am not putting down anyones methods, I am just stating facts. The problem with using XorIt as directed is that you need to be able to transfer and store keys securely. That is a big problem. I have never denied that. Rijndael and TwoFish have not been broken no, but I never said that. But it can be brute forced, unlike a non-predictable key. I am aware that they cannot be cracked easily now, but they might be in the future, expecially if a weakness is found. That is the problem with the common method of encryption. But you must know this youself. I am not a security expert.

While it is nice to see an Australian join in the argument, you have to admit that as someone selling conventional encryption software you are highly biased.

[Jason_R0]

{QUOTE-> If the key file is unpredictible then the plaintext cannot be decrypted. <-QUOTE}

Maybe you would like to explain what methods you would use to make a key file unpredictable, and what exactly makes a file unpredictable? Going by your website are you implying
{QUOTE-> program, a swap file, an image of your cat or even a music file <-QUOTE}
are unpredictable?

[Andrew Glina]

Excluding the Swap file, yes. Aside from a few bytes here and there (especially the header) they are mostly unpredictable. Ever tried compressing a JPEG? (I would make a challenge but I played that game last time and it got me nowhere.)

Obviously this is not the ideal for maximum security, but it is an option. I do say "In fact, if you use a good key file that is the same size or larger than the source and do not reuse the key file then it it impossible to decrypt the file, no matter how fast the computer is." and I explain in the readme what makes a good key. (I have a better expanation in my new version of CryptIt. This discussion has given me a lot to think about.)

I better go. I am late making tea...

[Jason_R0]

{QUOTE-> Excluding the Swap file, yes. Aside from a few bytes here and there (especially the header) they are mostly unpredictable. Ever tried compressing a JPEG? (I would make a challenge but I played that game last time and it got me nowhere.)

Obviously this is not the ideal for maximum security, but it is an option. I do say "In fact, if you use a good key file that is the same size or larger than the source and do not reuse the key file then it it impossible to decrypt the file, no matter how fast the computer is." and I explain in the readme what makes a good key. (I have a better expanation in my new version of CryptIt. This discussion has given me a lot to think about.)

I better go. I am late making tea... <-QUOTE}

Well those few bytes here and there could be enough to give away the general message of the plaintext. Glad to hear you have come out of this for the better. :)

[Magnus Mischel]

{QUOTE-> If the key file is unpredictible then the plaintext cannot be decrypted. There is no need for the file to be random. It just needs to seem random to the hacker. <-QUOTE}

We have already shown you that if you encrypt a text file with a key file that contains 0x00 bytes then every location where the keyfile contains 0x00 will result in visible plaintext in the output file. Yet you insist that "there is no need for the file to be random. It just needs to seem random to the hacker" and give recommendations on your web site to use JPEG files, the Windows swap file or even a music file, all of which can contain long stretches of 0x00 bytes.

You obviously do not care the least about representing your program factually - you have progressed to just wanting to win this debate no matter how wrong you are. The fact of the matter is that without a way to generate true random numbers your program is useless and provides the end-user with a false sense of security. And yet you have the audacity to claim on your web site that established algorithms such as Rijndael are less secure than your flawed product.

Perhaps you should consider that there is a reason why everyone in this thread is telling you that you are wrong. I suspect your reply will merrily ignore this and just state the reasons why you think you are right with blissful ignorance...

[Andrew Glina]

Not at all. I am well aware of the problem of null bytes. I have explained this to many users and if you read the readme you will see that I say that it must have "...as few nulls as possible...". My new version (that I started on before this debate) has a feature to analyse files and will reccomend not using any file that is like that. It also will detect repetition and lack of balance. XorIt is a bad example actually. XorIt was written as a favour to a friend of mine who did not like all of the buttons that CryptIt has.

I have mentioned before anyway, there are other options such as Blum Blum Shub generators. But no one has even tried to counter that point. I will solve this whole delemma soon (in a month or so) anyway as I intend to write a OTP file generator. But don't worry, no more challenges. Feel free to keep an eye on the site however and label it as "Snake Oil" too. I am sure you will.

But how can I win this debate? Everyone else thinks that my programs and even OTP encryption are a sham. No one here will be convinced. We are all wasting our time. What I am trying to achieve is a balanced debate for anyone who does a search for XorIt and finds this sillyness. If I do not stand up for my software who will?

[StevieO]

I wonder how many other vendors would be prepared to come out of the woodwork, and openly discuss issues like this about their products.

I don't know much about all the coding etc, and what's actually correct or not, but i think it's good to see Andrew Glina posting in a non offensive way !


Never heard of these, but they seem on topic !

. . .

Introduction

The purpose of this paper is to introduce the new random number generators IA, IBAA, and ISAAC. IA (Indirection, Addition) is biased but it appears to be secure. It is immune to Gaussian elimination. IBAA (Indirection, Barrelshift, Accumulate and Add) eliminates the bias in IA without damaging security. ISAAC (Indirection, Shift, Accumulate, Add, and Count) is faster than IBAA, guarantees no bad seeds or short cycles, and makes orderly states disorderly faster. The generator for RC4 will be used for comparison throughout this paper.

. . .

A sequence of new pseudorandom number generators were developed: IA, IBAA, and ISAAC. Their speed and lack of bias should make them useful for simulations and cryptography. The reader is invited to prove their security (or lack thereof).

http://www.burtleburtle.net/bob/rand/isaac.html


PRIZE, started 1998/february/6: $1000 (USA dollars) to whoever sends me the solution to the above challenge (plus publicly revealing a repeatable method for determining it) first. I'll also offer $100 for the first bias that can be detected with RANDSIZL=8 (in sequences of length less than 264 values) (starting with almost all seeds) (exceeding an absolute value of 4 times the standard deviation) (the test must start not knowing the seed).

ISAAC hasn't been broken since it was published 9 years ago. No bias has been detected either. I am offering these prizes in an attempt to get others to try to break it and assure those techniques are published. Apologies for having such a small prize. If you find successful attacks or biases in smaller versions of ISAAC, I'll include them in isaac.html, even though there are no prizes for them. I'm interested in attacks and biases against RC4 as well. Other fast stream ciphers are SEAL and WAKE.

2001: Marina Pudovkina published an attack on ISAAC with estimated running time of 4.67x101240.

http://www.burtleburtle.net/bob/rand/isaacafa.html


chi-square analysis of images.

So, once again, don't believe people who claim that steganography is undetectable. Especially their own secret algorithm that they will try to sell you, claiming that it has "military grade" and is of "world-class strength", "unbreakable even by the NSA". Ask them for a proof. Even better, crack their algorithm yourself.

http://www.guillermito2.net/stegano/index.html


StevieO

[_Lyn_]

Hi Jason_R0,

You asked: "how long would it take them to decrypt all your encrypted files?"

-However long it takes to decrypt the multi-character password of the 7z files inside! If the 7z¼¯ headers are not exposed i would imagine someone(s) would stay busy with that DVD for quite some time. If they see those they'll probably taser me, or whisk me away me to gitmo.

Thats a big reason why i like Andrews program. You can't just beat the password out of someone.

[Paranoid2000]

{QUOTE-> Thats a big reason why i like Andrews program. You can't just beat the password out of someone. <-QUOTE}If that's your main criteria, then you should be looking at deniable encryption algorithms like RubberHose (http://www.mirrors.wiretapped.net/security/cryptography/filesystems/rubberhose/rubberhose-README.txt) not Xor...

[TNT]

{QUOTE-> Ever tried compressing a JPEG? (I would make a challenge but I played that game last time and it got me nowhere.) <-QUOTE}Yes, and you can compress JPEGs with all the most common compression algorithms (rar, zip, bzip2, gzip), although usually not by much. But slow compression algorithms like paqar (http://www.cs.fit.edu/~mmahoney/compression/) are usually able to compress them quite a bit. You don't believe me?

Here, the first big jpeg I found on the Google cache: http://ice.unimi.it/alp/foto/CdA-04/weissmies/original/panorama%20dal%20rifugio.jpg

Size before compression: 824356 bytes
Size after compression (with paq6v2 -5): 796916 bytes

If you don't believe it, go ahead and test it yourself.

But that's beyond the point anyway. Regular image JPEGs are never, ever even close to resembling random. Using a randomness testing program, even a basic one like ENT, http://www.fourmilab.ch/random/, will show it right away. They utterly, completely fail the Chi-square Test every single time; and if you were to test the output of a true random source (i.e. radioactive decay) you would see it just doesn't fail the Chi-square Test.

[Devinco]

{QUOTE-> If that's your main criteria, then you should be looking at deniable encryption algorithms like RubberHose (http://www.mirrors.wiretapped.net/security/cryptography/filesystems/rubberhose/rubberhose-README.txt) not Xor... <-QUOTE}
Hi Paranoid2000!

Rubberhose looks very interesting.
How would you compare the plausible deniability feature of RubberHose to TrueCrypt's hidden volume feature?
The site http://www.rubberhose.org/ wasn't working for me. Is it live?

Also, I was wondering if there is some encryption software (within the reach of end users) that would allow for an incrementing rule set where the passphrase would change based on time, date, or better, a user specified pattern. A time or date based rule set could be attacked by constantly resetting the date/time. And the ruleset itself could be attacked, so that would need to be protected somehow (maybe encrypted also). But a custom user defined passphrase that increments or changes on each access might be possible. Some banks use those token cards (two part passwords), is there something similar that would be available to regular people?

Thanks

[TNT]

{QUOTE-> Thats a big reason why i like Andrews program. You can't just beat the password out of someone. <-QUOTE}

Oh yeah (that is, even if it worked as advertised):

Scenario 1:

Criminal: "Tell me your password or I will torture you".
You: "No!"
Criminal tortures you and you tell him the password.


Scenario 2:
Criminal: "Criminal: "Tell me where you hid the key or I will torture you".
You: "No!"
Criminal tortures you and you tell him where you put the key.


Scenario 3:
Terrorist: "Tell me your password or I will kill you".
You: "No!"
Terrorist kills you.


Scenario 4:
Terrorist: "Tell me where you hid the key or I will kill you".
You: "No!"
Terrorist kills you.


A big difference, indeed.

[_Lyn_]

Thanks Paranoid2000.

@Devinco: http://en.wikipedia.org/wiki/MaruTukku

Still looking for MD5 of the original project files.. The location of the server is encouraging but with all the "war on terra" b.s. its not tinfoil to question their integrity.

[_Lyn_]

There you go again! Not 1 of those scenarios apply to me. Securing the key is something that each person must work out on their own, and i have done so.
And no, i will not tell you how i do it so don't ask. If you want, start another discussion and we can all hash out the best storage solution. k?

Have you decrypted XORFileA.X yet?

tick-tock, lol.

[StevieO]

Hi Devinco,

I found references to Very interesting looking RubberHose yesterday, but the website doesn't exist anymore as you discovered. I tried to locate more info and a DL via Google etc with no luck !

It seems that it was for UNIX only and never ported over to Windows, as far as i could determine anyway.

I think it's VERY strange that on all the numerous links i went to, not one of has a DL of it. I found a Parent directory for it with DL links, but they also failed ?

I wonder if the men in black have had something to do with eliminating it from the web, as it sounded like it was pretty strong stuff !

I did manage to find this and DL it, again No Wiki for it that's gone too, just a 404 !

. . .

PhoneBook is a filesystem for Linux computers.

PhoneBook is strongly inspired by the RubberHose project. However, in contrast to RubberHose, PhoneBook aims to be easy to install and use, targetted at intermediate Linux users and above.

PhoneBook (Deniable File System Encryption) alpha Build 011 06-Jan-2004

For technical info, please visit the User Manual | PhoneBook Wiki Pages | Block Diagram

http://www.freenet.org.nz/python/phonebook

. . .


StevieO

[Paranoid2000]

{QUOTE-> How would you compare the plausible deniability feature of RubberHose to TrueCrypt's hidden volume feature?
The site http://www.rubberhose.org/ wasn't working for me. Is it live? <-QUOTE}TrueCrypt's hidden volume looks like a similar feature but appears more restricted in that the documentation does not mention whether multiple hidden volumes can be used.{QUOTE-> Also, I was wondering if there is some encryption software (within the reach of end users) that would allow for an incrementing rule set where the passphrase would change based on time, date, or better, a user specified pattern. <-QUOTE}Current algorithms would require that data be re-encrypted if the key changes so it's unlikely that such a feature would be feasible.{QUOTE-> Some banks use those token cards (two part passwords), is there something similar that would be available to regular people? <-QUOTE}Token cards (like the CryptoCard (http://www.cmf.nrl.navy.mil/CCS/people/kenh/cryptocard-wp.html)) are used for authentication rather than encryption (though they do use encryption as part of the process). In this case, the "challenge code" is what is constantly changing, rather than the key to megabytes or gigabytes of encrypted data.

With regard to Rubberhose, it would appear that other projects have taken up where it left off so thanks to _Lyn_ and StevieO for providing more up-to-date links.

Getting back to the initial topic of this thread, what it originally concerned was an attempt at implementing a One-Time Pad. While a proper implementation has been mathematically proven to be unbreakable (see Wikipedia: One-time pad (http://en.wikipedia.org/wiki/One-time_pad)) it has enough practical problems to make it unsuitable for most people. If you wish to encrypt 100MB of data, you have to have a 100MB key. How do you secure this? Storing it separately (e.g. on a USB memory stick) is little protection since it has to be present when you access your data. Encrypting it using a symmetric algorithm is better, but you are then depending on that algorithm's security, so why not just use it to encrypt the original data?

The one circumstance I could see OTP "adding value" for securing computer data is that of accessing data remotely via the Internet. In this case, anyone accessing the data would need to have a key (USB stick with the OTP) as well as know the password (key to decrypt the OTP).

For securing personal data on your own PC, the standard advice is to use open-source encryption software which is then subject to outside code review (sorry Jason), implementing tried and tested algorithms. So far, nothing posted here suggests any need to change that advice.

[Andrew Glina]

{QUOTE-> The one circumstance I could see OTP "adding value" for securing computer data is that of accessing data remotely via the Internet. In this case, anyone accessing the data would need to have a key (USB stick with the OTP) as well as know the password (key to decrypt the OTP). <-QUOTE}
Interestingly, I intend to do something similar to that in a future version of CryptIt. What I want to do is to as well as use a large key file, I want to have several patterns (such as use only certain bytes in a block of a certain size, for example byte 1, 3, 9 and 15 out of a 32 byte block) that can be used to further reduce unwanted decryption.

I have always seen the need to store the key on a removable drive as a feature. I even have a special mode for it in CryptIt. Physical keys have worked for the same way for years afterall.

[TNT]

{QUOTE-> Have you decrypted XORFileA.X yet?

tick-tock, lol. <-QUOTE}Ok, you're obviously a troll. So I won't bother with you ever again. Bye bye, pathetic loser... (and a busted one at that).

[_Lyn_]

Due to Paranoid2000 comments Andrew just announced an upcoming additional feature, then you follow up with that? If you were familiar with Andrews program you would know what he means to use "certain bytes in a block" It will be a great addition to that particular feature! TNT, please stop calling me out and i wont have to continue posting in reply, which further mucks up the thread..

Thanks!

[justacomment]

{QUOTE-> Hi Paranoid2000!

Also, I was wondering if there is some encryption software (within the reach of end users) that would allow for an incrementing rule set where the passphrase would change based on time, date, or better, a user specified pattern. A time or date based rule set could be attacked by constantly resetting the date/time. And the ruleset itself could be attacked, so that would need to be protected somehow (maybe encrypted also).

Thanks <-QUOTE}

Sounds like something out of a Dan Brown book , Digital Fortress. LOL

[Devinco]

{QUOTE-> @Devinco: http://en.wikipedia.org/wiki/MaruTukku
Still looking for MD5 of the original project files.. The location of the server is encouraging but with all the "war on terra" b.s. its not tinfoil to question their integrity. <-QUOTE}
_Lyn_,
Thanks for the link.

[Devinco]

{QUOTE-> Hi Devinco,

I found references to Very interesting looking RubberHose yesterday, but the website doesn't exist anymore as you discovered. I tried to locate more info and a DL via Google etc with no luck !

It seems that it was for UNIX only and never ported over to Windows, as far as i could determine anyway.

I think it's VERY strange that on all the numerous links i went to, not one of has a DL of it. I found a Parent directory for it with DL links, but they also failed ?

I wonder if the men in black have had something to do with eliminating it from the web, as it sounded like it was pretty strong stuff !

I did manage to find this and DL it, again No Wiki for it that's gone too, just a 404 !

. . .

PhoneBook is a filesystem for Linux computers.

PhoneBook is strongly inspired by the RubberHose project. However, in contrast to RubberHose, PhoneBook aims to be easy to install and use, targetted at intermediate Linux users and above.

PhoneBook (Deniable File System Encryption) alpha Build 011 06-Jan-2004

For technical info, please visit the User Manual | PhoneBook Wiki Pages | Block Diagram

http://www.freenet.org.nz/python/phonebook

. . .

StevieO <-QUOTE}
Hi StevieO,

On the page _Lyn_ supplied the link for, there is a link to the download page:
wiretapped rubberhose download (http://www.mirrors.wiretapped.net/security/cryptography/filesystems/rubberhose/ )
It is in a tar.gzip compressed format, so it appears to be a *nix program.
Whether it it contains any extra value added content (as _Lyn_ hinted), I don't know.
I'll be using Windows for a while yet, so that is not an option for me.
Thanks.

[StevieO]

Hi Devinco,

Yes that's one of the sites i visited yesterday, the Parent directory. Even though the two files are listed as available links for DL, they don't seem to work for me.

This is what i get

http://img167.imageshack.us/img167/7686/rhnodl16pf.png (http://imageshack.us)

I only wanted to DL them to keep as they appeared to be very rare, and i or others might be able make use of them one day. That's the reason why i DL PhoneBook.

I've done this often with things, as sometimes they do disappear !!!


StevieO

[Devinco]

StevieO,

No problem downloading them here with FF.

[Devinco]

{QUOTE-> TrueCrypt's hidden volume looks like a similar feature but appears more restricted in that the documentation does not mention whether multiple hidden volumes can be used. <-QUOTE}
Paranoid2000,

I tested this with TrueCrypt, and you are right. Only one hidden volume can be made per volume. In the attempt to create a second hidden volume, the first hidden volume was overwritten in the format process.
Of course you can nest regular volumes without limit, so you could put a second volume (containing a hidden volume) within another volume. Not quite the same thing, but it's a start (and it is in windows).

{QUOTE->
Current algorithms would require that data be re-encrypted if the key changes so it's unlikely that such a feature would be feasible.Token cards (like the CryptoCard (http://www.cmf.nrl.navy.mil/CCS/people/kenh/cryptocard-wp.html)) are used for authentication rather than encryption (though they do use encryption as part of the process). In this case, the "challenge code" is what is constantly changing, rather than the key to megabytes or gigabytes of encrypted data.

For securing personal data on your own PC, the standard advice is to use open-source encryption software which is then subject to outside code review (sorry Jason), implementing tried and tested algorithms. So far, nothing posted here suggests any need to change that advice. <-QUOTE}
Thank you for the info and the wise advice.

[StevieO]

Devinco,

Wonder why that is ?

Is it possible for you to Upload them both to one of these sites for our benefit, if you wouldn't mind.

http://www.wilderssecurity.com/showthread.php?t=99021

Thanks


StevieO

[Devinco]

{QUOTE-> Sounds like something out of a Dan Brown book , Digital Fortress. LOL <-QUOTE}
LOL,
Tell me about it. In the not too distant past, I thought all this encryption stuff was just for crooks and spies, not ordinary people. But criminals are actively targetting people regardless of their security knowledge. We need to defend ourselves from these low-lifes because governments are not going to do it for us.

Never read the book, but it sounds like it would be a fun fantasy read.
Do you recommend it?

[Devinco]

{QUOTE-> Devinco,

Wonder why that is ?

Is it possible for you to Upload them both to one of these sites for our benefit, if you wouldn't mind.

http://www.wilderssecurity.com/showthread.php?t=99021

Thanks

StevieO <-QUOTE}
I am not knowledgeable in the legal area in regards to encryption software. In the US, it is considered a munition and has severe export restrictions. It may be possible that they are blocking your ip address if you are outside the US (or even proxied). Uploading encryption software may be considered the same thing as distributing it and may be illegal here. Sorry, but I'd rather play it safe.

[justacomment]

{QUOTE-> LOL,
Tell me about it. In the not too distant past, I thought all this encryption stuff was just for crooks and spies, not ordinary people. But criminals are actively targetting people regardless of their security knowledge. We need to defend ourselves from these low-lifes because governments are not going to do it for us.

Never read the book, but it sounds like it would be a fun fantasy read.
Do you recommend it? <-QUOTE}

Dan Brown's digital fortress? Well it's a fun read, but there are many glaring errors when it comes to technical matters, so I wouldn't recommend learning the basics of "encryption stuff" from it.

Some of it struck me as wildly impossible or wrong, but what do I know?

What you mentioned sounds a lot like one of the fantasy ideas in the book.
So called "rotating cleartext" algothrim with a time invariant function. The idea is to make it immune even to bruteforce. :)

[Devinco]

Thanks JustAComment,

I've got a lot to learn about encryption but thankfully there are experts and many others here at Wilder's willing to help increase our encryption knowledge level. Threads like this help a great deal.

Not that it is related to this thread, but for those interested in learning more about encryption, here are some books (http://www.diamondcs.com.au/index.php?page=books&cat=crypto) that may be of interest.

[Devinco]

So has anyone here used both PGP Home Desktop 9 (the PGP Disk component) and TrueCrypt 3.1a?
Not counting the Open Source/Closed Source issue, which is better?
Which is easier to use? (creating mountable volumes, working with them, etc.)
Can PGP Home Desktop 9 make hidden volumes?

[Devinco]

justacomment,

What do you consider to be the best encryption software on the market?

[ronjor]

PGP is pretty good. :) http://www.philzimmermann.com/EN/findpgp/index.html

[Devinco]

Thanks Ronjor,

That's a great link.
It answers a lot of questions like where to get the free / trial version of PGP, etc.
I couldn't find anywhere if they have an upgrade from version 8.02.
Do you think they have an upgrade policy or do you need to buy the new version again?

[ronjor]

Found this link on the PGP site. http://www.pgp.com/products/upgrade/upgrade_faq.html#upgrade_process1

[Devinco]

Thanks Ronjor. :)

[JacksonDK3]

Hello,

Has anybody here used DriveCrypt and /or DriveCrypt Plus Pack?
I saw that DCPP can even encrypt the OS

If you are intereste you might want to take a look ;) .

Link removed: Use Google please : Pilli

[Inspector Clouseau]

http://www.wilderssecurity.com/showpost.php?p=568379&postcount=4

[Inspector Clouseau]

To come back to the original topic - here you can read a "review" from Mr. Schneier about XorIt:

http://www.schneier.com/blog/archives/2005/09/the_doghouse_xo.html

My comments to this: I didn't expect anything else ;D

[Andrew Glina]

Well, as I say, his opinion on OTP is well known. If you were surprised that he thinks OTP is snake oil then you would have to live on another planet. Thanks for posting this link.

(Incidently, my program was not the original topic.)

[Paranoid2000]

{QUOTE-> If you were surprised that he thinks OTP is snake oil then you would have to live on another planet. <-QUOTE}He doesn't think OTP is snake oil, merely the (faulty) attempts of many vendors to mimic it resulting in an insecure product.{QUOTE-> (Incidently, my program was not the original topic.) <-QUOTE}Well, it is now... :)

[Andrew Glina]

Yes, you are right. I worded that wrong. I should have said "If you were surprised that he thinks a OTP program is snake oil then you would have to live on another planet." Here is a quote from his Snake Oil essay;


"....One-time pads don't make sense for mass-market encryption products. They may work in pencil-and-paper spy scenarios, they may work on the U.S.-Russia teletype hotline, but they don't work for you....."


He is entitled to his opinion.

[Mmike]

{QUOTE-> Yes, you are right. I worded that wrong. I should have said "If you were surprised that he thinks a OTP program is snake oil then you would have to live on another planet." Here is a quote from his Snake Oil essay;


"....One-time pads don't make sense for mass-market encryption products. They may work in pencil-and-paper spy scenarios, they may work on the U.S.-Russia teletype hotline, but they don't work for you....."


He is entitled to his opinion. <-QUOTE}

I realy don't understand how can't you see why he is right? I mean, not just because he is The Bruce AllMighty, but just using pure logic?

[Andrew Glina]

What "Pure Logic" are you referring to "Mmike"?

That the files are too big? Not true.

That it is hard to transfer the keys? True, but that is not a reason to dismiss the technique. Many people use this method (not just users of my software either) for regular EMails with someone that they see at least every six months.

That is is hard to generate the keys? Not true. If you are using it to encrypt something huge then it is harder, but there are many ways to generate unpredictable files of around 1 MB. One that I have not mentioned is you open several files and cut and paste small sections (only once from each place I might note) from them at random and make one file. This file is 100% unpredictable as a whole, and still largely unpredictable in parts, while still not completely random. If you then test this file (using CryptIt) to ensure that there are no repeated nulls then it is secure for most purposes. Other options include using sections of a BBS generator output, perhaps even doing the same thing.


While I have not seen "Bruce AllMighty" I think I know where you are coming from. I think you are saying that because he is a respected member of the security community then I should see his opinion as fact. Well, to put it bluntly, I don't. I question everything, and I think you should too.

But I am not trying to convince anyone of anything. I am just trying to give a balanced debate so that anyone reading this can come to their own opinion. I even plan to link to this thread and Mr. Schneier insults from my site. If you think my software (or even OTP) is flawed then that is your right. But I find it very offensive to be accused of being a con man. and that is what people are saying when they label my software as "Snake Oil". As Mr. Schneier himself says;

'The term we use for bad cryptography products is "snake oil," which was the turn-of-the-century American term for quack medicine. It brings to mind traveling medicine shows, and hawkers selling their special magic elixir that would cure any ailment you could imagine.'

I have never claimed that my software is the be-all-and-end-all of security. I just claim that it has it uses and that it does work. Feel free to use it or not. It is a choice.

[random lurker]

{QUOTE-> I have never claimed that my software is the be-all-and-end-all of security. I just claim that it has it uses and that it does work. Feel free to use it or not. It is a choice. <-QUOTE}

Using phrases like "completely unbreakable" on your website doesn't really give that impression, now does it?

If you don't want to be seen as a con man, you should say something like:

{QUOTE-> CryptIt is a utility which combines two files in such a way that you can only recover one file if you have the other available. It could possibly be used as a component in a computer security solution, but it does not solve any of the hard problems involved.

If you believe you can generate large random keys on your own, and keep them secure (when you can't keep large files secure already, or why would you need this?), then you might find a use for this product... but if you believe this, you're either skilled enough not to need this product, or too ignorant to use it effectively. Therefore, don't buy CryptIt. <-QUOTE}

[Andrew Glina]

Thanks for the tip random lurker, but I think I will leave it the way it is. Your blurb seems a bit negative.

Besides, I do much the same now already. I have a link at the bottom of the XorIt and CryptIt page labled "Why you should consider using another program...". This then links to my FAQ which explains that Bruce Schneier thinks my program is "Snake Oil" with a link to his blog entry.

[random lurker]

Well, the link's a bit subtle, and the "#Snake" part doesn't work, and I still feel that your blurb makes a bit too much of the program's capabilities... but as you can probably tell, I'm no advertiser ;-).

Still, kudos for doing what you have -- and for bonus points, fix the anchors on your FAQ page :-).

[Andrew Glina]

Actually all my links are like that. When I did the last site redesign two years ago I thought it would be "cool" to have grey links with a black roll over. Time for a rethink?

I do agree that the description of the program does boast a bit about what I think is good about the method... but isn't that the point? I do want people to be intrigued and try the program. But I do say that "...It is argued by some though that this will never happen due to the laws of physics!..." It is not like other companies say in their promo blurb "some feel that this method is risky as a new algorithmic weakness could be discovered tomorrow". I give a long description in the ReadMe about the pros and cons of the method so I feel that I am providing my users with the knowledge (and several links) to decide themselves.

Thanks for pointing out the FAQ link error (I think I have fixed it) and for the kudos.

[heyUthere]

I do not know if you guys know about TOR http://tor.eff.org/overview.html
Using Tor protects you against a common form of Internet surveillance known as "traffic analysis." Traffic analysis can be used to infer who is talking to whom over a public network. Knowing the source and destination of your Internet traffic allows others to track your behavior and interests. It can even threaten your job and physical safety by revealing who and where you are. You can inadvertently reveal your national origin and professional affiliation to anyone observing the network, even if the connection is encrypted.

check it out!

[Paranoid2000]

Tor has been discussed in many other threads here - it does cover a different area though, providing online anonymity (using both multiple levels of encryption plus routing traffic via proxies) rather than secure storage of private data on disk. It is therefore not really applicable to this thread.

It is also worth noting that while Tor can make traffic analysis harder, its main benefit is encrypting your connection in the first place. Without this, your ISP can easily view all your online activities (and many are now required to log them under increasingly draconian data retention rules).

[Deven]

{QUOTE-> Hi Devinco,

I found references to Very interesting looking RubberHose yesterday, but the website doesn't exist anymore as you discovered. I tried to locate more info and a DL via Google etc with no luck !

It seems that it was for UNIX only and never ported over to Windows, as far as i could determine anyway.

I think it's VERY strange that on all the numerous links i went to, not one of has a DL of it. I found a Parent directory for it with DL links, but they also failed ?

I wonder if the men in black have had something to do with eliminating it from the web, as it sounded like it was pretty strong stuff ! <-QUOTE}I suspect the author got distracted by other things and forgot to renew the domain name.

Take a look at this URL for a working copy of the old "rubberhose.org" site, I believe it is the author's site, just under another domain name, but it may have actually been the same server:

http://iq.org/~proff/rubberhose.org/

[StevieO]

Hi Deven,

Thanks for the info and link, which does work for me !

Have you actually tried it or know anyone that has, and if so how what do You/They think of it ?


StevieO

[StevieO]

I found this on the RubberHose link that Deven gave me.

. . .

Security

Rubberhose places extreme demands on random number generators and
ciphers. It is not enough for a generated stream to be merely
irreversible. There must be no computationally feasible way to
detect ANY (statistically significant) correlation between values
in the stream.

etc

http://iq.org/~proff/rubberhose.org/current/src/SECURITY

. . .

Lots of other very useful and interesting info over there too. Very indepth and mostly over my head, but i learnt things anyway !


StevieO

[Deven]

{QUOTE-> Thanks for the info and link, which does work for me ! <-QUOTE}Glad it worked for you. While much of the site is on archive.org, that doesn't have the actual download, while this site does. Like I said, I suspect this was either a mirror or maybe the actual original site via a different URL...{QUOTE-> Have you actually tried it or know anyone that has, and if so how what do You/They think of it ? <-QUOTE}No, I haven't tried it yet, but I thought it looked very interesting, especially that you can have multiple layers of hidden data. I thought it would be interesting to use it on a CD-ROM, since you wouldn't have to worry about clobbering the hidden data if you're using read-only media...

Deven

[Rilla927]

{QUOTE-> Hello,

Has anybody here used DriveCrypt and /or DriveCrypt Plus Pack?
I saw that DCPP can even encrypt the OS

If you are intereste you might want to take a look ;) .

Link removed: Use Google please : Pilli <-QUOTE}

Hi Jackson,

I had the same question about DriveCrypt products. Why did they remove your link? I thought you were allowed to post links.

I was going to post a link with my question to see what everybody thought. This really puzzles me!

[Alex5]

Over the years there were many stupid and/or dishonest "security experts" who claimed proven un-breakability of their products as One Time Pads while in fact providing products which substitute random key of One Time Pad with stream cipher. While such products are NOT One Time Pads and can claim nothing of it's proven un-breakability they did in many cases provide considerable security as stream ciphers.

Now, this one is truly in a league of his own. He didn't substitute random key for cryptographically secure pseudo random number generator, or no. He advised people to use any other files as keys. Any MP3 or JPEG lying around will do, as long as attacker doesn't know which one was used.

And it doesn't look like he's being dishonest. It looks like he actually knows absolutely nothing about cryptography.

[IamScared]

A little observation. Twofish is broken. The best attack now is around O(2^52), against the theoretical O(2^256) brute force attack. There is a paper by Moriai and Yin, two japanese researchers called "Cryptoanalisys of TwoFish" that presents the technique.

With respect to OTP, being myself a graduate student in cryptographic research.. OTPs are theoretical unbreakable, but their realization is extremely hard, because a lot of details have to be considered. Common users don't have any means to accomplish them in a real world scenario.

Another point is that the algorithm AND THE IMPLEMENTATION has to be public, so that the community can test and evaluate the security offered by a cryptography product. Beautiful "textbook algorithms" can be totally insecure by a broken implementation. Example: RSA in ECB mode.

So, why don't use well-known community-verified cryptographic primitives like AES or Blowfish? The keys can be protected furtherly by assymetric crypto algorithms, like RSA or ECC.

OTP is a inadequate solution to a problem that has fairly good solutions.

Good solutions are PGP, GPG (this is open-source and patent-free!) of the openssl command line utilities.

I like GPG and use it in a daily manner.

IamScared (or Diego Aranha, for the ones that like to attack arguments based on the anonymity of the poster :/)

[Arlen Cuss]

{QUOTE-> I suspect the author got distracted by other things and forgot to renew the domain name.

Take a look at this URL for a working copy of the old "rubberhose.org" site, I believe it is the author's site, just under another domain name, but it may have actually been the same server:

http://iq.org/~proff/rubberhose.org/ <-QUOTE}

Yes, that's the orirginal author's site (Julian Assange). I suppose he has better things to do than pay for domains!

[Phleg]

{QUOTE-> TRUE: The strength of encryption is only as secure the files themselves. <-QUOTE}

Or...not. The strength of encryption must be dependent upon the security of the key, and only the security of the key.

If I encrypt a file that I want to remain secured, I'll use an encryption algorithm which uses both diffusion and confusion. Confusion is analogous to the XOR encryption being done; values in the plaintext being replaced by other values in the ciphertext. Diffusion, on the other hand, distributes the statistical information of a file amongst the length of a block.

With both of these techniques together, even with the plaintext and ciphertext, one cannot discern the key.

On the other hand, with XOR, knowing the plaintext, or even statistical information about the plaintext, renders the 'security' nearly useless, unless you're using a key with a length exactly as long as the plaintext. However, even in this case, you can still be vulnerable. Firstly, you have to store the key securely, which poses exactly the same problems as storing the original file securely. If you keep the key with you to make sure it's secure, you might as well just be carrying the file itself. Even worse, if you use the same key more than once, any sort of statistical information in your data (usually file headers, but often predictable parts of the actual contents, too) can lead to the entire key being broken trivially.

{QUOTE-> Anyone with basic knowledge of XorIt can create files that are unbreakable. Here is example: I suggest it is best to encrypt both source + key, then combine the two. You will NOT be able to decrypt it in billions of years without the encrypted keys that only exists on DVD in my possession. <-QUOTE}

This quote only indicates how inexperienced you are with true cryptography. This extra rigamarole is pointless, and I'll show you why. Let P be your plaintext, C be the resultant ciphertext, K_1 be your key, and K_2 be the key you encrypt both with. A "^" is the XOR operation.

Your process starts off as the following:

C = (K_2 ^ P) ^ (K_2 ^ K_1)

Unfortunately for you, XOR is a commutative and associative operation. So really, all you're doing is this:

C = (K_2 ^ P) ^ (K_2 ^ K_1)
C = K_2 ^ P ^ K_2 ^ K_1
C = P ^ K_1 ^ K_2 ^ K_2
C = P ^ K_1 ^ (K_2 ^ K_2)

It's trivial to note that any string XOR'd against itself is nothing but zeroes, and any string XOR'd against zeroes is itself, so finally we have:

C = P ^ K_1 ^ (K_2 ^ K_2)
C = P ^ K_1 ^ (0)
C = P ^ K_1

Welcome to futility, population: you. You've achieved nothing extra, but now you need to carry around and protect two keys the size of the file (well, technically you don't, but if you'd known that you wouldn't have done this in the first place).

{QUOTE-> Do you now understand??? <-QUOTE}

I do. Apparently, you don't.

{QUOTE-> You do not know what you are talking about. I ask you one last time: why did you not decrypt XORFileA.X? <-QUOTE}

Because you don't come across random files in the wild that you need to decrypt. I will say it clearly: that file is probably very difficult to crack, for the explicit purpose that we didn't know (at the time) what type of file it was, any type of statistical information about it, and we have no information about the key generator he uses, and what its statistical properties are. And there's the trick: this type of security is great for protecting your pornography from your parents and kid sister, or for putting a random file on the web to "challenge" people to decrypt.

However, in the real world, cryptanalysis doesn't work in quite the same way. Typically, one analyzes many ciphertexts in tandem, all generated with either the same key or the same algorithm. With an pseudo-OTP generator like the one presented in XorIt, virtually any type of attack will exploit the fact that he's likely using some form of cryptographically insecure random number generator: i.e., (a + bx) mod c, which is the most common one, or some form of the Mersenne Twister. Even with a more secure algorithm (I believe Blum Blub Shub was mentioned), many attacks still remain.

There are very, very strict requirements on a One-Time Pad that must be in place for it to be cryptographically secure, and it is impossible for a deterministic computer to satisfy all of them. The others are excessively and pointlessly cumbersome.

1) a truly random number generator
2) secure key transmission and storage
3) secure key disposal
4) keys the length of each plaintext
5) a unique key for each plaintext

The first isn't as hard now, with Blum Blum Shub. However, there's no way to guarantee that it won't be possible in the near future to predict sequences from the algorithm, as it is a deterministic PRNG.

The second criteria virtually eliminates doing anything over a network. If you transmit your key to someone digitally, you have completely invalidated any security that might have been had with this type of algorithm. If you find some way to transmit the key securely, you might as well have transmitted the original date over that same channel.

The third criterion is extraordinarily difficult. Even after wiping your hard drive, data is quite often able to be retrieved. Deleting the file is simply not good enough. Overwriting it with alternating bit patterns is an improvement, but cumbersome, time-consuming, and still doesn't totally neutralize this means of attack. Like I said: great for your kid sister, bad for anything actually important.

The fourth is in some ways the worst of the bunch. If you want to encrypt an ISO, for instance, you need a key around 700MB in length. Not only does this take significant time to create, but you also need to now keep TWO large pieces of data secure rather than one. Since the key to be kept secure is exactly the same length of the data, it might as well be the data itself.

The fifth isn't difficult, but it requires that the person using the software know about this limitation. Also, it means that you double the storage space required for encrypting anything.

So I ask you: why go through all this effort? Why use a product that doesn't publish its source code for peer review (often, the algorithm a commercial vendor uses is perfectly secure when used correctly, but is badly implemented; c.f., static initialization vectors in the RC4 for WEP), go through the extra hassle of carrying large, cumbersome keys, give up the ability to transfer your files over a network or otherwise share the information with select others, and uses a technique that is only (potentially!) secure given the most extreme constraints, especially when alternatives exist?

And alternatives do exist. The recent AES algorithm (Rijndael) is fast, proven to be secure (the best cryptographers in the world have yet to break it, even with virtually their full attention on it for a decade), lets you re-use keys, has keys of a reasonable length (128-, 192-, or 256-bit), and is safe for transmission over a network or other insecure medium (the key can be encrypted with a public/private keypair and transmitted; this cannot be reasonably done for OTP, due to the massive size of the keys and the poor performance of all asymmetric algorithms).

Furthermore, if OTP was so easy to implement securely, why does the cryptographic community spend so much time, effort, and money on creating new and complicated algorithms, when OTP has existed for decades? Why spend nearly a decade reviewing dozens of symmetric algorithms for the recent AES standard, analyzing every aspect of their security, searching for weaknesses? If OTP was truly the holy grail of encryption, why go through any of this? Because, frankly, it's not possible or practical to implement securely in computer hardware or software.

[Phleg]

{QUOTE-> You will NOT be able to decrypt it in billions of years without the encrypted keys that only exists on DVD in my possession. <-QUOTE}

Oh, and therein lies the rub. If you're carrying around a DVD full of your various keys, and keep that secure, why not just keep the data on you in the first place? They're the same size, and they have the same security constraints. What do you gain?

[Andrew Glina]

To Phleg

Congratulations. You have just discovered what everyone else already knew; OTP encryption is generally not practical for securing large amounts of files. It is best used for message transfers. (It has been said several times even in this thread.)

I hope you enjoyed writing that essay.

[Random User]

I've read through a most pages of this thread and it amazes me what a flamewar this has become. Why do some people, as I see it, of true cryptology knowledge, join this discussion?

I've joined this discussion simply because of Bruce Schneier's newsletter which pointed me to this thread.

I've noticed a few things:
1. Andre Glina, the author of XorIt. Has a basic knowledge of cryptography.
2. Andrew Glina advertises his creation.
3. Most users in this thread look at his creation as snake oil.

Q. Why is it snake oil?
A. True world application is not feasable.

(Q/A as the discussion goes, not my opinion which comes next.)

True/False: In my opionion: True. It is snake oil.
Why: Andrew Glina says XorIt is a one-time-pad and no more.
For one-time-pads it is argued that one needs a TOTALLY random
source. I argue this is not true for ALL applications of a one-time-pad.
However it is also argue that for the INTENDED use of XorIt it it not
feasable. Not feasable is not contradicting Andrew Glina's statement.
Then we see to the "public": Does the "public" understand the basics of
cryptology? In my experience: No. So, if the "public" thinks of this as
the FINAL solution to hiding information, as Andrew Glina would like the
"public" to think, the "public" will be mislead.
Conclusion is that XorIt is "snake oil". (In my opinion).

Snake Oil is per definition: (My own words/opinion)
A remedy for an "illness", but does not provide, for ANY "buyer", the
intended result.

To this I have a few points to add:
1. One who want's to sell (or is it freeware, w/w.o source, if so disregard this point) this kind of security that is very misleading to the uninitiated doesn't know what he/she does, is really dumb or businessmart.
2. To create a encryption scheme is easy, but to create a SECURE encryption scheme is hard.
3. If you have a knowledge of cryptology, do not take persons like Andrew Glina very seriously. However, when such persons tries to induce the "public" with "false" information make your argument and then leave when the person doesn't seem to understand what all your points are. You do not want to teach him/her since it is not in your interrest. You only want to prove him wrong. Well: YOU CAN'T. All this discussion leads to is more monetary loss for your employer when you discuss this at work. :)

Andrew Glina "sells" a secure encryption program.
What does this mean?
Most opionion in this thread: secure=Secure.
In Andrew Glinas opinion: secure=Proven Secure.
The threads opinion on XorIt: Secure but not feasable.
Andrew Glinas opinion on XorIt: Proven Secure.
(Correct me if I'm wrong but this is what I've gathered from posts this far.)

Andrew Glina seems to misunderstand some very important keywords:
Proven Secure: Unbreakable in any way. Hacking, bruteforce, etc.
Not feasable: Cannot work at all or might work under some certain circumstances.
Secure: Something that is secure. Unless... (fill in your own explination).

Final Q/A:

#1.
A. Do I support Andrew Glinas statements?
Q. No, He contradicts himself at numerous times and seems to have very little
knowledge of cryptology.

#2.
Q. Do I think Andrew Glinas' XorIt is good?
A. No. It serves no purpose for the "average joe".

#3.
Q. Does XorIt work as intended?
A. Yes. It works as a one-time-pad and that was the intention.

#4.
Q. Would I promote XorIt?
A. No! See answer #2.

Last words:
If we look at MY definition of "snake oil" we see the words "for any buyer".
This translates to:
If a single buyer gets the result he/she thought he/she would get then this would not be "snake oil".
This is only semantics and not of importance of this discussion/thread.

/CKret

(Yes I've read Bruce Schneier's work and many others too and yes I've been working In this field for so and so long but who cares! Can't we all just get along!? :))

[Random User]

Corrections to the last post:

1.
However it is also argue that for the INTENDED use of XorIt it it not feasable.
should be:
However I also argue that for the INTENDED use of XorIt it it not feasable.

2.
Proven Secure: Unbreakable in any way. Hacking, bruteforce, etc.
should be:
NOTHING. Since Andrew Glina seems to understand this concept, but does a false application of the statement.
(Should have been: Proven Secure: Mathematically proven unbreakable.)

I blame it on Cut'n'Paste. ;)

Might be a few more mistakes but I'm on my last beer now so... be gentle. :)

[Andrew Glina]

Well you are entitled to your opinion "Random User", and since mine has been re-iterated several times to other anonymous users I will not debate you... much.

The main point that I feel needs to be clarified is that you are wrong about the purpose of XorIt. It was not written for OTP at all. (Vernam is not the same as OTP.) As I say "XorIt is designed to use conventional XOR encryption on keys that are the same size as the file to be encrypted." No mention of OTP there at all. I only mention OTP with emphasis some of its needs, with further clarification in the ReadMe. It was actually written for a friend of mine for usage with a Blum Blum Shub pseudorandom number generator. Thus, by your definition, it is not "Snake Oil"! Don't worry, I am only joking. See it as "Snake Oil", "Frog Oil" or whatever you want. I am not trying to persuade you, or anyone, of anything. I just wanted to make that point.

But please do not accuse me of being deceitful. I notified my users of the Bruce Schneier "review" and to the registered users I have offered refunds/exchanges. No one wanted one. If anything, this has made XorIt/CryptIt more popular!

(Incidentally, what do you mean by "Andrew Glina advertises his creation"? I have not spent one cent on advertising for any of my programs. Putting it on my website hardly qualifies if that is what you mean.)

[schneier]

"A little observation. Twofish is broken. The best attack now is around O(2^52), against the theoretical O(2^256) brute force attack. There is a paper by Moriai and Yin, two japanese researchers called "Cryptoanalisys of TwoFish" that presents the technique."

Twofish is not broken. The paper mentioned above does not contain a Twofish attack. It's a great piece of cryptanalysis, and there is the a distinguising attack against reduced-round Twofish that's the best out there. But there's no way to extend that attack to more rounds, and no way to convert the distinguishing attack into a key-recovery attack.

Unfortunately, the paper is not on-line. I am working to get it on line. I will also post more about this in my blog.

Bruce