response 7 of 55:

Apr 14 09:35 UTC 2000

#0 is bullshit.  There is no encryption method that results in the same
size of 'plaintext' and 'cyphertext' being the same size that is not
ultimately 'substitutionary' and thus breakable. I challenge the author
to release his/her method for peer review.

response 9 of 55:

Apr 14 10:38 UTC 2000

Re resp:5 - "...encrypted data should be uncompressable."

I don't think that's true, at least not without further conditions.
Suppose you start with plaintext A and from it produce encrypted text B
by some method.  Then you could replicate B a few times to produce, say,
BBBBB.  The new text is just as well encrypted as B but is obviously
compressable (to B).

response 19 of 55:

Apr 15 03:42 UTC 2000

  (jp2 meant input not output in line 69)

response 21 of 55:

Apr 16 05:49 UTC 2000

In any event, #15 is *not* OTP, because it's using a pseudo-random #
generator, not a true random source.  In fact, it's not even
particularly secure, because random (and its variants) are so easy to
analyze.

If you want something stronger to implement, try RC4.  The algorithm
used in RC4 is actually a lot simpler than random(), yet has real
cryptographic strength, runs fast, and can interoperate with other
people's code.
        typedef struct rc4_key_schedule {
                unsigned char state[256],x,y;
        } rc4_key_schedule;
        rc4_set_key(ks,len,key,rekey) rc4_key_schedule *ks;
        unsigned char *key;
        {
                register unsigned char t,x,y,z;
                if (!rekey)
                {
                        x=0; do ks->state[x]=x; while (++x);
                        ks->x=ks->y=0;
                }
                x=y=z=0;
                do {
                        t=ks->state[x];
                        y+=key[z]+t;
                        if(++z==len)z=0;
                        ks->state[x]=ks->state[y];
                        ks->state[y]=t;
                } while (++x);
        }
        rc4(ks,len,ip,op) rc4_key_schedule*ks;unsigned char *ip,*op;
        {
                register unsigned char x=ks->x,y=ks->y,t,u;
                int i=-len;
                for(;;) {
                        y+=t=ks->state[++x];
                        u=ks->state[y];
                        ks->state[x]=u; ks->state[y]=t;
                        t+=u;
                        *op++=*ip++^ks->state[t];
                        if (!++i) break;
                }
                ks->x=x; ks->y=y;
        }
(* note, "rc4" is a trademark of RSA.  FWIW).
The above can be used either to encrypt or as a random # generator.  To
make random numbers, given an all 0's buffer to rc4.  To add additional
entropy to existing state, call rc4_set_key with rekey !=0.

response 23 of 55:

Apr 17 04:10 UTC 2000

If you look very carefully, you'll see that there is a one line XOR and
the rest of the code in #21 is merely concerned with generating a random
# stream.  The difference is that (a) the logic to generate the random #
stream is smaller than the logic in random(), and (b) there is no known
good attack to capture the algorithm state given the output, ie, it's
"cryptographically" secure.  Note also with random(), you have no
guarantee that it's implemented the same way on different architectures
of machines; indeed, when you start considering environments such as the
Macintosh, Windows, VMS, MVS, etc., it's very possible some or most of
these either don't offer random(), or offer a random that works
differently than the bsd version.  Indeed, even going between gnu & bsd
things could be different.

response 25 of 55:

Apr 17 20:34 UTC 2000

Oh yes, there's another interesting feature about the program in #15.
In order to generate the key, the program calls "srandom(getpid())".
Under many versions of Unix, getpid() returns a small integer, typically
less than 30,000.
        (Under some environments, getpid is even less random than that;
        under AIX, the pid contains the process slot plus a 8bit
        uniquifier; this means a program that forks & exits will reuse
        the same pid after 256 forks.  Under MS windows or the
        macintosh, getpid, if it exists at all, may return a constant.)
A number less than 30,000 is basically equivalent to more than 15 bits
of key; this means not only is brute force an easy way to break this
algorithm, but simple table look might just just suffice.  In some
cases, there may be no more than 8 bits, or even no bits of entropy in
the key.  Besides macintosh & windows, another "0 bit entropy" case is
the case of a program run at boot time - the PID will be the same on
every boot for applications started at boot time, so effectively the PID
is a constant.

Unfortunately, generating random numbers is a common need in
cryptographic applications, and failure to get enough bits of entropy is
one of the common mistakes made.  Using strong encryption is not
sufficient to ensure security, and this is a wonderful example of that
problem.

response 27 of 55:

Apr 17 21:40 UTC 2000

That's also pretty common -- usually people say "time(0)^getpid()" which
avoids a core dump problem & uses a less expensive operation to mash the
bits together.  Sure it's better, but it's not much better, certainly
not against even a moderately determined opponent.

Key generation & distribution are some of the easiest things to botch in
a cryptographic module.  Everyone likes to spend time poking at the
cryptographic algorithm - there are thousands of papers analyzing
variations of random() alone for any signs of cryptographic strength.
Comparitively little attention is spent on dealing with entropy, and
even with key distribution, there is usually a certain amount of hand
waiving & faith involved in the process.  When people break security
products, it's almost never through the cryptographic algorithm (no
matter how weak), but through some other means instead - and these are
the areas that are most often vulnerable.  Cryptoanalysts know this and
use it to their advantage - it's simply easier to attack something in
the places the designers overlooked and skimped.

response 29 of 55:

Apr 20 21:57 UTC 2000

 
The Pretense At Documentation For Mr.Jima
 
"Mr.Jima says Hai"
 
commandline format:
you must precede all commandline parameters with either a forward slash
or a dash , or they are ignored. there is absolutely NO seperator expected,
so if you type -I:in_file.txt then the program will search for a file that
is called ":in_file.txt" which you probably don't have. this no-seperator
feature is just so i can eliminate total keypresses to execution. the valid
form of the last example would be
 
-Iin_file.txt
or
/iin_file.txt
 
notice how i changed the case of the "I" parameter, i will get to that
later on.
 
to run:
for the first time, you need to get the metakey from the program. to create
and get a metakey, just run the program with the commandline parameter !.
you will see a screen full of legal mumbojumbo that i hope covers my ass in
any official business legal mumbojumbo sense, and near the bottom will be
the word <metakey> and a number. that number is the metakey you need to run
the program from that point on. the metakey won't change after a normal
execution if you are using a version later than 1.01 , that means you can
keep using the same metakey over and over again after you've retrieved it
once. every time you run the program with /!, however, the metakey changes.
 
here is a screen dump of the various help screens available by running the
program with /? or /1 parameters, and some details on each parameter will
follow.
 
 
Mr.Jima - - help screen of available switches. /? 
 
--<metakey>    you must run this for encryption routine to operate; 
/I<filename>   and this for name of the infile to be en- or de-crypted; 
/O<filename>   and this for name of the outfile made by en- or de-cryption; 
/F<filename>   and this for name of the keyfile used by en- or de-cryption, 
/0<filename>   or this, same as /F but also performs null-byte checking, 
/K<character>  or this as a typed key to be used, must be 1 to 80 chars; 
/E             and this to encrypt infile, overwrite/create outfile, 
/D             or this to decrypt infile, overwrite/create outfile. 
 
/#<number>     create file of 1 to 2,147,483,640 bytes of random content. 
               use before /0 or /F switch to open created file as key. 
               file is always named "jima.key", will overwrite if exist. 
/P<number>     execute from 1 to 65,535 passes of en- or de-cryption. 
/X             overwrite keyfile and infile with nulls after processing. 
/x<filename>   write <filename> with nulls, cannot be keyfile or infile. 
/1             display help screen of all data requirements. 
/!             display legal disclaimer and current <metakey>. 
 
 
remember that all forward slashes "/" may be replaced with dashes "-".
also remember there's no ":" or anything between the parameter switch and
 the parameter data. no -I:infile, just -Iinfile
the first block list of switches are the switches required for execution of
mr.jima's encryption or decryption schemes. you need all of the following:
 
an infile, designated like this:    -Iplain.txt
an outfile, like this:              -Oplain.enc
either a keyfile, like so:          -Fkey.gif
   or a keyline, like this:         -Kfo0bar242
   or a keyfile, with 0 check:      -0key.gif
and then a command, either          -D
   to decrypt, or                   -E
   to encrypt. if you are familiar
   with the process used for en and
   decryption, you know these two
   switches don't require anything of
   the file to be operated on besides
   that it has to exist. that means that running the decrypt process on a
   fresh file will potentially encrypt it just as much as if you had told
   mr.jima to encrypt it.
 
oh yes and finally                  -*<metakey>
 
and you know how to get the <metakey> already. we'll say it's 242, decimal.
 
                                    -*242
 
so your commandline looks like this :
 
mrjima -oplain.enc -E /fkey.gif -*242 /iplain.txt
 
this will encrypt plain.txt with key.gif making a file called plain.enc.
 
about the upper and lower case...
 
if you use an upper-case letter for /I , /F , or /O , then while the program
is running the filenames will be displayed when they are first opened. if
you use lowercase letters, the filenames will be replaced with "<no-no>" or
something like that, i forget.
 
let's look at the second block of parameters again:
 
/#<number>     create file of 1 to 2,147,483,640 bytes of random content.
               use before /0 or /F switch to open created file as key. 
               file is always named "jima.key", will overwrite if exist. 
/P<number>     execute from 1 to 65,535 passes of en- or de-cryption. 
/X             overwrite keyfile and infile with nulls after processing. 
/x<filename>   write <filename> with nulls, cannot be keyfile or infile. 
/1             display help screen of all data requirements. 
/!             display legal disclaimer and current <metakey>. 
 
the parameter -# is poorly documented, it doesn't really let you make a
2.145 gig random-content file, it only lets you make up to 2gig exactly.
something i changed but forgot to document.
 
-#5840  makes a file of 5,840 random bytes using that remarkably un-random
        algorhythm presented by pascal (and basic) but seeded with your
        system timer so it is relatively random. i have a bit of ASM code
        downloaded from an AI database that purports to create the closest
        thing to random numbers you can get with a PC, which will be used
        in future versions.
 
-P5     runs the encryption process using a particular number of passes.
        (passes, by default are set to one.)
 
-X      paranoid? use this switch to overwrite the keyfile and infile with
        00h and then set their length to 0 bytes, after the encryption or
        decryption process. you can also use this,
-x      lowercase x, with a filename of any file to just overwrite and set
        to 0 length on the fly.
-xdamn.fil
        running -x requires nothing special like using a metakey or
        providing other filenames or commands, so it can be used by itself
        at any time. if it appears anywhere in the commandline like so...
 
mrjima /Iplain.enc -E /xplain.txt /Fkey.gif -*242 /Oplain.enc
                      ^^^^^^^^^^^
        it will be executed as soon as it is encountered during commandline
        parsing. except for in the above example; the filename used has
        already been reserved by the /I switch as the InFile.
        -x can be run multiple times on the same one line.
 
-0      this is the alternative to using /F for designating a keyfile. when
        you use this, the filename used is expected as the keyfile so the
        same rules above apply when also using /x.
        what -0 does is run through the file checking for bytes of 00h.
        the 00h bytes doesn't cause anything to happen to a byte of infile,
        and that is what you want to avoid unless you're using multiple keys
        or passes, and the passes thing only if the files vary in length,
        and even then you can't be too sure.
        like /x, this will run as soon as it is encountered on the command
        line, and requires nothing else to run. it too can be run multiple
        times on the same line.
 
now on to the second screen , the one you get with /1 :
 
 
Mr.Jima - - help screen of all data requirements. /1 
 
Mr.Jima cannot work properly unless all requirements are met. all options 
must be preceded by either a slash / or dash -. all option <data> is 
case-sensitive where it is applicable. order in which options appear on 
commandline is order in which they will be executed. encryption routine is 
not run until entire commandline is parsed. later switch <data> is precedent 
over earlier <data>. switches /0 /# /x operate upon being encountered. 
routine will not run unless option --<metakey> is used; <metakey> is found 
only through using /! option. switches /O /I are also required and infile 
must exist in working directory. also, one of /K /F or /0 are required. 
if using /0 or /F, keyfile must exist in working directory. finally, one of 
/D or /E are required for command directive. 
/0 replaces /F but the /0 null-byte scanning can be run on any existing file 
without any other requirements being met. also, /# /x can be run without any 
requirements being met.
/X runs after en- or de-cryption is finished. 
for /I /O /F, uppercase makes <filename> visible, lowercase will hide it. 
a final requirement is that there is no similar filename between any pair 
of infile, keyfile, and outfile. 
 
 
this is an attempt by mr.jima to say everything i just said above but in one
screen only. actually it's an attempt by me, but i prefer to pass all
responsibilities onto mr.jima himself, which is apparent to you when you
view this screen using the /! parameter:
 
 
By running Mr.Jima, you accept legal responsibility for having read,
understood, and accepted the terms of this legal disclaimer.
These are the terms: The Author, Gabriel "Eyenot" Petrie, accepts
no legal responsibility for any effect this application, "Mr.Jima",
may have on your computer or its files. The Author accepts no legal
responsibility for the safety or security of the encryption that this
application may provide. The Author accepts no legal responsibility
for the state of this application as it is when you receive, or when
you run it, or what the effects of the state of the application may be
on your computer or its files. The Author accepts no responsibility
for the effects of this application or its use on any aspect of your
life, whether in business practices or in any other situation.
The Author accepts no responsibility for the presence of application
on your computer or in computer memory. The Author accepts no legal
responsibility for any charges or costs this program may have waged
or debted you, and The Author distributes this program only as
"Freeware", meaning The Author does not charge for ownership of the
application by any party.  <Metakey>: 360
   "Mr.Jima", "mrjima.exe" (c) 4-14-2000 Gabriel "Eyenot" Petrie,
   ALL RIGHTS RESERVED, portions (c) 1983, 92 Borland International, Inc.
 
 
and there you have it.
- eyenot