The Doghouse: CryptIt

It's been far too long since I've had one of these.

CryptIt looks like just another one-time pad snake-oil product:

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. 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. 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. Furthermore, the key file can be anything - a program, a swap file, an image of your cat or even a music file.

Amazingly enough, some people still believe in this sort of nonsense. Before defending them, please read my essay on snake oil.

Posted on September 28, 2005 at 1:25 PM

Comments

ZwackSeptember 28, 2005 1:51 PM

Wow, this is a really nice looking front end...

So, it takes your input file, a "key file" which you get to pick and it does a byte by byte xor of the two.

As long as you have a secure mechanism for transferring the one time key files and you don't reuse them then this will be really secure...

Of course, if you have a secure mechanism for transferring the one time key file then why bother. There is also the possibility that it's using a Pseudo Random Number Generator to generate the one-time pad which might make it less than random.

It seems to me that this is probably a perfectly reasonable one time encryption program that is just completely worthless...

I don't want to have to distribute data files in a secure manner so that I can then send an encrypted file of the same size.

I don't think that this is snake oil... Just dumb.

Z.

SwapXorSeptember 28, 2005 1:55 PM

Clever guys: when you XOR a file with your swap file, it might indeed be impossible to decrypt... even by yourself. And they should also write a unix version that uses a /dev/random seeded by hardware entropy. ;-)

Ryan RussellSeptember 28, 2005 1:56 PM

You quote the description for "CryptIt", but link to "XorIt". Which one did you mean to pick on?

JosephSeptember 28, 2005 2:30 PM

Why couldn't you just use a good implementation of AES 256 or something to encrypt the key file, and send it along with the encrypted source file...

JustinSeptember 28, 2005 2:55 PM

@ Joseph

I hope you're being sarcastic. Let's say I have a 100 MB source file, and a 100 MB key file. So now I encrypt the 100 MB key file, and send both (200 MB).

But wait, I encrypted the key file with AES, which is exactly what CryptIt is "better" than. So tell me why I'd do that.

Davi OttenheimerSeptember 28, 2005 3:23 PM

From XorIt: "this is known as a 'one-time pad' and it is completely unbreakable, even to computers 1000 years from now"

Funny, and we were all so worried about predicting what computers could do 50 years from now.

TomSeptember 28, 2005 3:44 PM

It seems like the creator of CryptIt is confusing the theoretical framework surrounding one-time pad cryptography and the usage model he/she is advocating.

OTPs are only "unbreakable" if the pad is truely random. All bets are off after that.

CrpytIt seems to be advertising how easy it is to use... "Furthermore, the key file can be anything - a program, a swap file, an image of your cat or even a music file." Nothing random about that. Executables and images have known headers, and swap files have runs of 0's.

There appears to be a conflict here... The implied message is that CryptIt uses a perfect encryption scheme, and that scheme is still perfect even when non-random pads are used. False and very deceiving.

StephenSeptember 28, 2005 3:57 PM

I keep in touch with an old friend from college using one-time pads. We each have a copy of a DVD-R I constructed with several hundred thousand 100KB files of pseudorandom data. Each time we send a file we XOR it with the next unused 100KB key (or next series of unused keys for files over 100KB). We don't reuse keys, and when we need a new DVD-R, it's exchanged in person.

Don't knock the method, knock the implementation.

Fred PageSeptember 28, 2005 4:13 PM

Heh... my problem is more the price than the deceptive ad- 10$ for an XOR script?

@Tom - good comments.

@stephen - The reality is that the implementation is almost never adaquate; you're almost always better off using public/private key encryption. For example, in the implementation you propose, have you analyzed the puedo-random number generator to determine if there are patterns in the keys which give a basis for hacking it? If your alogrithm were known to an attacker (or derivable), would that eliminate your security?

In any case, even if your implementation is at least as secure as public/private key encryption, this isn't. It's also so trivial that it's not even a useful building block for someone who wants to create a useful one-time pad.

StephenSeptember 28, 2005 4:32 PM

@Fred

I'm using Blum Blum Shub (GMPBBS) to generate one large file, then partitioning that up into 100KB chunks.

RvnPhnxSeptember 28, 2005 4:34 PM

[moronquote]AIM (AOL Instant Messager) uses XOR to encrypt the password too, so it must be safe!!![/moronquote]

Fred PageSeptember 28, 2005 4:47 PM

@stephen
-I'm certain that I'm missing something (being fairly unfamiliar with Blum Blum Shub), but I don't see a substantive difference in the security of a string of pseudo-random numbers from Blum Blum Shub versus using RSA encryption (which is a public/private encyrption) using a sufficiently large key.

Specifically, both of them rely on the exact same mathematical assumption: that large integer factorization is difficult.

steveSeptember 28, 2005 5:01 PM

Hey, look at the features:

"XorIt gives no pass/fail results"
Great! Enjoy the fun of bit errors. Oh, I forgot, there must be a CRCIt or something to sell...

"Furthermore, if you use an unpredictable file that is the same size"- Yeah, you only need a entropy source with high bandwith... but luckily the filesize is limited to 4GB

"an image of your cat or even a music file." Talking about patterns, yes... If you don't have a cat, simply download the first image from the web ;-)

"as little repetition and as few nulls as possible" - Hey, we found weak keys!

"Use XXX Bytes" - What's next, CeasarIt?

"If your needs are more simpler then you can also use a word (string), but the advantages of the Vernam method are lost then." ---

"evaluate XorIt for a period of 30 days" - or write it yourself tonight!

Chris SSeptember 28, 2005 5:17 PM

I like the DVD of "key files". I've considered similar ideas myself, but don't really have need of that level of security (that is, I'm not prepared to make that trade off).

However, what I was considering was taking an audio stream from a radio plugged into the sound card, recording that, running it through a mixing function (SHA1, or stronger), and using the result to create the "key files". Some advance work would have to be done to ensure there is sufficient entropy in the radio signal; since compression below about 4 kilobits per second usually leaves audio almost incomprehensible, that would suggest that there is at least 4 kb/s of entropy in the radio sample, particularly over a long period. (At this rate, it will take about 100 days to get just over 4 gigabytes of "key files". Would using two different stations on left and right channel provide 8 kb/s of entropy?)

Would that satisfy people here?

Filias CupioSeptember 28, 2005 5:23 PM

@Zwack

"Of course, if you have a secure mechanism for transferring the one time key file then why bother."

It makes sense if your key-file transfer channel has very high latency (James Bond with a briefcase handcuffed to his wrist travelling by submarine) and you have low latency but insecure channel (seize control of the world's communication satellites and broadcast to all TVs and radios.) You get to combine the security of James Bond with the low latency of the satellites, so long as you dispatched Mr. Bond early enough.

ShuraSeptember 28, 2005 5:36 PM

@David Ottenheimer: if done the right way, a one-time pad *is* unbreakable, and it doesn't matter how powerful computers will be in 50 or 1000 years - it's a simple exercise in information theory to show that.

But the key point is that it has to be done the right way; theoretical security doesn't help if the practical implementation suffers from weaknesses. Nevertheless, one-time pads are used, and even though it may seem pointless (if you can securely transfer an n-bit key, why bother with a one-time pad instead of directly transmitting your n-bit message on the same secure channel?), they do have their applications - you can meet someone, exchange a key with them, and later use that to communicate securely. Think of it as deep-frozen security that you can defrost and use whenever you need it (although like food, it's one-use only). :)

ArikSeptember 28, 2005 6:18 PM

@Shura

In order to do it The Right Way (tm) you need to generate a Good Random (tm) OTP. If you have any statistical anomaly or predictability in your OTP, it may be exploited.

From the site: "First select the file to be Xored...Next you select the Cryption file to Xor the source with...The Xor method is especially powerful if you choose a Cryption file that is larger than the source, as most decryption programs work by looking for patterns..."

It's obvious that the author of this web page knows nothing of OTP, because the first thing they have to say is Choose a file which is entirely RANDOM. You can produce a perfectly good and pretty much unbreakable result with this program if you dd if=/dev/random as many bytes as your source file into a file.

Other than that, charging $7.5 for a program that, well, xors two files is a bit too much. I mean, if you know how to generate a Good Random (tm) file, you can go the extra mile and xor them files.

Michael GrahamSeptember 28, 2005 9:02 PM

The Vernam Cipher can be an effective means of ensuring secure communications if the system is implemented correctly. My company sells an encrypted communication system using this technique, but with some significant differences:

1) We provide our client with key-generation system that uses a ComScire random number generator. We have tested output from this device with Diehard and feel it produces an acceptable random stream. Two secure digital cards are filled with 512 byte tables of random numbers.

2)Our clients uses a regular PC to enter a message. This message is written to a CF card. This computer is never exposed to the Internet and has no network card.

3) The SD and CF cards are inserted into a PDA which has an Ethernet interface. The PDA exclusive-ors the plaintext and tables from the SD. Tables are selected using a publicly available number (e.g. digits 2,3 and 4 from the NYSE volume. The number is hashed to point to the table. If a collision occurs (the table has been overwritten due to previous use) a rehash is performed until an unused table is found.

We use SD and CF cards because they can't boot our PC in the event someone has compromised the PDA by introducing code over the net into the PDA. Other activities described above are done to preserve the integrity red/black interface. The PC is never upgraded or exposed to any other software.

The recipient of the message reverses the above procedures (with the exception of key production).

Problems with the system are key-distribution and maintaining physical control of the key SD card. Because our key card can fit in a digital camera and even store pictures in the unused area, it is very easy to pass through inspection.

We only sell this system for communication between two fixed and well-secured sites. It has been successful to date. We have not addressed TEMPEST at this point, but are considering it for a future upgrade.

Don't email me to buy one. We only sell to mineral exploration companies or other users with legitimate needs to protect large data file transmissions.

Michael GrahamSeptember 28, 2005 9:11 PM

I neglected to mention in my previous post that once the first table is selected using the hasing procedure, subsequent tables are selected using the last 8 bytes of the previous table. Since these eight bytes are random we should get fairly even usage of our tables, but this has been a problem in our earlier SW versions.

B-ConSeptember 28, 2005 9:23 PM

"sinnercomputing" -- What an appropriate name.

No thanks, I'll strick with TrueCrypt for the time being.

At least until someone develops am algorithm using a 8192-bit key.

Bruce SchneierSeptember 28, 2005 9:40 PM

"Don't email me to buy one. We only sell to mineral exploration companies or other users with legitimate needs to protect large data file transmissions."

As opposed to the readers of this blog, whose needs are illegitimate?

RogerSeptember 28, 2005 10:21 PM

Am I reading this right? It doesn't do any key management, it just xors together the two files you nominate? Geez Louise, they're asking ten bucks a copy for a program that any novice programmer could write in 10 minutes! Here's my (functionally identical) version, as a Perl one-liner:
perl -MFile::Slurp -e '$o={binmode=>":raw"};$l=length($i=read_file(shift,%$o));$r=read_file(shift,%$o);$k=substr($r x(1+($l/length$r)),0,$l);write_file(shift,$o,$i^$k)' in key out
Yeah it's a memory hog on big files, but what do you expect for a free program that took ~3 minutes to write [1]! (And yes this is Xor-Vigenere not Vernam, but so is theirs.)

I started to wonder if it was a joke too, but then I saw "Sinner" defending it on the Wilder forum link, yep, it seems he's serious.

Note 1: Yes, I'm embarrassed it took that long. I forgot that File::Slurp wants the options to read_file as a hash, but to write_file as a hash ref. Weird.

Preston L. BannisterSeptember 28, 2005 10:49 PM

Bruce, I can see that it is popular to pile on (in agreement with you), but in this case you are being just a bit sloppy.

First, one-time pads (if well chosen and practical in application) *are* probably the absolute best possible form of encryption.

Second, one-time pads (if properly generated and used) *are* practical for some applications. One-time pads are useful when you can securely deliver the pad(s) only occasionally, and want to exchange secure messages in the times in between.

I have a very simple example. My dad moved ~800 miles away. Either he or I drive to visit a few times every year. Writable DVDs (~3GB) and inexpensive USB memory devices (~1GB) can hold a pretty big one-time pad. Assuming a properly generated pad, this would allow us to exchange messages in complete security, with no questions about newly discovered algorithmic weakness.

This need is not entirely academic. He will be doing design work for some local companies, and will need to transfer files in some secure fashion.

Now the vendor in question is unclear on some crucial key points. Do they perform any sort of test on the file chosen for the one-time pad? Some files are good pads, many are not. Some sort of simple check is in order. Are the pads used byte-for-byte (certainly a bad idea for most files) or scrambled in some way?

Now my guess is that the answers to the above questions are all bad - but we lack proof. You would be right in dunning them for not addressing important questions. You are *likely* right in suspecting that they not using good one-time pads. Lacking proof it is premature to label the site and product as "snake-oil".

YvanSeptember 28, 2005 11:38 PM

Hmm. Just tossing this out there, but the idea I had for a OTP cryptosystem is pretty simple.

Take an acceptable source of random data (I would defer to a cryptographer to suggest this for me), and collect a stream of data 1GB (although, now it would be more like 5-10GB to be useable for any length of time) in size. Store the data on two sets of media after encrypting with a public key. This will provide a basic level of protection should someone manage to pilfer or copy a key in transit. Deliver one set of media.

When encrypting a message, a header containing an index into the key material is encrypted using the public key, as well as other useful information. Potential leakage of information, but crucial to ensure that messages and key data are synchronized should a message be lost.

The recipient of the message decrypts the header and then uses the material and performs the same task. Should the key material be exhausted, the message recipient can return the re-usable storage media for replenishment, or the media can be discarded for new media. In a high-volume environment, both parties could be equipped with the tools [i.e. acceptable random data collection; generation of random data only yields pseudorandom :S]

This particular system appealed to me because it leveraged the benefits of OTP crypto to improve security, but reduces the impact of covert replication of the OTP storage media through the use of public key crypto. It doesn't eliminate the need for preshared keys (at least for the public-key component), but given if you really *need* OTP protection, overcoming the organizational obstacles of deploying a set of reasonably sized public keys should be surmountable.

Granted this is a high-level perspective on it, and I am not a cryptographer, but this would seem to me to be sensible. That said I am still working my way through various crypto books and am still a (fairly green) student on the topic.

Rip it apart, because it will be educational for me, or an ego boost if it would be a good approach :)

packratSeptember 29, 2005 1:58 AM

@Michael Graham
"We use SD and CF cards because they can't boot our PC in the event someone has compromised the PDA by introducing code over the net into the PDA."

Not to nitpick, but this isn't necessarily the case. If the PC in question has an IDE flash card reader, or can boot from a USB device, then it can boot from a correctly formatted flash card. I've seen both Linux and DOS boot images that can be used with flash drives. Also, if I remember correctly, Windows leaves autorun on by default for all removable drives, including flash devices. Just inserting the card in the reader can allow execution of any file on it (in the current user's context, obviously).

Andrew Glina (Sinner)September 29, 2005 2:30 AM

I thought that someone as respected as you had more class. I am disappointed. I challenged the crew at Wilder's Security to decrypt a weak file (that is a JPG encrypted with an EXE) and they could not. I found it surprising that they failed as a few even claimed to do that type of thing every day. One even claimed that it would take seconds. If you wish to take up a similar challenge feel free, otherwise please stop slandering me and my site. I agree that the ReadMe and description was flawed, but if you took the time to check you would have noticed that that is an old version and a new version is being released tomorrow. The new version is more clear about the strengths and weaknesses of the method.

OTP is a practical method. With Blum Blum Shub it can even be easy. Furthermore, with large removable drives OTP is no more insecure than your front door key.

I cannot understand your angle. What does someone like you have to prove? Your opinion on OTP is well known. Someone like you can say something and many will believe, irregardless of how true it is. You have done much in the past to deserve this respect. But you have lost mine.

RogerSeptember 29, 2005 3:00 AM

@Preston:
> Bruce, I can see that it is popular to pile on (in agreement with you), but in this case you are being just a bit sloppy.

This is a fair comment, I usually try to be a bit contrary because I think it enhances a discussion if people have to really examine and defend their thinking. Of course that doesn't help on political issues, where if you disagree with someone they just shout louder 8^).

> First, one-time pads (if well chosen and practical in application) *are* probably the absolute best possible form of encryption.

"Best"? What does that mean? I don't think you really justify this; and I note the two pre-conditions you require, which really don't belong in parentheses. A genuine OTP is theoretically the most *secure* form of encryption, but this is not the same as best because "...if ...practical in application" is not true. The proper use of OTP is exceedingly IMpractical. These causes people to fall into three classes:
a) a very limited set of specialist users who have the resources to work through the difficulties;
b) the great majority of crypto users, who shun them; and
c) people who try to take shortcuts to get around the impracticalities, and end up with something which isn't a true OTP, and probably isn't very secure.
This last is worth emphasis. The theoretically perfect security of OTP is very brittle. You _must_ follow all the rules exactly. If you try to skimp, the security can very quickly drop from perfect security to almost nothing.

> Second, one-time pads (if properly generated and used) *are* practical for some applications. One-time pads are useful when you can securely deliver the pad(s) only occasionally, and want to exchange secure messages in the times in between.

That is only part of the requirements, though.
* How are you going to generate 3 GB of truly random bits? It's really quite hard. Most practical solutions you might come up with will be lucky to generate a few hundred bits per second, which means it will take years to fill your DVD. And as soon as you start thinking of ways to speed up the process, you are probably converting your OTP into either a running key cipher or a stream cipher, and completely destroying the proof of perfect security. SO, you've got yourself a stream cipher, which might or might not be secure, but sure as heck has brittle security and clumsy key management. Why not just use a stream cipher someone has studied, and knows to have robust security?
* What are you going to use to generate these pads? A non-networked machine locked in a bank vault, or your regular PC? Hmmmm ... you do realise that in practice, very few security failures are due to cryptanalysis, but total compromises of networked PCs are as common as dirt?
* How do you guarantee destruction of the random bits as soon as used? In diplomatic or espionage service, they are written on magicians' flashpaper, and each page is incinerated once it is used. Last time I tried it, I found DVDs don't burn too well and you certainly can't incinerate them a few sectors at a time. Now you may say that you are going to repeatedly overwrite the used data, but how sure are you that that is unrecoverable? If you're not sure of that, then you don't have a OTP.

[...]

> This need is not entirely academic. He will be doing design work for some local companies, and will need to transfer files in some secure fashion.

Whoa, you are transferring data between multiple recipients? Practical experience says you will want a system which offers ease of key management. OTP is the exact opposite of that. You could hardly choose a less suitable system. Secondly, as a matter of professional liability, most businesses will want you to use something that has been certified. In other words, not your home grown OTP system.

> Now the vendor in question is unclear on some crucial key points. Do they perform any sort of test on the file chosen for the one-time pad? Some files are good pads, many are not. Some sort of simple check is in order. Are the pads used byte-for-byte (certainly a bad idea for most files) or scrambled in some way?

Oh dear. You don't seem to realise: the pad files MUST be totally and utterly truly RANDOM data. You cannot just use existing files. If you use existing files, what you have is called a running key cipher, and is WEAK. VERY weak. Just how weak depends on the degree of entropy in the files, but in the case of, say, English text, it is so weak people break them for amusement as a hobby. If it is, say, highly compressed Zip files of private files not available to an attacker, it may in practice be a serious challenge. But it still won't be even in the same ballpark as serious cryptography.

You cannot even use files generated by a random number generator. That gives you a stream cipher. How strong it is depends on the complexity of your random number generator, and most of them are crap.

To get a OTP, you MUST use genuine, hardware generated true random numbers. Nothing else gives you a security guarantee. In fact nearly everything else is childishly weak.

> Now my guess is that the answers to the above questions are all bad - but we lack proof. You would be right in dunning them for not addressing important questions. You are *likely* right in suspecting that they not using good one-time pads. Lacking proof it is premature to label the site and product as "snake-oil".

The product criticised by Bruce is snake oil for the following reasons:
1. They charge money for a program that simply XORs together any two files. This is a trivial exercise which any first year student could do in minutes, and is not worth charging money for, even $10. It also involves no cryptography whatever.
2. They call it a OTP program, but leave the generation of the pad files up to YOU. In a OTP, generation (and destruction) of the pad files is ALL the difficult and important work. The XORing is trivial. By leaving the important stuff up to people who have no idea of the difficulty of the problem, it is practically guaranteed that most users will use unsuitable files and have worthless security.
3. Worse and worse (and I admit I'm not certain of this yet) it seems to simply use the key file from the beginning, repeating it if the file to be encrypted is longer. If true this means:
a) the same key may be used for multiple files instead of being immediately and securely destroyed. This means that even if they used a truly random pad, all security is totally lost; and
b) if the file to be encrypted is much longer than the key file, we end up with not a OTP, but a Vigenere, which, once again, is pretty weak. Exactly how weak depedns on various factors but in the worst case, we mean solved on a desktop PC in milliseconds.

steveSeptember 29, 2005 3:06 AM

@Michael Graham:
"The SD and CF cards are inserted into a PDA which has an Ethernet interface. The PDA exclusive-ors the plaintext and tables from the SD."

So anyone who can expose your PDA over the net has access to the plaintext on the CF card?

steveSeptember 29, 2005 3:29 AM

@Andrew:
"OTP is a practical method. With Blum Blum Shub it can even be easy." With BBS isn't it effectively Vernam with a stream cipher, and not any more OTP?
What exactly do you mean by calling it "practical"?

Andrew Glina (Sinner)September 29, 2005 3:38 AM

@steve

Well I do not do this myself as I do not agree with using a stream of any kind, but one user I know simply uses a BBS generator and uses it for EMail. His recepient knows of the primes he will be using so there is no need to store the code, only the primes. Thus, the problem of storing a large keyfile is solved. Hence the "easy" part. Beyond that I do not know much more.

(The practical part was not refering to BBS.)

Neil BartlettSeptember 29, 2005 3:48 AM

There's a great quote from the snake oil merchant on that forum thread:

"Quoting Schneier on one time pads is like quoting Bill Gates on open source"

Well, it's difficult to answer that one, isn't it. I think they discovered a new Godwin's Law

steveSeptember 29, 2005 3:57 AM

@Andrew:
Ok, I expressed the question mistakably:
What do you mean by saying "OTP is practical"? I mean, what does this practical mean? Practical for what, in what sense, ... ?

rikSeptember 29, 2005 4:09 AM

@Chris S:

I have a one time pad CD, made a few years ago now, for messages between myself and one other person. The CD was generated by using a webcam pointed at a lava lamp and a lightning ball. Noting that the images coming out of the webcam uncompressed were a bitmap of a fixed size, the largest number that was both smaller than this file size and relatively prime to it was chosen, and that many bytes passed through SHA512 to generate a single block. leaving the rest of the image in the pipe to be the hashed next time (ensuring that the aparentl position of the two aparently random objects was also not static). One snapshot was taken each time the machine had finished hashing the last block.

It's quite possibly the prettiest RNG I've used. Quality of the entropy it generates has not been scientifically tested, but opinions are welcome. If it's known to be poor quality, it was at least a fun experiment.

Happy BytesSeptember 29, 2005 4:56 AM

The question is NOT that OTP isn't secure - the problem is ALWAYS the keyfile. I tried already to explain in the wilders thread to you that using files WITH KNOWN STRUCTURES ( and executables are! ) is the weak point. You seem not to understand this. Do you know what a PE Header is? You can easily reconstruct such things! There are only slighty differences between Section Number, Entrypoint etc. And - the first 1000 bytes of Win32 Executables containing LOT'S OF ZEROS - meaning a XOR with 00h will always result in the Key Byte! That's why it was VERY EASY to find out that you encrypted a JPG picture with a executable! Take a look at my screenshots there - and even a blind guys sees what i mean. Executable Data is __NOT__ randomly! Give me a corrupt executable (Header corrupt) and i'll repair it for you by hand! Using known filetypes as key is YOUR problem - doesn't matter HOW BIG and WHAT data it contains.

Take a look into X-Raying. Peter Ferrie from Symantec explained this pretty well, if i remember right there should be even a tech paper available somewhere.

You see if you XOR 2 known filetypes with each other! THATS A FACT! Based on this you can explorere first the headers. Then you can start to reconstruct step by step the keyfile. If you have the Header you might then know based on JPG Header which pixelsize this picture has! You can even see with which program your "secure" data was created - in your case it was Adobe! Do you really think that people are so stupid to believe that XOR'ing 2 known filetypes will result in security?

a^b=cSeptember 29, 2005 5:07 AM

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

Do they not realise that it's impossible to break a vanilla XOR key? You might happen to guess it, of course, but you'd *in fact* just be guessing the original plaintext (the hard way) if you did so, with no way to actually verify that you'd guessed correctly.

One-Time-Pads have their uses, I'm sure, in the context of shared, mutually unreadable secrets, but for encryption... well, you can't get the 'key' to the recipient any more securely than you could get the entire plaintext to them, can you? So the usefulness is marginal at best.

Andrew Glina (Sinner)September 29, 2005 5:14 AM

@Happy Bytes

I gave you a chance to prove your point and you either failed or you didn't try. I don't really care which one it was now. (Trying after I tell you what the file was hardly counts.) You have made your point about headers several times and it is getting a bit tiresome.

Finding out the type of file that was encrypted or was the key does not get you very far unless the rest of the file is predictable. Obviously if you were encrypting something like text then you would not do that. But in my example it was a JPG.

Yes I know that it was not secure. That was not my point. My point was that it could not be decrypted in "seconds". No one proved otherwise. If I used a true unpredictable random file then it would have been impossible to decrypt and that would have proved nothing as that is a known fact already. Even Bruce Schneier agrees with that.

Please do not make the same point again. You are making a quite interesting and educational debate boring.

Andrew Glina (Sinner)September 29, 2005 5:19 AM

@a^b=c

I agree. It is not an encryption method to solve all problems. For example, it is not practical to use it to encrypt your whole hard drive. Most users that I know use OTP for EMail, like a few of the posters here.

steveSeptember 29, 2005 5:29 AM

@Andrew
Ok, but then you still have to get your hands on enough random data, and you would need a key management to avoid using the same key twice, or am I wrong?

--

Another interesting aspect of OTPs: Imagine you're living under a totalitarian regime, and you encrypt correctly (assuming you use a sufficient random source). The police searches your house and finds the ciphertexts, but you have hidden and/or destroyed the key.
Then they could construct every plaintext they want and claim they have found the key. There is no way to prove the opposite...
(I would say using AES/CBC it will be very hard to find a second key that decrypts the ciphertext to readable text...)

Andrew Glina (Sinner)September 29, 2005 5:47 AM

CryptIt has simple key management with the "Drive Mode". It does not delete the key, but my idea was that you have several named keys and once used you don't use it again, or delete it yourself. Remember that my program does not differentiate between encrypting and decrypting.

But you are right. For optimum security (as in 100%) you do need a good source of random/unpredictable data, and that is hard to come by. I am working on writing a OTP generator myself, but it will be slow. (5KB a day at most probably.)

Personally I feel that the best method is one that the user creates themselves. I have heard of variations of the old webcam idea. I like riks version of this, another similar one is a fish tank.

It is a hard method, that I do not deny. I have recieved many EMails over these programs and I used the feedback from those to make an improved version that clarifies the procedure. But it still is a limited method, and in most cases conventional encryption is the better option.

I am only here to defend my reputation.

Incidently, you make an interesting (and ammusing) point. I will consider adding a warning for people living in totalitarian regime countries.....

Gopi FlahertySeptember 29, 2005 6:18 AM

Andrew:

Let me try an analogy.

One medical problem some people have is lactose intolerance. They have trouble digesting lactose in milk products. There are medications on the market you can take, and will help you digest milk you have consumed.

Let's say we have a company offering one of these in pill form. For it to work, you need to take it 30 to 60 minutes before you consume lactose. Take it too long before, and it's gone before you digest the milk. Take it at the same time as the milk, and the milk makes you sick before the pill does anything.

Now, on this mythical company's web site, they have pictures of people sitting at a dinner table, pill in hand, bowl of cereal and milk in front of them, looking like they're about to eat the pill and eat the cereal. In the documentation for this product, they talk about how convenient and flexible it is, and how you can eat the pill any time of day. They make a passing reference that perhaps you should take it 30 to 60 minutes, but don't really explain that it is almost entirely ineffective if you ignore that.

What would you think about this company? Would you trust them? Would you consider, "oh, we'll fix the documentation in the next version" to be a sufficient explanation? Personally, I'd want to know how and why they got it so totally wrong before I trusted anything they said.

I think this analogy is very similar to Andrew's software. It is absolutely true that this software could be used correctly with a one time pad. However, the documentation, instructions and screen shots are misleading enough that many users of this software will use it in an _extremely_ insecure manner without understanding their mistakes.

Your software is in the doghouse because a user, following the instructions you provide, is likely to produce a file that is not properly encrypted.

Happy BytesSeptember 29, 2005 6:32 AM

@Gopi: That's exactly what i try to explain with using known filestructures as encryption keys. ;-)

Of course they Author says that it's getting bored, but THIS is exactly the point.

Andrew GlinaSeptember 29, 2005 6:36 AM

Interestingly, I updated my program description for XorIt a few days ago due to the debate on Wilders. There were many fair points made there so I updated the website (but not the readme) so it explained the methods used with more details. In particular I removed the reference to example files as with some, in particular the page file, I was wrong to advise the use of. However I just noticed that Bruce has quoted the older one. I am assuming that this was a honest mistake.

So please, if anyone wants to insult my description of XorIt, please read it from the website first. I also include in the new version of CryptIt (unreleased but it is on my Beta page) a detailed explanation of XOR encryption methods. Feel free to insult that also. I spent a decent amount of time doing research while I was writing that (including Bruce's Snake Oil page) and I feel that it cover the subject well without being too biased or overly descriptive. But I am always open to debate. I feel it is one of the best ways to learn.

Andrew GlinaSeptember 29, 2005 6:44 AM

@Gopi

I covered most of your point in my earlier post, but what is wrong with the screen shot?

Besides, if you use a normal encryption program and then use a bad password, like "Password", then it is insecure also. What is the difference?

Happy BytesSeptember 29, 2005 6:50 AM

Andrew, you've just missed the train!
Security has something to do with TRUST. Would you give someone your house keys during your holiday time to take care of your pets when you do not trust this person? I wouldn't.

How can you trust ( even if it works! ) an security program when the author suggest to use it with completely insecure key files? Does make sense or?

I mean that would be exactly the same if an antivirus company states on ther homepage: "It's not really necessary to activate the real-time monitor scanning because scanning on demand from time to time is good enough if you only check your emails".

===> I wouldn't even consider to buy this product - because the company behind this has NO Sense of responsibility infront of ther costumers.

Otherwise they wouldn't advise such BS.
You fixed it NOW - that's fine, but doesn't change anything on the fact that you did start discussion in the wilders forum BASED ON THIS NOTORIOUS BULLSHIT.

Andrew GlinaSeptember 29, 2005 7:05 AM

@Happy Bytes

Your point always has been that you can extract the file once you decode the header. I still dispute this. I did not start any discussion. As always I am just defending myself when I am insulted. There is no need for you to swear. No one is insulting you.

As for trust, I certainly would not trust you anyway. I am still waiting for an explanation why you disassembled the registration section of my program, posted it on the Internet, and then made incorrect accusation about logic flaws. Why did you do this? This is what a cracker would do. Do you want people to think that you are one?

Are you saying that you have never made a honest mistake? You have proved otherwise already. Many security companies have made mistakes, and I do not even claim to be one.

I am happy to admit my mistakes. I learn from them and become a better person. But do not dispute my honesty. That is the only reason why I am debating.

Gopi FlahertySeptember 29, 2005 7:13 AM

Andrew:

"Besides, if you use a normal encryption program and then use a bad password, like "Password", then it is insecure also. What is the difference?"

People are much more likely to understand the idea that somebody can guess "Password" than to understand the difference between real random numbers and pseudo-random numbers.

User stupidity is nearly impossible to prevent. However, the problem with an OTP is that generating true randomness is a very difficult challenge. The challenge has moved from "generate 128 or 256 bits of randomness" to "generate many many megabytes." Users of your software are very likely to make mistakes despite their best intentions, and are unlikely to understand their mistakes or be able to properly analyze what went wrong.

Your CryptIt description on your web site still suggests using a swap-file, by the way.

I'm happy to hear that you seem to be realizing the mistakes you made earlier, but there's one important, fundamental thing I think you need to realize:

One time pads have very bad failure modes. Very slight deviations in how you do things can have an _enormous_ impact on their security, more so than most other algorithms. An "almost random" number source does not give you "almost perfect" security.

Happy BytesSeptember 29, 2005 7:15 AM

I'm Reverse Engineer. And that's even legal because it's my daily work ;-) Of course i take a closer look to unknown software. I'm well aware that i didn't post the full registration - i just pointed out the fact that regardingless what you enter as key the cpu register EAX will always contain 128 if you input a 128 byte key. That's all. Because i notice such things even without debugging applications. Of course i'm aware of the "more" checks - and it would be highly unfair (and illegal) from me if i would make them also public. If you doub't that i can easily explain the rest of the "protection" via private email to you not that you claim again that i do not know how to do it. As i said already, purpose was to point out this eax thing, nothing more nothing less.

Andrew GlinaSeptember 29, 2005 7:23 AM

@Gopi

I agree, the chance of user error in CryptIt/XorIt is far greater. But on the other hand who would use a program like CryptIt unless they actually wanted a program like it? My new version can analyse files and will report most bad ones. (It fails all text files for example.)

I will be looking into randomness soon when I try to write a OTP generator. I intend to make sure it passes all randomness tests before it is released. But you are probably right. I do have a lot to learn about random file generation.

CryptIt has not been updated yet. It is still in Beta. I try give my users a week to object to any changes (or find problems) before I update a program. Rushing out updates is never a good idea. (Probably tomorrow. The new version is on the site however.)

Happy BytesSeptember 29, 2005 7:28 AM

Ok, AMEN this story now.

You provide correct information on your website and everybody will be happy :-)

Andrew GlinaSeptember 29, 2005 7:50 AM

@Happy Bytes

I will be updating the site in around 18 hours. (It is 11 pm for me.) With all honesty, thanks for your criticisms of my programs. They came at the right time as I was re-writing the CryptIt ReadMe because I already felt it was weak. The Wilders debate gave me many good points on what else was wrong with it. One thing that I added due to the debate was a comment in the program description, not just in the readme, that many feel that the current encryption methods are unbreakable in the foreseeable future already.

Incidentally, I intend to link to this debate from my CryptIt and XorIt page. This has been a quite good discussion. (I don't think it is over yet though...)

Mike SherwoodSeptember 29, 2005 9:52 AM

I wrote an "unbreakable" encryption program that was more complex than this product when I was 15. I have since learned a little more about cryptography by being less defensive of my beliefs and listening to people who have demonstrated expertise in the field.

XOR based ciphers can be useful in some cases. I use an XOR encryption step on all of my important data before running it through PGP. Generating the XOR key can be a time consuming and vulnerable process. The fastest approach I've found is to use "dd if=/dev/zero of=keyfile bs=1024 count=1024" under Unix. This works on all Unix platforms and solves the problem of exchanging the XOR key. I've found a way to optimize this step such that it can process any size file in under a second. If anyone would like a copy of this program, I'll go ahead and write it and post it free of charge. =)

Andrew GlinaSeptember 29, 2005 10:01 AM

@Mike Sherwood

"This works on all Unix platforms and solves the problem of exchanging the XOR key."

But it would then be a stream cipher and thus not 100% secure.

JosephSeptember 29, 2005 11:05 AM

@ Justin

Yes, I'm being sarcastic. Damn text only interfaces! They need to be upgraded with "automatic sarcasm recognizers."

Gopi FlahertySeptember 29, 2005 11:08 AM

Andrew wrote, "I agree, the chance of user error in CryptIt/XorIt is far greater. But on the other hand who would use a program like CryptIt unless they actually wanted a program like it?"

Please read, and think about, your marketing materials. You promise unbreakable cryptography. You also promise easy to use cryptography using any file.

Who _wouldn't_ want your program, based on your original marketing promises? Most people in the world don't understand these issues well enough to make an educated decision.

Andrew GlinaSeptember 29, 2005 11:20 AM

@Gopi

True, but until recently I barely marketed these programs at all. They were driven by a few users who absolutely loved them. (One user registered CryptIt three times, and I do not charge for upgrades!) Eventually I decided to put them on CNET, and thus to a wider audience.

But I can tell you that most do not want these programs. They are not that popular at all. (Under 50 registered users.) I think it is because I do stress (even in the old description) that passwords will not work well with CryptIt. (XorIt doesn't even support them.)

Ari HeikkinenSeptember 29, 2005 5:34 PM

That's probably the best quote of nonsense I've seen so far. They talk about brute forcing large keys with "enough computers" and xor'ing files with other files as encryption.. Heh..

packratSeptember 29, 2005 8:49 PM

This whole discussion, I think, serves as another reminder that any security system is only as strong as it's weakest link. In this case, that weakest link is key management (to say nothing of key exchange).

Andrew GlinaSeptember 29, 2005 9:09 PM

@packrat

I agree with you completely. If you cannot be 100% sure of your key transfer/storage method then the method of my software is not for you.

Michael GrahamSeptember 29, 2005 10:00 PM

Bruce: My comment about not contacting me to buy one of our systems was intended primarily to ensure no one thought I was trying to sell anything. This blog is very informative and doesn't need people trying to sell things.

The comments about getting the plaintext off the CF card when the PDA is connected to the net is very interesting. There is a reasons for this decision. We did not want to mix cipher text and plaintext on the PC. This seems counterintuitive because you would normally want the plaintext/ciphertext pair to not be on the machine connected to the Internet.

We feel that we have a more controllable environment on the PDA in terms of knowing what every process, application, etc. is, what should and shouldn't be in various places, resistance to viruses etc. A Windows system has a lot going on. When we perform the exclusive or on the PDA we put the ciphertext where the plaintext used to be on the CF card. The screen then instructs the user to plug in the network cable and transmit.

This is not perfect but we feel it is relatively secure. When I was doing IV&V on command and control systems, the government was only using operating systems that had fixed memory and did not use VM or page. If you are trying to secure a system or understand a system it is very helpful if you are running in a very simple environment. The PDA gives us that.

HSSeptember 30, 2005 3:38 AM

Andrew wrote:
"But it would then be a stream cipher and thus not 100% secure."

But according to the IPsec RFCs (RFC 2406, Conformance Requirements) there are only two encryption algorithms which must be implemented by IPsec systems:
DES and the method described by Mike Sherwood (which is specified in more detail in RFC 2410).

But DES is weak, and if Mike's method isn't secure either, then there are no secure algorithms required for IPsec! That's bad!

Andrew GlinaSeptember 30, 2005 5:22 AM

@HS

Well, I didn't say that it wouldn't be secure, I said it would not be 100% secure. That is, it would not be unbreakable. In short, it is a bit pointless using using a stream cipher as a key to XOR as then you are using a similar process to conventional encryption. It would be easier, and probably more secure, to use a password based encryption program.

JoachimSeptember 30, 2005 8:48 AM

Aloha!

Well, they do have received plenty of acclaim and awards for CryptIt, so then it _must_ be good:

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

I really liked the quote from the well known and highly reputable "Dr Mike":

I looked for a special encryption, named Vernam Cipher or Xoring, and found CryptIt. Mr Glina expanded CryptIt to my personal wishes and made it a very fast program. There are a few freeware programs which do Xoring, but they can not compete with CryptIt. It is almost perfect. (Almost as I believe there is nothing perfect.)

MarcSeptember 30, 2005 8:59 AM

@HS
Based on recent research that I have completed, I believe that the method Sherwood describes is secure. We have, in fact, demonstrated it's equivalence to a EDED 4DES cipher using a pair of known-strong keys.

This demonstration that the method as decribed in RFC2406 is as secure as a 4DES variant proves it is more secure than 3DES.

HSSeptember 30, 2005 10:53 AM

Thanks Marc!

That's good news. I've heard that 4DES is quite a bit slower than RFC2410, that's why I wanted to avoid it. AES-256 ED with CBC seems to offer a good combination of speed and security. maybe I'll switch to that once it becomes available. Thanks for your research, you really saved my day!

MichaelOctober 1, 2005 9:16 AM

Some things to mention:

1. Not everybody can easily code a XOR program. I, for example, cannot. Mr Glina’s program xors, it does not pretend to do anything else. I use it, it works reliable and fast. In my opinion it is worth the money.

2. As far as OTP is concerned, refer to
http://www.pro-technix.com/information/crypto/...

3. Of course are the files Mr Glina mentioned (music etc.) not random data and therefore not suitable for OTP. Nevertheless it will be very difficult to decrypt when, e.g., using a music-file as key file.

4. Mr Glina’s program does not provide key files. Do not blame him for bad key files.

5. For OTP you will need random key files and you will have to exchange them in a secure way. This will be difficult. The suggested CD/DVD exchange method will work fine. On the other hand it shows that OTP will be complicated when more than two partners are involved.

5. BBS will be quite good in generating PRN-files, if choosing the right Generator Parameters. Refer to Michael Monagan, Greg Fee A Cryptographically Secure Random Number Generator for Maple http://oldweb.cecm.sfu.ca/CAG/products.html
BBS has a fine additional aspect, see the original publication or look for Probabilistic Encryption Key Exchange (Blum/Goldwasser) http://www.connotech.com/PEKEELEC.HTM

6. It is quite difficult to define and to test Randomness as well. For checking for random quality there are free tests available. Refer to E.N.T. http://www.fourmilab.ch/random/ and to The Marsaglia Random Number CDROM including the Diehard Battery of Tests of Randomness http://stat.fsu.edu/pub/diehard/

7. For exchanging short messages (< 1 MegaByte, my usually do not exceed 100 kiloByte) via E-Mail BBS files and XorIt are the best I could find. If somebody knows something better, please tell me.

HSOctober 1, 2005 11:25 AM

Michael wrote:
"1. Not everybody can easily code a XOR program."
True, but every serious programmer can.

"Mr Glina’s program xors, it does not pretend to do anything else."
It claims to be a file encryptor (we are talking about CryptIt, not XorIt), and it claimed (before the site was changed) that it would be "virtually unbreakable" (without mentioning that you would need high quality random data for this).

"I use it, it works reliable and fast. In my opinion it is worth the money."
If you want real encryption, then you'd better use gnupg - which is free - or PGP. In typcial usage scenarious even programs like 7zip are probably more secure than CryptIt (and are free too).

"As far as OTP is concerned, refer to http://www.pro-technix.com/information/crypto/...
Have you read it? Notably the part about "True Randomness"? You should ask the people who e.g. implemented /dev/random in Linux about how hard it is to produce true random data.

"3. [...] Nevertheless it will be very difficult to decrypt when, e.g., using a music-file as key file."
This may protect your data from your little sister, but not from a real attacker. Suggesting that it would be harder to break than 128-Bit symmetric ciphers (as the webpage did before it was changed) is very misleading.

"4. [...] Do not blame him for bad key files."
There are *no* good key files for OTP on your average PC, and creating them is difficult and *very* slow (maybe a couple of kilobytes per hour, if the system is used).

"5. For OTP you will need random key files and you will have to exchange them in a secure way. This will be difficult."
Alright, finally something we agree on.

"The suggested CD/DVD exchange method will work fine."
No it won't. You still have to produce real random data instead of using pseudo random or even non-random data like all the files you have on your system.

"5. BBS will be quite good in generating PRN-files, if choosing the right Generator Parameters. [...]"
PRN stands for *Pseudo* random numbers - so this is no longer a OTP, and doesn't have the security properties of a OTP. Guess the initial values for your BBS, and you have decrypted the file. So how many bits of true random data did you use to seed your BBS? Why not simply use a carefully designed and tested block or stream cipher?

"6. [...] For checking for random quality there are free tests available.[...]"
Which only test statistical properties, not their quality for OTP use. I am fairly sure data encrypted with a block cipher would qualify as "random" according to those tests, even though it isn't random at all.

"7. For exchanging short messages (< 1 MegaByte, my usually do not exceed 100 kiloByte) via E-Mail BBS files and XorIt are the best I could find. If somebody knows something better, please tell me."
See above. If you are serious about security, use PGP or gnupg (which can do symmetric encryption too if you don't want to bother with public keys).

MichaelOctober 1, 2005 3:35 PM

"As far as OTP is concerned“
Have you read it? Notably the part about "True Randomness"? You should ask the people who e.g. implemented /dev/random in Linux about how hard it is to produce true random data.

Yes, I have read it. I know how hard it is is to produce true random data. Please define random.

"3. [...] Nevertheless it will be very difficult to decrypt when, e.g., using a music-file as key file."

This may protect your data from your little sister, but not from a real attacker. Suggesting that it would be harder to break than 128-Bit symmetric ciphers (as the webpage did before it was changed) is very misleading.

I think it will be very difficult to get it to a test. Unfortunately I do not know anybody who can real attack. But you are right in general.

"4. [...] Do not blame him for bad key files."
There are *no* good key files for OTP on your average PC, and creating them is difficult and *very* slow (maybe a couple of kilobytes per hour, if the system is used).

I agree.

"5. For OTP you will need random key files and you will have to exchange them in a secure way. This will be difficult."
Alright, finally something we agree on.

"The suggested CD/DVD exchange method will work fine."
No it won't. You still have to produce real random data instead of using pseudo random or even non-random data like all the files you have on your system.

The exchange method will work fine irregardless the quality of the key files. Just a method of secure exchange. I did not refer to the files. Sorry for unclear wording.

"5. BBS will be quite good in generating PRN-files, if choosing the right Generator Parameters. [...]"

PRN stands for *Pseudo* random numbers - so this is no longer a OTP, and doesn't have the security properties of a OTP. Guess the initial values for your BBS, and you have decrypted the file. So how many bits of true random data did you use to seed your BBS? Why not simply use a carefully designed and tested block or stream cipher?

Do you know how BBS works? For my BBS there is N = P*Q, P and Q primes with some special properties, each 600+ decimal digits. The seed, as you call it, is always a number with 600+ decimal digits. Good luck guessing! But you are right: if you know the start parameters, you know the key file.
I use BBS for its special advantage I mentioned before. The BBS has a special feature: If you know both the GeneratorParameter N and its prime factors P and Q you can, with the further knowledge of one output xi (i chosen at will) and its position in the row (= i) calculate any wanted xk directly. There is no need to go through all the iterations to k. And this works in both directions (i > k, i 0) and i + m as well to the first partner, than the first partner would, with his knowledge of P and Q, be able to recalculate the key file. The advantage is that there is no need to give P and Q away. No transmission, no transmission difficulty. The security depends on the assumption that it is difficult to factor N. Today there is no public known algorithm (except on a quantum computer) to factor a biprime N with 1200+ decimal digits. Keep N secret as well and it will be impossible to reconstruct the key file. Please confer Monagan and Fee I mentioned before for mathematical details.

"6. [...] For checking for random quality there are free tests available.[...]"

Which only test statistical properties, not their quality for OTP use. I am fairly sure data encrypted with a block cipher would qualify as "random" according to those tests, even though it isn't random at all.

Again, define random. And give a method to distinct between true random and a BBS-file with appropriately chosen Generator parameters. Or any other file passing the statistic tests.

"7. For exchanging short messages (< 1 MegaByte, my usually do not exceed 100 kiloByte) via E-Mail BBS files and XorIt are the best I could find. If somebody knows something better, please tell me."
See above. If you are serious about security, use PGP or gnupg (which can do symmetric encryption too if you don't want to bother with public keys).

I cannot really check what PGP does. I can check what XorIt (or CryptIt, I used it before there was XorIt available, but the XOR part only) does. I do not want to be forced to trust something I do not understand.

MichaelOctober 1, 2005 3:40 PM

Sorry, transmission problem before.


I use BBS for its special advantage I mentioned before. The BBS has a special feature: If you know both the GeneratorParameter N and its prime factors P and Q you can, with the further knowledge of one output xi (i chosen at will) and its position in the row (= i) calculate any wanted xk directly. There is no need to go through all the iterations to k. And this works in both directions (i > k, k > i)

So, if one uses a BBS with known N to both partners and the factors P and Q to the first partner only and makes use of i iterations for the key file and gives the result of the i + m’s iteration (m to be chosen by the second partner, m > 0) and i + m as well to the first partner, than the first partner would, with his knowledge of P and Q, be able to recalculate the key file. The advantage is that there is no need to give P and Q away. No transmission, no transmission difficulty. The security depends on the assumption that it is difficult to factor N. Today there is no public known algorithm (except on a quantum computer) to factor a biprime N with 1200+ decimal digits. Keep N secret as well and it will be very hard to reconstruct the key file. Please confer Monagan and Fee I mentioned before for mathematical details.

Andrew GlinaOctober 1, 2005 9:22 PM

I still stand by my description of XorIt and CryptIt. The only part that I "take back" is the page file example. As I said in the quote above...

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

Sure, I do not say the exact details of what you need to make a "good key", but it does say in the ReadMe. (Even in that version.) Since my programs are either Freeware or Shareware then people have ample opportunity to look into what make a good key before deciding to pay me. Besides, I don't recall seeing on the front page for any security program "usage of bad passwords will result in bad security). For example the PGP page...

http://www.pgp.com/products/desktop/home/...

...calls itself "strong", "robust" and "secure" for "both casual and power users". No mention of why, and not one mention of limitations. If people want to know more, then they read more. This is little different to my software, except perhaps that the person who wrote that blurb is a marketing expert and I am not.

Incidentally, we are not talking about CryptIt at all. It may say CryptIt, but the link and the description is for XorIt.

MichaelOctober 2, 2005 12:22 AM

Mr Glina is right.

PGP may come out as weak depending on the key, which may be chosen poorly.

So I depend on things I know or can test myself, respectively. Which means XorIt and BBS.

HSOctober 2, 2005 5:41 AM

Michael wrote:
"Please define random."
There is a nice definition on the webpage you linked to.

"I agree." [regarding the difficulties in creating good files for OTP]
But without good key files, this encryption method loses its strong security.

"The seed, as you call it, is always a number with 600+ decimal digits. Good luck guessing!"
How did you create this seed? Unless doing this very carefully, your seed doesn't really contain 600+ decimal digits worth of true randomness.

"[...] Keep N secret as well and it will be impossible to reconstruct the key file."
OK. But you no longer have a OTP. What you have is a stream cipher with different security properties than a OTP. Suddenly you have the same "problems" like other ciphers.

[testing for randomness]
"Again, define random. And give a method to distinct between true random and a BBS-file with appropriately chosen Generator parameters. Or any other file passing the statistic tests."
See the definition you linked to. Having a method to distinct between the two is irrelevant - you have to assume that your attacker knows or suspects that you use a BBS. So the problem of recreating a truly random file (impossible, thus the security of a OTP) is reduced to guessing the correct initial values for BBS - still very hard, maybe practically impossible, but *much* easier than for a true OTP. Now if the attacker knows something about how you created your initial values and you didn't get this part right, then suddenly it may become feasible for him to recreate your key file.

"I cannot really check what PGP does. I can check what XorIt (or CryptIt, I used it before there was XorIt available, but the XOR part only) does. I do not want to be forced to trust something I do not understand."
That's your decision. I for one prefer to rely on people who understand the problems better than I do and who invested a lot of their time to get things right instead of trying to get it right myself. Maybe you got it right at the first try and now have a good encryption. However your security does not depend on CrypIt or XorIt, it solely depends on BBS and the values you chose for it. You *don't* have a OTP. CryptIt/XorIt did not add anything to the security of this method, it's all in the BBS.

@Andrew
Your program does not do encryption. It can be used to build a true OTP system, but you are not solving any of the difficulties of actually working with a OTP. None whatsoever. But you claim: "If you want unbreakable encryption, try CryptIt or XorIt.". And the fact that you make the dangers of reusing a key file once sound like pretty much a theoretical problem is not very encouraging either.

Writing a program to xor two files does take less 2.5 minutes (including startup time of editor) - it doesn't have a GUI, it's slow, but it does the same thing. Nobody is solving encryption problems with 150 seconds worth of programmer time.

Regarding CryptIt vs XorIt: You are probably right - I got confused because none of the updated webpages still match the text cited by Bruce Schneier. But as both claim to be "unbreakable" this doesn't really matter.

Gopi FlahertyOctober 2, 2005 6:20 AM

@Michael writes:
"So I depend on things I know or can test myself, respectively. Which means XorIt and BBS."

So you're saying that you truly understand attacks against pseudo-random number generators? You understand how the lack of randomness in your PRNG interacts with the patterns and lack of randomness in the file you are encrypting?

The pad you are using has patterns - there's absolutely no question about that. You generated it using a 600 digit number. You have, _at_absolute_best_, about 2000 bits of key.

Patterns of various kinds in the plaintext can be used to reduce the effective keyspace of the key - because the pad itself also has patterns. Both the pad _and_ the plaintext contain patterns; if an attacker can understand the relationship between those two patterns, they can start breaking it.

The security of your system is entirely dependent on the relationships between these components, and it seems fairly clear that you don't have a deep understanding of them.

You say you want to use a system that you understand - yet you don't appear to know any way to determine the difference between your less than random pads and a truly random pad. If you don't understand that, then you don't understand how your system works.

Andrew GlinaOctober 2, 2005 6:26 AM

@HS

Does not do encryption? OK, I will take your word for that as you must be using some sort of special meaning for "encryption". But if I XOR one file with another unpredictable file it is impossible for you to XOR it back to the original file without the second file. Call it whatever you want, but it does prevent the file being read. Using the key a second time will not make the file completely readable, but with analysis, you could extract parts of the file. You do not believe me? There is no need to. Project VERONA...

http://en.wikipedia.org/wiki/VENONA


...is a good example of what happens when OTP is used badly. But even then most messages were not broken. To quote Wiki...

"Out of some hundreds of thousands of intercepted cyphertexts, it is claimed that under 3000 have been partially or wholly decrypted."

OTP is unbreakable (are you disputing this fact?) and has it's place, and it has been explained several times on this page so there really is no need to do it again. As for solving the problems of OTP, will it help when I write a OTP generator?

Perhaps you could or even have write a program. (You beat me in speed but I dislike modern languages and I pay the price for it.) But could you put up with people like you attacking your work? That is what I have to do. If you want the job, feel free.

(I am not sure where Bruce Schneier was quoting from. I changed that page about a week before he posted this "review". That is why you cannot find that text. It is from the previous version of XorIt which you can still download.)

Andrew GlinaOctober 2, 2005 6:39 AM

@Gopi

Nice technobabble there. Accusing someone of a lack of understanding without giving one reason why you do. Patterns in the original file? Perhaps, but if you compress it then the only pattern left is the header, and that will only tell you the file type.

BBS is a special PRNG and in that it has never been proven to be reversable. (Although it probably is.) Finding out the pattern of a BBS XORed with a file would be far harder than decrypting a normal cipher stream. The only disadvantage of using BBS is the time taken to make the stream.

Gopi FlahertyOctober 2, 2005 7:19 AM

@Andrew writes:
'Besides, I don't recall seeing on the front page for any security program "usage of bad passwords will result in bad security)."'

You're right, you don't. However, you also don't see text suggesting that your password can be anything, including your favorite football team! You're also ignoring a very important point: It is _much_ easier to understand password guessing than randomness.

'The only part that I "take back" is the page file example.'

I see. Well, just out of curiosity, I did a quick analysis of some mp3 files on my computer. You proposed - and have not yet withdrawn your endorsement of - using them.

I analyzed about 50 mp3 files from my collection using a short python program I wrote. Every single one of them had a _continuous_block_ of zero bytes of _at_least_ 2000 characters, starting between 2000 and 3000 bytes into the file!

Furthermore, for every file I tested _over_90%_ of the first 8192 bytes were zeroes!

The AAC files I looked at were a bit better, only having 50% zero bytes in the first 8192, but they still had at least 1700, and up to 7958 long contiguous sequences of zero bytes. However, while the MP3 files have a lot less zeros after 8192, the AAC files are still at 40%-50% zero bytes for the entire first 65536 bytes of the file.

You still stand by your statement that "the key file can be anything," including a music file that'll leave the beginning of your file 90% plaintext?

Gopi FlahertyOctober 2, 2005 7:31 AM

@Andrew:
"Accusing someone of a lack of understanding without giving one reason why you do."

I don't! I don't claim to understand how the patterns present in those different forms of data will interact. What I was trying to demonstrate is that the parts of the system that were easy to understand, that he _did_ understand were not the parts that mattered.

What I was claiming was that understanding the security of XOR + PRNG requires understanding a lot about the PRNG. Understanding XOR + random pad is easy but isn't the same thing.

"Finding out the pattern of a BBS XORed with a file would be far harder than decrypting a normal cipher stream."

Do you have a reference or citation for that claim? I was under the impression that it was hard to accurately compare the two, so I'd like to read a more technical explanation of that.

Andrew GlinaOctober 2, 2005 7:38 AM

You must be using LAME. It does that a lot. I did not say MP3 and once again I did not say that it will give you unbreakable security. I only said that a good key file will give unbreakable security.

But in my new version of CryptIt (written before this review I might note) I have a file analyser that will recomend not using files like that.

CryptIt never claimed to be easy to use. If you think that it did then you are kidding yourself. What is easier, a 4K file or a word. I should know, the word wins out.

Andrew GlinaOctober 2, 2005 7:53 AM

@Gopi

Sorry. I apologise. That was rude and un called for. This debate is pointless and silly and it is getting me annoyed. (Luckly I am in the middle of a work out so I have somewhere constructive to vent!) I am convincing no one of nothing. I will go and let you guys insult my software by yourselves. It is hardly worth defending a piece of software that has made only $50!

I have linked to this page (a few days ago) so my users can decide for themselves.

Gopi FlahertyOctober 2, 2005 8:03 AM

"You must be using LAME. It does that a lot."

Some of the files are from LAME, some from iTunes. Both of them are fairly popular programs for encoding MP3s.

"I did not say MP3"

What's your point? You suggested music files; I tried files of the two formats that are by far the most commonly used. If you ask a computer users to choose a music file, what are the odds that they'll choose something _other_ than MP3?

"and once again I did not say that it will give you unbreakable security. I only said that a good key file will give unbreakable security."

And, in the next sentence, you tell people that they can use _any_ key file. You helpfully give them four examples - all of which are fundamentally useless. Nowhere do you mention that your examples are actually really terrible.

Your statement, as read by most people, would be understood to claim your examples were good. Why do you even give such atrocious examples?

Andrew GlinaOctober 2, 2005 8:17 AM

I wrote the ReadMe in a hurry. It suxed I know. I have corrected it. (Once again, prior to this write-up.) CryptIt has never been a successful program so I have had better things to do than improve a ReadMe for a unpopular program. If you do a search of the net you will find loads of programs with bad ReadMes. I have spent more time debating CryptIt in the last 2 weeks (this all started on Wilders) than on the program itself and it has become extreamly silly.

You win. Yay!

HSOctober 2, 2005 8:21 AM

@Andrew:
OTP is unbreakable - true. But as your program does next to nothing to actually create a OTP system this is meaningless. XORing is easy (hence my 150 seconds programming example). Creating the key file is the hard part. Very hard.

Writing a "OTP generator" (I assume you mean a tool which creates random data computed from events like user input) would be a much bigger step to achieve a real OTP than writing a program that does XOR - but I doubt you (or most other developers including me) are able to do this correctly. But at least I am aware of the difficulties and know this is better left to professionals (and BTW to the OS, which is in a much better position to gather entropy).

Why should I have to put up with people attacking my work? *I* never claimed to offer virtually unbreakable encryption.

Regarding VENONA: apparently the soviets made a few mistakes while using an otherwise good OTP - and had some of their traffic decrypted. But using files from your computer is much weaker than what the soviets did. I also doubt the users of your program will make less mistakes than trained persons handling secret data. So expecting your method to be secure (oh sorry, I meant "unbreakable") is expecting a bit much.

I am curious: how many files suitable for real OTP encryption (i.e. full of true randomness, not algorithmically generated) do you have? How did you create them?

"Finding out the pattern of a BBS XORed with a file would be far harder than decrypting a normal cipher stream."
Xoring a file with the output of a BBS is a normal stream cipher.

Gopi wrote (regarding Michaels seed for BBS):
"You generated it using a 600 digit number. You have, _at_absolute_best_, about 2000 bits of key."
Let's assume that breaking BBS is comparable to breaking RSA (just a guess because both need to factor two large primes). The NSA article about ECC (linked from Schneier's Blog) has a nice table, indicating that this is rougly comparable to a 112 bit symmetric key.

Andrew GlinaOctober 2, 2005 9:21 AM

I just don't know when to quit do I?

@HS

I have infinite OTP files. I use the scrabble method. It is big enough for EMails and 100% unpredictable and 100% unbreakable. I can give you a test file if you want to dispute this.

Feel free to test my OTP generator when it is finished. If this circus is still open I will post it here.

@Bruce Schneier

You know what really annoys me about this little story? I had scheduled an upgrade of CryptIt / XorIt (they are linked at the hip) and I was working on it when I receive an EMail from someone who liked XorIt. She posted to Wilders my program, and got attacked for it. I step up to defend her and my program, like any responsible author should. I make my points, they make their points, no one changes their mind, and the whole thing dies down. In this lull I get CryptIt finished and I start my 1 week beta process like any responsible developer. In the mean time, you get wind of this debate and decide to rehash it. By this time I have updated my description for XorIt, but am awaiting comments from users prior to updating the ReadMe to XorIt. You decide to use the un-updated version (I am sure it was an accident) that I wrote 3 years ago, and I then spend another week defending a ReadMe that I have already decided was flawed. True I could just ignore you, but it does come down to it that you are respected, and thus any opinion of yours will be seen as a fact to some. Thus I am here trying to defend a document that I have already changed! Only I would be silly enough to fight for such a hopeless cause!

Moral of the story? No good deed goes unpunished.

HSOctober 2, 2005 12:26 PM

If by "scrabble method" you mean manually drawing letters from a bag, then yes, that should work (assuming you have 256 different letters in your bag, always use the full set with equal numbers of each letter etc.). You really should recommend this method to your users, as you have not mentioned any other secure method of creating OTP key files.

But claiming you actually have "infinite OTP files" is a bit of a stretch - what's the maximum rate at which you can create them?

MichaelOctober 2, 2005 1:24 PM

@HS
-The seed, as you call it, is always a number with 600+ decimal digits. Good luck guessing!"
How did you create this seed? Unless doing this very carefully, your seed doesn't really contain 600+ decimal digits worth of true randomness.
You are right.
-[...] Keep N secret as well and it will be impossible to reconstruct the key file."
OK. But you no longer have a OTP. What you have is a stream cipher with different security properties than a OTP. Suddenly you have the same "problems" like other ciphers.
As I said. Exchange gets difficult with more than two partners. If there are two partners only they can use a BBS with same P*Q=N.
-[testing for randomness]
you have to assume that your attacker knows or suspects that you use a BBS. So the problem of recreating a truly random file (impossible, thus the security of a OTP) is reduced to guessing the correct initial values for BBS - still very hard, maybe practically impossible, but *much* easier than for a true OTP. Now if the attacker knows something about how you created your initial values and you didn't get this part right, then suddenly it may become feasible for him to recreate your key file.
O.K. Let’s assume the attacker knows I use BBS. As you say, guessing is (almost) impossible. As always, most secrets are lost through treachery and sloppery. If the attacker has access to my generation process, I am lost. That’s the difference to true randomness. But how to distinguish two files (random / PRN) without having access to the generation process?
-However your security does not depend on CrypIt or XorIt, it solely depends on BBS and the values you chose for it. You *don't* have a OTP. CryptIt/XorIt did not add anything to the security of this method, it's all in the BBS.
You are right again. XorIt just does xoring, the encryption strength depends on the key, here BBS.

@ Gopi
-The pad you are using has patterns - there's absolutely no question about that. You generated it using a 600 digit number. You have, _at_absolute_best_, about 2000 bits of key.
That’s right. BBS is cyclic and therefore the BBS-files have patterns. But it is easy to generate files with cycle length > 10^100. Confer to Monagan and Fee, cited before, for mathematical details. Key length is arbitrarily.
-and it seems fairly clear that you don't have a deep understanding of them.
Obviously.
-You say you want to use a system that you understand - yet you don't appear to know any way to determine the difference between your less than random pads and a truly random pad. If you don't understand that, then you don't understand how your system works.
Yes, I do not know any way to determine the difference between my BBS-files and truly random data, supposed I have got the files only. If you know a way, please, let me participate from your supreme knowledge.


HSOctober 2, 2005 4:43 PM

@Michael:
It may be impossible to distinguish a BBS generated file from a truly random one just by performing some test on it. But it's (at least theoretically) possibly to brute force a BBS generated file, i.e. trying all possible seed value until you get the key file. This is no longer comparable with a OTP, and it may even become practically possible if the implementation failed to use truly random seed values.

This is just like with a conventional cipher, though you have to find a way to compare the key lengths. And very likely it's *much* better than xoring with media or system files.

MichaelOctober 3, 2005 1:53 AM

@HS

"But it's (at least theoretically) possibly to brute force a BBS generated file, i.e. trying all possible seed value until you get the key file."

Very theoretically. Appropriate Generator Parameters choosen, of course.

The number of atoms in the universe is estimated to be below 10^80. The number of possible seeds is - in my BBS - above 10^600.

If nobody has access to my seed generation process, the seed has not to be random at all. If some side conditions are respected - they are in my BBS - the generated file will be unpredictable to the right and to the left and, regarding this aspect, undistinguishable from random. It will have no detectable pattern. There are patterns due to the fact that BBS is cyclic, but cycle length will be above 10^600.

But you are right, it is not true random and therefore not real OTP. The advantage is, I do neither have to exchange keys nor to store them.

For my purposes it suffices, as I suppose that anybody who has access to my generation process will have access to my otherwise stored key files as well.

joseOctober 21, 2005 1:18 PM

stop speaking stupids and use one real secure program , use datacloak from matthew bennet. XorIt is a good program just only if you use a good real ramdom file only.

joseOctober 21, 2005 1:28 PM

always bruce attack OTP because twofish was not select for AES why get out this class of blog .

joseOctober 21, 2005 1:33 PM

profanity ??? you killed this poor guy he just only post one small and nice program , just one real XOR program , if used whit one real ramdom file, and you know twofish is cracked ,why you are not really serious about this your time is end in cryptography

joseOctober 21, 2005 1:37 PM

anyway you are a nice guy Bruce , because twofish and blowfish were a good option not long time ago. But really I like the people use real security not algorithms that this poor people thinks are secure , but really is not....

Thanks and good bye

Jose's Little HelperOctober 22, 2005 1:42 AM

Bruce, I think you missed one before. Hope not because of the context.

[Posted by: Happy Bytes at September 29, 2005 06:50 AM]

blix coOctober 24, 2005 12:13 PM

So, this is what happens when pure ideology meets practical application.
The products that Andrew is selling are, it has been pointed out, useful for hiding things from your little sister. And maybe your wife, boss, co-workers, neighbors, divorce lawyers....
Will these programs and the "encryption" they use ever be successful against a concentrated attack by a class A math wizard and one very middling computer?
No.
Will most of us....not you guys, not the crypto guys, but most of us, the general public....will most of us be put under that microscope?
No.
So, for those of us who need a $10 program to hide things from our sister / wives / co-workers / accountants, these programs might be just the thing. For those of us who need a program that is more computationally terrifying to send a casual email to mom, then gpg or truecrypt or $any_crypto_package will do just fine. Really, it's all about understanding what level of scrutiny your files will stand up to. I've managed to go for 20 years working with and on systems in all manner of work (including government nonsense) and never once had to have my files stand up to a concentrated attack by a math geek. To that end, I consider myself lucky but average.
In short: I do not wear a bullet proof vest all the time, and it's not because I don't believe in the physics of small fast pieces of metal vs soft tissue. It's because I don't need that level of protection every second of every day.
All that being said, the marketing language on the website could be toned down to, say, not make any sort of claims about the "crypto" being used and instead concentrate on speed and ease of use, maybe? It is only as strong as the method used to store the key, and if you have a strong method for storing the key, then why aren't you using that for the files?

Bruce SchneierOctober 24, 2005 1:09 PM

"So, for those of us who need a $10 program to hide things from our sister / wives / co-workers / accountants, these programs might be just the thing."

Honestly, go to TuCows and you'll find a good dozen free programs that are also just the thing...unless you really need to spend the $10.

joseOctober 24, 2005 2:55 PM

What is happening whit you happybytes you are still occupated with Andrew Glynna xorit picture trying to decrypt it , remenber the header is always one common file structure but the rest of the picture, can be anything , so... you never will decrypt it darling, use datacloak encrypting twice or more times , yes twice or more , only makes your file free of hackers high or low skills.
And yes datacloak from mathew Benneth not Cloak (stegonography cracked program).
Well try to crack some with this happybytes or you are now because glynna' s picture UNHAPPYBYTES your new name jajajaja...

joseOctober 24, 2005 2:59 PM

Why you dont speak about cryptoanalisys of twofish from moriai...
Bruce , Im waiting for your answer Sir.
Is time to develop new algorithm right now or use datacloak with two or more passes, to real security. have a nice day.

joseOctober 24, 2005 3:02 PM

Im not trying to make advertising of this program ,( datacloak from mathew Benneth ) because the although is not free , it works ,always without restrictions , so , is free use anyway.
open your eyes boys

blix coOctober 24, 2005 3:52 PM

@Bruce Schneier
Indeed! There are many, many software titles, free and otherwise, which have cryptographically sound methods.
Sometimes, though, throwing $10 away is sort of ego engaging. Like lighting a cigar with a $100 bill. On a much smaller, more trailor-park scale.
Best bet would be to just donate the $10 to the eff, though, and grab a copy of something more capable. My post was more along the lines of: sometimes you don't need military grade munitions to swat flies.

joseOctober 24, 2005 9:27 PM

blix try datacloak by mathew bennett , is just a little hard to find one donwload page but if you want I can send a copy 293kb via mail. If you encrypt twice or more with this sofware one of your files are better than twofish ,blowfish... or inclusive pgp.

KRYPTOCHEF Detlef Granzow (persönlich)April 25, 2007 9:32 AM

KRYPTOCHEF Detlef Granzow (persönlich)!

Gerade habe ich erfahren per Telefon vom (Europäischen Gerichtshof für Menschenrechte) das eine Entscheidung in meiner Sache (GRANZOW gegen BRD) getroffen wurde.
In dieser Sache geht es um schwerste Menschenrechts Verletzungen gegen meine Person.

(schwere Folter-Mordversuch,
schwere Rechtsbeugung,
drei Jahre am Stück Einzelhaft ohne irgend etwas und ohne absehbares Ende und grundlos),
kompletter Eigentums Verlust und Diebstahl,
und Vernichtung von Beweismitteln)

2 Mio. Euro Schadensersatz werden von mir gefordert von der BRD.

Die Bundeskanzlerin der BRD:
Frau Merkel hat bis jetzt garnicht darauf reagiert.

Ich weiß das die BRD ein absoluter Verbrecherstaat ist, und die ganze Welt soll es wissen.

Bitte einige Tage warten...

Mit besonders freundlichen Grüßen
KRYPTOCHEF Detlef Granzow (persönlich)!

Vistasil gegen Pickel und FrickelApril 25, 2007 10:29 AM

Wie lautet denn nun das Urteil?
Und warum antwortest du nicht auf meinen Beitrag (unter dem von dir mit der Kaffeemaschine)?

Translation for those who don't speak German:

The amazing KRYPTOCHEF is back and says that the European Court for Human Rights (correct translation?) made a judgment in his case (he claims that the German government abducted and tortured him and destroyed his property, and is angry that chancellor Merkel doesn't answer his messages he posts to various blogs and forums)

He didn't give any more details, and we can guess why...

KRYPTOCHEF Detlef Granzow (persönlich)!April 26, 2007 10:37 PM

KRYPTOCHEF Detlef Granzow (personal)!

Straight ones I have experienced by telephone of
(European Court of Justice for human rights)
a decision in my thing
(GRANZOW against BRD)
was met.
In this thing it goes over heaviest of human right injuries against my person.

Heavy torture attempted murder,
heavy departure from the law,
three years at the piece of solitary confinement without something and without foreseeable end and groundlessly,
complete properties loss and theft,
and destruction of evidence two millions euro payment of damages demanded by me of the BRD.

The Bundeskanzlerin of the BRD:
Mrs. Merkel did not react up to now to it.

I that the BRD an absolute criminal state is white, and which is to know whole world it.

Please some days wait…

With particularly friendly greetings
KRYPTOCHEF Detlef Granzow (personal)!

Vistasil gegen Pickel und FrickelApril 27, 2007 1:55 PM

You think you are heavy on wire? There you are on the woodway! You have yes completely a bird!

Babelfish is proof that god doesn't exist :)

KRYPTOCHEF Detlef GranzowApril 20, 2008 10:40 AM

Spenden für KRYPTOCHEF Detlef Granzow (persönlich)!

Hiermit möchte ich dazu aufrufen eine Spende ab ca: 1 Euro an
KRYPTOCHEF Detlef Granzow zu spenden.
Auch andere Währungen sind herzlich willkommen.
Und 1 Euro macht niemanden wirklich ärmer.

Wenn die Gesamt Spenden Summe von 2 Mio. Euro gespendet wurde,
dann mache ich das aktuelle KRYPTO zu einer frei benutzbaren
und frei kopierbaren weltweiten Freeware KRYPTO Software.

Es liegt also vielleicht auch an ihnen ob KRYPTO Freeware wird.
Wenn ja, können auch KRYPTOCHEF Spender - KRYPTO kostenlos benutzen.

Ein Super Angebot von KRYPTOCHEF Detlef Granzow (persönlich)!

Meine KRYPTO Homepage:http://www.kryptochef.eu

KRYPTOCHEF Detlef Granzow - Spenden Bank Konto:

Name der Bank: Deutsche Bank
Bankleitzahl der Bank: 10070024
Name des Kontoinhaber: Detlef Granzow
KRYPTOCHEF Spenden Konto Nr.: 2475341 00
IBAN: DE83 100 700 240 2475341 00
BIC: DEUT DE DBBER
Verwendungszweck: KRYPTOCHEF Spende (Bitte unbedingt angeben!)

Vielen Dank für ihre Spenden !
Illegale Verwendung meiner Bank Daten werden privat und strafrechtlich verfolgt.

Spenden für KRYPTOCHEF Detlef Granzow (persönlich)!


Donations for KRYPTOCHEF Detlef Granzow (in Person)!

Hereby I would like to encourage a donation from ca: 1 Euro
KRYPTOCHEF to Detlef Granzow to donate.
Other currencies are welcome. And 1 Euro does not really poorer.

If the total sum donation of 2 million Euro has been donated,
then I do the current KRYPTO to a freely usable and global
free copy freeware KRYPTO Software.

So it is perhaps up to them whether KRYPTO freeware.
If so, can also KRYPTOCHEF donor KRYPTO free.

A Super Job from KRYPTOCHEF Detlef Granzow (in Person)!

My KRYPTO Homepage:http://www.kryptochef.eu

KRYPTOCHEF Detlef Granzow - Donations Bank account:

Bank Name: Deutsche Bank
Bank number of the Bank: 10070024
Name of the Bank account holder: Detlef Granzow
KRYPTOCHEF donations Bank account number: 2475341 00
IBAN: DE83 100 700 240 2475341 00
BIC: DEUT DE DBBER
Purpose: KRYPTOCHEF donation (Please now!)

Thank you for your donations !

Illegal use of my Bank Data are private and prosecuted.

Donations for KRYPTOCHEF Detlef Granzow (in Person)!

AnonymousApril 24, 2008 2:49 PM

that guy seems like a damn retard. Furthurmore im more confused than ever about CCF files types. found a item i wanted to dl. Clicked dl as a ccf thinkin i had the software for it but appearently not. Then i went lookin 4 the damn stuff and stumpled upon here. And im still no "clearer" as to how the hell to "dl as a CCF".

Gee i sure miss the good ol days of FTP. Where actually knowing the REAL info= access and anything else= denied, Then banned.

AnonymousApril 24, 2008 3:00 PM

Askin 4 what is like 6 million dollars is:

A: STUPID
B: RETARDED
C: if you got smashed once....why do u want us to give people a paper trail to follow? So we can get smashed too?
D: If you need that $$ Y NOT make the SOFTWARE for FREE, PERIOD? Ud be amazed how many people OFFER donations for FREEWARE/SHAREWARE.

And Kyrptochef.... How about u send me 1/2 a euro for every 1 that some fool donates? Cause im pretty damn poor. 26 and gainfully unemployed for 2 years.

KRYPTOCHEF Detlef Granzow (persönlich)!April 26, 2008 6:55 AM

KRYPTOCHEF Detlef Granzow (persönlich)!

Anonymous kann KRYPTO nicht unberechtigt entschlüsseln und der Rest der gesamten Welt kann es auch nicht.

Ansonsten ist Anonymous zu feige seinen Namen zu nennen,
weil er Angst hat mich zu treffen.

Anonymous über dich lacht die ganze Welt.

KRYPTOCHEF Newsletter auf
http://www.kryptochef.eu

KRYPTOCHEF Detlef Granzow (persönlich)!
--- English Version ---
KRYPTOCHEF Detlef Granzow (personal)!

Anonymous KRYPTO can not unreasonable decipher and the rest of the world as a whole, it can not.

Otherwise, Anonymous Feige to its name;
because it scared me.

Anonymous Register of laughs the whole world.

KRYPTOCHEF newsletter in
http://www.kryptochef.eu

KRYPTOCHEF Detlef Granzow (personal)!

Comments on this entry have been closed.

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc..