|
Grex > Cyberpunk > #129: Powerful new encryption designed by Eyenot - Mr.Jima Encryption |  |
|
| Author |
Message |
eyenot
|
|
Powerful new encryption designed by Eyenot - Mr.Jima Encryption
| 
Apr 12 22:05 UTC 2000 |
Mr.Jima v 1.0 (c) 4-13-2000 by Gabriel "Eyenot" Petrie
portions (c) 1983, 92 by Borland International, Inc.
classes : freeware + utility
shortdesc: encryption
filename : mrjima.exe
included : mrjima.doc
file size: 13k bytes
platform : MS-DOS
requires : disk file space of at least 14k bytes free
3 free file handles
286 or better processor
keyboard or other line-input device
descript : encryption / decryption of any size file into file of same size,
using a key file of any size smaller than 2.147 gigabytes.
all relevant documentation is stored inside executable, just run
the file by itself to read opening documentation.
cost : free from author
register : no registration required, no crippleware involved.
e-mail : eyenot@cyberspace.org
IRC : yes. mostly EFNet and UnderNet.
future : next version will include multiple passes on file in one session
"Mr.Jima Documentation" (c) 4-13-2000 by Gabriel "Eyenot" Petrie
FYI: Mr.Jima is NOT "Replacement Encryption", "XOR", "Bit-Shift", or
random/psuedo-random algorhythm Encryption.
The process I coded into Mr.Jima is capable of encrypting a file into deeper
and deeper layers, each one further from the original file. Just encrypt
the already encrypted file again, naming itself as the output file.
If you change keys between layers, encryption will be more effective BUT
you will need to keep track of which keys you used on which layers, because
you have to be able to decrypt the file again with each key for each layer
in reverse order.
Two teaser files are included in the first distribution. These files have
been encrypted to 1 level, using one key for each of them. If you find these
two files easy to crack, try again after you've used Mr.Jima to encrypt them
to 2 or 3 layers using different keys. Experiment: use graphic, command,
archive, or even text files as your keys.
Any file can be encrypted, and the maximum size of the file is unlimited.
The encrypted file is always the same size as its unencrypted original.
The key itself however must be smaller than 2.147 gigabytes in size .
Distribution Archives are available from the following webpage sites:
www.cyberspace.org/~eyenot
www.lunarsurf.com/~eyenot
The file is freeware, if you like it please distribute it. Send any comment
to eyenot@cyberspace.org
-eyenot
|
| 55 responses total. |
raven
|
|
response 1 of 55:
|
Apr 12 23:44 UTC 2000 |
Linked to cyberpunk. Join cyberpunk at the next Ok: prompt to discuss
computer security, hacking, cracking,etc and it's effects on society.
|
raven
|
|
response 2 of 55:
|
Apr 12 23:46 UTC 2000 |
Doh already cross posted in cyberpunk... :-(
|
jp2
|
|
response 3 of 55:
|
Apr 13 04:33 UTC 2000 |
This response has been erased.
|
mdw
|
|
response 4 of 55:
|
Apr 13 05:31 UTC 2000 |
It's hard to say without source (and I don't feel like disassembling the
object although that would be easy enough) - but at a very cursory
glance it doesn't look very secure. A simple character frequency count
shows the character with octal code 350 appears 7 times in secret.enc
Just for the sake of comparison, I encrypted the last paragraph (280
characters) using idea & rc4, with the key "foobar". With idea, the
most common character, octal 375, appeared 4 times, and 7 other
characters appeared three times. With rc4, the most common character
was %, 4 times, & 4 other characters appeared 4 times. secret.enc is
actually smaller (only 212 characters) so I would not expect to see 350
7 times, # 5 times, * 4 times, and 7 other characters 3 times.
Not all good random numbers are of cryptographic strength, but good
cryptographic routines should (in general) be good random number
generators. For the output from a cryptographic routine not to be
statistically random suggests that there is a pattern, and of course,
patterns are what a cryptoanalyst would look for and use to break the
algorithm.
The strings inside the binary say it uses "byte rotation". That by
itself is certainly not at all sufficient (although certain modern
algorithms, including rc6 and mars do indeed use variable rotation of
words as a small *part* of their algorithm.)
|
jp2
|
|
response 5 of 55:
|
Apr 13 15:33 UTC 2000 |
This response has been erased.
|
gull
|
|
response 6 of 55:
|
Apr 13 16:31 UTC 2000 |
Encryption is one of those things that *looks* easy to people who only know a
little about it. The more you know, the tougher the problem looks. That's
why there are so many bad encryption algorithms out there, some of them in
commercial software.
|
bdh3
|
|
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.
|
darkskyz
|
|
response 8 of 55:
|
Apr 14 10:33 UTC 2000 |
my guess is that this works simply by rotating each char in the plaintext x
times, where x is the char in the same place in the key file.
|
remmers
|
|
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).
|
mdw
|
|
response 10 of 55:
|
Apr 14 16:01 UTC 2000 |
There are lots of even trivial transposition algorithms that would
prserve the length. Even with a block algorithm, cbc with cipher text
stealing will preserve the length as long as it's > than the block size.
There are also pure substitition ciphers that are "impossible" to break;
OTP is the classical example.
It's clearly possible to design encryption algorithms that are
compressible. Generally, the reason people do that is for transport
reasons, such ascii encoding. There is generally a trivial transform
that reduces this form to a non-compressible "perfectly" random form of
data. The other case I can think of that might do this is some of the
various public key encryption algorithms, which use prime numbers - the
data there may not be perfectly random statistically speaking, but the
differences may be either trivial (primes are odd) or not particularly
useful (there are more 512 bit primes less than 3*2^128 than between
that & 2^512.)
|
jp2
|
|
response 11 of 55:
|
Apr 14 18:09 UTC 2000 |
This response has been erased.
|
scott
|
|
response 12 of 55:
|
Apr 14 18:24 UTC 2000 |
I'd think that encryption would be even better if the output resembled
something totally unrelated.
|
jp2
|
|
response 13 of 55:
|
Apr 14 18:26 UTC 2000 |
This response has been erased.
|
gull
|
|
response 14 of 55:
|
Apr 14 20:43 UTC 2000 |
Re #12: That's called (I think) steganography. It's used when you have
encrypted data that you don't want to *look* like encrypted data. A common
example is embedding the encrypted message in a GIF file. Done right, it'll
look like random "noise" -- maybe the result of a low-quality scan.
|
jp2
|
|
response 15 of 55:
|
Apr 14 21:54 UTC 2000 |
This response has been erased.
|
mdw
|
|
response 16 of 55:
|
Apr 14 22:39 UTC 2000 |
69
The output from "random" is not of cryptographic strength and is in fact
easy to break. This is *the* obvious program every wannabe
cryptographer writes first off; there are also a large number of papers
analyzing why it's bad and breaking all sorts of "improvements".
|
jp2
|
|
response 17 of 55:
|
Apr 14 22:45 UTC 2000 |
This response has been erased.
|
jp2
|
|
response 18 of 55:
|
Apr 15 01:04 UTC 2000 |
This response has been erased.
|
bdh3
|
|
response 19 of 55:
|
Apr 15 03:42 UTC 2000 |
(jp2 meant input not output in line 69)
|
jp2
|
|
response 20 of 55:
|
Apr 15 06:43 UTC 2000 |
This response has been erased.
|
mdw
|
|
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.
|
jp2
|
|
response 22 of 55:
|
Apr 16 14:50 UTC 2000 |
This response has been erased.
|
mdw
|
|
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.
|
bdh3
|
|
response 24 of 55:
|
Apr 17 04:44 UTC 2000 |
I seem to recall an old C compiler where random() simply returned the
value of the refresh register of the Z80 processor.
|