|
|
|
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.
Linked to cyberpunk. Join cyberpunk at the next Ok: prompt to discuss computer security, hacking, cracking,etc and it's effects on society.
Doh already cross posted in cyberpunk... :-(
This response has been erased.
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.)
This response has been erased.
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.
#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.
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.
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).
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.)
This response has been erased.
I'd think that encryption would be even better if the output resembled something totally unrelated.
This response has been erased.
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.
This response has been erased.
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".
This response has been erased.
This response has been erased.
(jp2 meant input not output in line 69)
This response has been erased.
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.
This response has been erased.
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.
I seem to recall an old C compiler where random() simply returned the value of the refresh register of the Z80 processor.
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.
This response has been erased.
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.
Mr.Jima 05h (c) 4-14-2000 by Gabriel "Eyenot" Petrie
portions (c) 1983, 92 by Borland International, Inc.
classes : freeware + utility
shortdesc: encryption to garbage and back again with key
filename : mrjima.exe
included : mrjima.doc
file size: 22k bytes
platform : MS-DOS
requires : disk file space of at least 22k bytes free
4 free file handles
286 or better processor
keyboard or other line-input device
descript : encryption / decryption of any file at all into file of same
size, using any file at all as a key file. all files processed
must be shorter than 2 gigabytes in length. all relevant
documentation is stored inside executable, just run the file
without commandline to read. file is technically "garbage"
without the key. other strange features included.
cost : free from author
register : no registration required, no crippleware involved.
e-mail : eyenot@cyberspace.org
IRC : yes. mostly EFNet and UnderNet.
"Mr.Jima 05h Documentation" (c) 4-14-2000 by Gabriel "Eyenot" Petrie
All Rights Reserved
Changes 04h - 05h :
NOTICE : using the file-nulling feature might create lost chains on your
dr
This is alot of released versions for two days, but that's alright. I
don't expect anybody to have or to ever download them all.
Now the /# generated file must be below _exactly_ 2 gigabytes. That's
2,000,000,000 or on the commandline /#2000000000 . If you request more,
it will tell you bug off and only make a 2 gig file.
Now both /# and /P will check for your commandline input and if there is
an illegal character in there, such as -P5b, then it will tell you about
it and not accept that data.
All options requiring files now have proper filechecking and, since I
want later data to precede earlier data, all procedures now handle each
other's data based on who went first. If you ask for a keyfile earlier
in the commandline and then you ask for a different one later in the
line, and the second time you ask the file doesn't exist, it will tell
you all about it and go back to using the first keyfile you asked for
as the keyfile for encryption.
Now the screen output is in a debugging sort of style, with each line
of screen output preceded by the option that caused it to generate.
Lots of error checking and screen output added. Much bigger .EXE, too.
No other new features, really. This is a pretty complete release.
I was thinking about the required metakey, and truth is, if I only made
you use the metakey once on a file ever, and then you didn't have to use
it ever again, you might receive a copy of the file that has already been
keyed, and you might not read the legal screen. I need you to read the
legal screen if you are going to use this for any serious purposes, but
I want the program to be easy to use, so that is why I compensate and
only require you to check for the key once using /! , and afterwards you
can use that same metakey over and over again with that file.
[ prior changes omitted ]
Two teaser files are included with each distribution. The first
distribution should have been easy for anybody, and if you can find a copy
of it out there, it still stands that nobody has solved either teaser.
However, I gave away the answer to the SENTENCE.ENC file, which is this:
"All Around The Mulberries."
(sans quotes)
Somebody suggested it was the alphabet due to its being 26 characters long.
HAHA! Fooled YOU!
The rest of the teaser files including the ones released with v1.01 which
are the same as the ones for 03h are still unbroken and unspoken. I used
some pretty hairy keyfiles on v1.01's SECRET.ENC, so i dunno if you will
be able to sort out its entire history.
Distribution Archives are available from the following webpage sites:
www.lunarsurf.com/~eyenot
The file is freeware, if you like it please distribute it. Send any comment
to eyenot@cyberspace.org
-eyenot
[ More Stuff From Later In Time ]
for the sake of display in bbs i shortened this file. i thought that since
the commandline procedures are getting a little crazy, i should also
include some pretense of documentation. also, this guy i gave a copy to on
the bus can't make heads or tails of how to operate the program, so there's
another reason why pretense at documentation is in order, sort of.
okay - as far as the code goes, i won't be releasing it until i have made
an ASM of the program which could take me awhile (i am still just reading
the ASM book and haven't coded one thing yet.) as long as this is still in
Boring Turtle Power source code i'll be too ashamed to release the actual
thing.
but i'm not above giving away "big secrets". here's two things to help you:
(1) the value used for Metakey is written to the end of the executable
every time you run the program with the "!" switch. This changes the file
size by 1 byte, so you will know a distro that has been run once before and
possibly re-packed with differing contents, from one that came unopened
from the gift store. i'm not against you hacking your own version of the
program or making a crack that keeps the program from changing the last
byte of the file, but as i've said in the "!" screen, i have nothing to do
with what state the program is in when it reaches you. anyways, if the byte
checked for metakey (last byte of file at any length) is 00h , as it is
when the file has been untouched and unexecuted with "!", that doesn't
matter because 0 is an illegal value for the metakey.
(2) here is the basic scheme of things
InFile is the file to either be en-crypted or de-crypted, any file
KeyFile is any file used as a key
OutFile is the result after either en-cryption or de-cryption
procedure "crypto":
Open InFile for input
Open KeyFile for input
Open OutFile for output
Clear Pass_At to 0d
loop until EO_InFile_Chk AND EO_KeyFile_Chk AND (Pass_At=Pass_Goal) :
Read In_Byte from InFile
Read Key_Byte from KeyFile
Clear Work_Word to 00h,00h
If Procedure is to Encrypt, then ...
Add In_Byte to Work_Word
If Procedure is to Decrypt, then ...
Add 256d to Work_Word
Add In_Byte to Work_Word
Decrement Work_Word by Key_Byte
If Work_Word is more-than 255d then ...
Decrement Work_Word by 256d
Clear Out_Byte to 00h
Add Work_Word to Out_Byte
Write Out_Byte to OutFile
If EOF(InFile) then ...
Reset(InFile)
EO_InFile_Chk = TRUE
If EOF(KeyFile) then ...
Reset(KeyFile)
EO_KeyFile_Chk = TRUE
Increment Pass_At by 1d
end loop
Close(All them files)
end procedure "crypto"
what do you get ? you tell me, take a textfile of say 2048 bytes and
encrypt with a .gif of about 16k as a key, using 3 passes.
do you like the result?
try to decrypt using the same key first with 2 passes, then decrypt
the result with another 1 pass.
you don't get back the result you got before encrypting with 3 passes.
this isn't a sure shot, i didn't code it thinking "this is unbreakable"
and i don't say it's unbreakable. as far as i can see, the resulting
"encrypted" file is total garbage. if somebody can manage to break one
of the distributed teasers, tell me about it and how you did it because
i'm curious as to the weak points of this system.
that pretense at documentation i mentioned will be in the next file.
?
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
>oh yeah > >in the last file, for documentation, i kept saying -*<metakey> was the proper >switch which is all wrong... it's -- (same thing as /-) which is easier to >type than -* or /* . >--<metakey> remember that > >as for other stuff, i didn't think i would get any feedback at all let alone >what was it, 27 responses ? thanks for the response. on IRC, which is to be >expected, i only get stuff like "what color r u panty" and "are you smoking >pot now" etc. > >so much for instant chat being the perfect medium for discussion. :( >which bums me out. i always used to marvel at BBS chats on multi-line systems. >i mean, you can get so much done so quickly ! no more sending response, >waiting for it to save to disk, waiting for somebody to login and read and >reply, etc, etc. just instant communication. thing is, people just use it >to elicit sex and drugs and to attempt typing out industrial lyrics in a way >that is supposed to affect actually listening to the music >(i'm guilty, i often break into lyrics from Tyranny For You) > >hmm. about the "encryption". well, here's the big thing. people want an >encryption that, no matter what file you get, the outcome is a truly >encrpted file. thing is, i'm not so energetic to take care of all that for >anybody. if you want real encryption, use a real brain. encrypte a file >using a different-sized and different-type of file, say a text with a .gif >or .mod, and use multiple passes. use two keys! etc. > >this way, stupid people will encrypt entire files with one byte of 01h, >and smarter people will still reign over stupid sorry about the > stuff, i got suddenly disconnected. anyways, be smart with your encryption and as far as i can see, using mr.jima with variety of keys and passes will be safe and secure. but don't count on it, please try to crack the teasers. the latest distro, version 05h, is available here now. lynx to www.grex.org/~eyenot/jima.html and it should be there.
The pseudo-code in #28 doesn't entirely make sense to me. My best interpretation is if "Procedure is to Encrypt" is true, then "Out_Byte" will be set to exactly what In_Byte is, and Key_Byte isn't used at all. If "Procedure is to Decrypt" is true, then out_byte appears to be the difference between in_byte & key_byte, which at least makes more sense. It's not entirely clear to me what "pass_at" is used for, but perhaps the intent is to make multiple passes over the data file & only write the results out on the last pass. This could be done just as easily by reading and discarding an arbitrary # of bytes out of the keyfile before making one and only one pass through the data file. Better documentation for the algorithm would include a set of test vectors. This is a set of plaintext, key, & ciphertext and allows someone implementing their code to test & see if they get the same results. If including anything but straight C code (and there is really little reason not to post a C implementation since C is so ubiquitous) then it is also a very good idea to test the documentation by finding someone else and asking them to try to implement it. If they can follow the description and quickly write something that passes the test vector test, then the description is good. The more mistakes they make, or the more questions they ask you because the documentation wasn't clear, the more help the documentation needs. In any event, as best I can determine, the algorithm used is to sum the keyfile & data file bytes for encryption, and for decryption to subtract the key bytes back out of the ciphertext to get the plaintext back. If so, this is actually a very old algorithm, may date back to the romans. It is also secure, *IF* (big if!) the key file is *Truely* random and the same size (or larger than) the data file. When used in this fashion, this would be a OTP (one-time pad) which is not breakable. A good way go get that "random" data would be to sample the least significant bits from a stream of digital sound, & some bit mashing (rotation & xor's) to mix the data a bit. The digital sound is probably best taken from a non-stored sound source, such as a microphone input. A popular, but *BAD* source of "random" data is a function such as "rand()" or "random()" in the C library. This is bad because it's only statistically random, uses a known algorithm, and there's a trivial algorithm that can go from a small sample of output to recreate the generator internal state & all future output. A Gif file (or other graphics format) has some good & bad properties as a key file. The bad thing is that gif files start with very non-random data. The good thing is that the actual internal *compressed* data may have some fairly good statistical properties. With a better mixing algorithm, a gif file would make a fine key, but for this function (which does no mixing at all), it may not be very good.
Using XOR instead of addition would make the program self reversing. That is, the same set of commands and options would be used to toggle the encrypted/ plaintext state of the file. I tried something like this once, using a standard pass phrase type key. It turned out to be piss poor in security. So I sacrificed auto-reversibility, implimented a random number generator of my own that called for a separate line of input from the keyboard, and added zero to 3 bytes of random garbage after each "good" byte on encryption, dropping the garbage on decryption - on top of the aforementioned XOR operation. It stood up a little better, though I'm not sure just how good it is. Probably it would help to compress the file (in a manner that doesn't include a lookup table) before encrypting. PGP seems to have made the issue moot, if you never distribute *any* keys to something. Distributing a public key is supposed to be safe, though I wonder if it might not be discovered at some future date that it's possible to derive the private key algebraicly. Certainly the information is there *somewhere* in that pile of bytes - it has to be.
> Using XOR instead of addition would make the program self-reversing. i know, i thought about it for about 5 minutes. i ended up with what i have now. > whatever process you use, if you can't produce a public key then it's > moot, ever since PGP and this bugs the hell out of me i mean who the hell ever heard of a non-confidential key ? > there's probably some way of deriving the entire key used to encrypt the > file by analyzing public keys there most definitely is, and because of this i won't ever be using PGP for anything truly important. i will stick with one-use system. not only that but the government watchdogs forced the system down beneath some limitations that make it possible for the NSA folks to decrypt any given PGP-encrypted file within 24 hours or something like that. my system is just not good enough to be ever watched by watchdogs, that's why i will be sticking with and improving / complicating it as time goes by. eventually i will design a way of assuring that every person must read the legal screen at least once before using the program, perhaps by placing a message before each execution that says something like i am released from any legal responsibility unless the user has read and agreed to the terms in the documentation. eetc. sorry i ramble so much, i'm not used to being able to get alot of stuff said at once since i left post-format for chat-format a couple years ago. anyways, next thing i am working on to incorporate into the process is anacryption , which takes bytes from one place in the file and puts them in another place. i dunno if this is the 'professional' name for it. this process is like XOR in that it's totally reversible if you have the key. i figure if i run this process optionally after encryption, it will add a little bit ot the scrambling of the file values. you're right about one thing, though, and that's that nobody wants to use a system that doesn't generate public keys. what a bummer, that people are so loose with their interpretation of 'privacy'
##plain.txt -- text file
This is a text to be encrypted.
##eof
##key. -- key file
This is a key used to encrypt a text 10 times.
##eof
##plain.enc -- bytes in hexadecimal
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
00000000 db 09 ea 4d b2 df 4d c1 d8 b7 08 d1 02 06 e5 0d
00000010 55 91 f7 8b 28 cc 23 af d9 eb 8b e1 9b 71 81 e6
00000020 70
##eof
i used mrjima v05h
mrjima --<metakey> -Iplaint.txt -Oplain.enc -0key -P10 -E
the pseudocode for this is back a few messages
ah but i forgot a line for it
in the case where Process_Is_Encryption, it should read:
Add In_Byte to Work_Word
Add Key_Byte to Work_Word
i forgot to include adding the key_byte there. sorry.
might as well repost the pseudocode, it was too full of errors last time.
variables:
InFile : is the file to either be en-crypted or de-crypted, any file
KeyFile : is any file used as a key
OutFile : is the result after either en-cryption or de-cryption
Pass_At : is the current number of completed passes
Pass_Goal : is the target number of completed passes, which defaults to 1 if
not specified
functions:
Reset(filename) : leaves the file open for input but returns the pointer to 0
Clear [ some variable ] : means set it to 0
signs:
##d - numerals in decimal ##h - hexidecimal
## begin psuedocode ##
procedure "crypto":
Open InFile for input #
Open KeyFile for input ## this is pretty self-explanatory
Open OutFile for output #
Clear Pass_At to 0d # this clears completed passes to 0
loop until EO_InFile_Chk AND EO_KeyFile_Chk AND (Pass_At=Pass_Goal) :
# that means do everything below until the variables
# EO_Infile_Chk and EO_Keyfile_Chk are both true,
# and Pass_At is equal to Pass_Goal
Read In_Byte from InFile # get a byte from infile
Read Key_Byte from KeyFile # get a byte from keyfile
Clear Work_Word to 00h,00h # set work_word to 0d
If Procedure is to Encrypt, then ... # if you are encrypting,
Add In_Byte to Work_Word #
Add Key_Byte to Work_Word #
End If # end encryption if
If Procedure is to Decrypt, then ... # if you are decrypting,
Add 256d to Work_Word #
Add In_Byte to Work_Word #
Decrement Work_Word by Key_Byte #
End If # end decryption if
If Work_Word is more-than 255d then ... # if work_word is > FFh,
Decrement Work_Word by 256d # take 0100h out of it
End If # end the FFh if
Clear Out_Byte to 00h # set the output byte to 0d
Add Work_Word to Out_Byte # set out_byte to work_word
Write Out_Byte to OutFile # and write it to outfile
If EOF(InFile) then ... #
Reset(InFile) # this means if you reach the
EO_InFile_Chk = TRUE # end of infile, say so
End If #
If EOF(KeyFile) then ... #
Reset(KeyFile) # same here for keyfile
EO_KeyFile_Chk = TRUE # these are to close the loop
End If #
If EO_InFile_Chk AND EO_KeyFile_Chk = TRUE then ...
Increment Pass_At by 1d
End If
# this means that once both the infile and the keyfile have reached their
# respective ends at least once, which means the _File_Chk variables have
# been set to TRUE, then you've completed one pass now say so.
# this is also used to close the loop, remember.
end loop
#
# keep doing the above until all the three loop conditions are met.
# once the loop is finished, then continue ...
#
Close(All them files)
end procedure "crypto"
## end psuedocode ##
that about does it.
This response has been erased.
That's not true. There are certain trusted methods, such as private
bonded courier, and previously encrypted channels, that can be used to send
a private kek over, and routinely are used for that purpose.
My secure method of transmitting a key has been to physically travel to the person(s) with whom I want secure communications and exchange keys in person. Feasible for exchanging keys, since I wanted to visit anyway. But not for using with every single message to be sent.
There are plenty of low-bandwidth or one-time methods, too. For
example, you could use a one-time crypto pad, with a random modification of
rot13, and hand the pads out to people you *might* want to communicate with.
As long as the message is shorter than the key on the pad, it's completely
secure.
|
|
|
- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss