I had this idea some time ago during a crypto course in my company. We
discussed lots of algorithms and for almost every kind of algorithm there's
just one problem: time. What I want to say is: no matter how good an
algorithm might be, almost all of the more complex ideas about encryption
lead to short keys, the messages are mostly bigger. This makes it easy
to attack the key by analysing symmetrics in a message or other methods
for getting the key or sometimes even the handling (if the attacker don't
know anything about the crypto algorithm). In these cases it's a matter
of time to break the key. But with better computers, CPUs and even
specific hardware you can save a lot of time and maybe even break the
key during some days/hours or even minutes.
In this course there was also a discussion about the XOR method for
crypting data. XOR means: you code byte 1 with byte 2. If you
code the resulting byte 3 again with byte 2 you'll get byte 1 back.
Extremely simple and symmetrical. No public/private key-pair, nothing
asymmetric and therefore very fast. But also extremly safe if the key is
as long as the message. If this is the case you can either try to attack
the key or the message. Maybe the key is too simple ? This brought us to the
idea: how safe a key must/can be ? It should be best to have a total random
key, maybe compressed data e.g. a gzip/bzip file.
|Attacks and solutions:||
Now it's interesting, we might come to a point where it could be easier
to attack the message by brute force instead of attacking the key. You
can say: Hey, the head of the key can be detect maybe a as gzip file !
And that's the point where I put an offset option in my program.
The idea now is: create a CD with just a long file (e.g. noise from a
TV card or noise from shortwave audio etc.) and burn it twice.
Give one CD to a friend and tell him the starting offset. From now on
you can talk extremely safe with each other. For every message you
take the next bytes on the CD etc. until every byte on the CD has been
used. Try to not use key CDs twice (don't start from the beginning of
the CD) but if you're not that paranoid this shouldn't be such a big
problem. And however, one CD should be enough for lots of text messages
but even enough for big binary data.
This is the last "stable" version. You
can find the CVS Repository
here. At this time the versions are equal though...
As tgz-Source: crypt-xor_2.1-2.tar.gz
Sorry, no apt-Directory at this time. Oliver Kurth, which is the maintainer of Masqmail had been hosting it but sadly his domain masqmail.cx has been gone.
Anyway, thanx to him, because he was the one doing the original Debian package for this tool and I hope I did everything right because for this version I tried to use his skeleton to create the debian package. I'm not very familiar with building Debian packages, I just know, how to install them. :)
But why this update? It's obvious that the tool itself hasn't been changed. It's because I used stdio for I/O and normally they use 32 Bit Integers. Which means: only 2 GB maximum filesize. That's bad so I changed the compile-process and added these gcc-options:
With these options the whole process is largefile-safe.
First version of the Debian package:
The sources belonging to that package: crypt-xor_2.1-1.tar.gz
Nevertheless, newer versions will be found here.
The reason for this is: at this time only some few people using it
with linux systems. But I'd like to have even ports for other systems
(*BSD, Solaris, even Windows systems) and I think this is the bigger
forum to get some people working with me on this small piece of software.
Another point is, of course, to have more add-ons, tools and maybe
graphical interfaces. That's where I'd like to go. Will someone go with
me? Just email me to also
work on this project. What you can gain ? Sorry, no money, but lots of
This project is friendly supported by:
(last changed: 2006-02-28)