|
Grex > Cyberpunk > #129: Powerful new encryption designed by Eyenot - Mr.Jima Encryption |  |
|
| Author |
Message |
| 25 new of 55 responses total. |
mdw
|
|
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.
|
jp2
|
|
response 26 of 55:
|
Apr 17 20:57 UTC 2000 |
This response has been erased.
|
mdw
|
|
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.
|
eyenot
|
|
response 28 of 55:
|
Apr 20 21:57 UTC 2000 |
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.
?
|
eyenot
|
|
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
|
eyenot
|
|
response 30 of 55:
|
Apr 20 22:17 UTC 2000 |
>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.
|
mdw
|
|
response 31 of 55:
|
Apr 21 00:06 UTC 2000 |
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.
|
drew
|
|
response 32 of 55:
|
Apr 21 02:17 UTC 2000 |
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.
|
eyenot
|
|
response 33 of 55:
|
Apr 21 03:50 UTC 2000 |
> 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'
|
eyenot
|
|
response 34 of 55:
|
Apr 21 04:59 UTC 2000 |
##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.
|
eyenot
|
|
response 35 of 55:
|
Apr 21 05:33 UTC 2000 |
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.
|
jp2
|
|
response 36 of 55:
|
Apr 21 19:28 UTC 2000 |
This response has been erased.
|
jazz
|
|
response 37 of 55:
|
Apr 21 20:53 UTC 2000 |
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.
|
drew
|
|
response 38 of 55:
|
Apr 21 20:59 UTC 2000 |
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.
|
jazz
|
|
response 39 of 55:
|
Apr 21 21:06 UTC 2000 |
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.
|
mdw
|
|
response 40 of 55:
|
Apr 22 03:14 UTC 2000 |
The pseudo-code & example vector in #35 don't appear to correspond to
each other. Two of the example vectors are presented as character
strings, and don't include any line delimiters. The character set used
is also not identified (could be ascii, ebcdic, or something else). If
ascii, then the string would appear to be:
124 150 151 163 040 151 163 040 141 040 164 145 170 164 040 164
157 040 142 145 040 145 156 143 162 171 160 164 145 144 056
(in octal), which is 29 decimal characters in size. The output vector
given is 31 bytes and the claim is that the algorithm does not increase
the file size. That suggests a line delimiter of 2 characters is
included, most likely
015 012
or carriage return, line feed. It's difficult to tell if the same is
true of the key used. The string
This is a key used to encrypt a text 10 times.
is only 46 character in size.
The pseudo-code given appears to write out one byte on every iteration
of the loop. The loop body is apparently iterated once for the maximum
of the data file size and the key file size, plus one extra iteration
for each increment of pass greater than one. This means with an input
data file size of 48 bytes, and a pass count of 10, the output file size
would appear to be 57 bytes in size. This doesn't match up with the
claimed characteristics of the algorithm, obviously. Perhaps the intent
is to sum each byte of the data file with "pass" bytes of key data,
wrapping key data as necessary to supply sufficient key key material.
Ie, if d[i] = the i'th byte of input data, k[i]=the i'th byte of key
data, a=the amount of data, b=the amount of key data, & p=the pass
count, to calculate o[i], the output at offset i,
w = d[i];
for(j = i,x = 0; x <p; ++x, j += a)
w += k[j % b];
o[i] = w;
Unfortunately, I can't make this algorithm generate the example vector
claimed. Using decimal, I get:
pass=0 d[0]=84 k[0]=84 sum=168
pass=1 d[0]=168 k[33]=101 sum=269
pass=2 d[0]=13 k[18]=32 sum=45
pass=3 d[0]=45 k[3]=115 sum=160
pass=4 d[0]=160 k[36]=32 sum=192
pass=5 d[0]=192 k[21]=32 sum=224
pass=6 d[0]=224 k[6]=115 sum=339
pass=7 d[0]=83 k[39]=32 sum=115
pass=8 d[0]=115 k[24]=99 sum=214
pass=9 d[0]=214 k[9]=32 sum=246
resulting output (in octal):
366 343 144 222 100 040 341 034 363 161 276 000 177 060 312 151
344 032 050 331 321 200 152 377 006 301 025 313 060 300 041 060
377
or in hex:
f6e3 6492 4020 e11c f371 be00 7f30 ca69
e41a 28d9 d180 6aff 06c1 15cb 30c0 2130
ff
It's useful when including examples to include several that exercise
different boundary conditions - in this case, the key file could be
larger or smaller than the data file, the pass count could be 1, 2, or
larger, etc. Several such examples, with hexadecimal inputs & outputs,
could make the algorithm used a lot less ambiguous.
It's almost always an even better idea to, instead of using pseudo-code,
to use real code in a well-known language, ie, C, and to *test* that
code to be sure it works as expected. It's more important for that code
to be short & easy to understand, than necessarily efficient. Doing
everything in-memory, (using byte arrays) is a good way to achieve this
kind of simplification.
The AES algorithms, described here
http://csrc.nist.gov/encryption/aes/aes_home.htm
are some interesting examples of some much more complex algorithms
complete with descriptions, sample implementations, and sample vectors.
In #33, a technique of "swapping" characters is described. This is
called transposition, and is another elementary encryption technique.
The addition that is *apparently* done by "Mr.Jima" is a specific sort
of "substitution" cipher, and that is the other classic technique. It's
possible to combine the two, and most modern block ciphers use some
combination of both within one data block. In DES, the "S boxes" are an
example of substitution, and the bit permutations done at various steps
are examples of transposition. One of the goals in DES (and most block
ciphers) is that changing any one bit of input or key should cause
*roughly* half the output data bits to flip, in a pattern that is
extremely hard to predict. The transposition and substitution done both
help DES to achieve this goal. Some other cryptographic primitives
include "expansion", where one takes some input data & creates
additional data based on that initial data. The DES key schedule
algorithm is one example of expansion. An additional class of
algorithms is "compression", where one takes a lot of input data and
reduces it to a smaller amount of bits. This process is usually
intended to be one way and very lossy - a "hash" or "checksum" function
is one example of compression. DES has some less extreme forms of
compression inside it - in fact the S boxes also do some compression,
because they take 6 bits of input, but only produce 4 bits of output.
So far as public key technology goes, it's been around since the 70's.
It's actually very nifty stuff. The idea is actually that you have 2
keys. One is private, you keep that, and nobody else knows it. The
other key is public, everyone gets to know that one. There are various
ways to "sign" things using the private key, such that you can prove to
someone else you know your private key (they verify this with your
public key), to encrypt and decrypt data, and various key exchange
protocols. The last is important because public key encryption is
*very* slow, and not practical for large amounts of data. In fact, PGP
uses idea (or other symmetric key encryption algorithms) to encrypt the
actual data it ships. It's certainly an interesting question whether
the NSA can crack RSA. It does seem certain that nobody else knows how
to break RSA. Among other things, the NSA is the world's largest
employer of non-teaching mathematicians; they have some very bright
people working for them. Objecting to RSA because the private key is
"somehow" encoded in the public key is just nonsense. Practically the
same thing could be said of any symmetric algorithm - if you know (or
can predict) the plaintext, and know the ciphertext, then (in theory)
you know the secret key used to encode it. The brute force DES cracking
machine made by EFF relies on this theory.
There is no such thing as perfect security. Even an OTP can be broken -
the key transport problem is a critical practical weakness of OTP. To
analyze any security system, you have to look at the pain of using it
(encryption is, like it or not, never as fast or convenient as sending
things in the clear), the value of the data being protected (to you),
and the resources and determination of the opponent. Ya, if you're
protecting nuclear bomb secrets, and your opponent is the NSA, you might
not want to use RSA. On the other hand, if you're merely protecting
letters written by your SO, and your opponent is the typical cook-book
vandal, even RC4-40 might suffice. If you have a very boring sex life,
even plaintext might work (it's certainly less likely to attract
attention.)
|
eyenot
|
|
response 41 of 55:
|
Apr 22 08:39 UTC 2000 |
re: keeping outfile length same as infile, retaining encryption
where lines read
if eof(infile) then ...
set eo_infile = true
reset(infile)
add line: reset(outfile)
end if.
not too fucking hard or twisted to figure out.
given the objective
|
eyenot
|
|
response 42 of 55:
|
Apr 22 08:51 UTC 2000 |
re: perfect security
well what do you want ?
won't use subversion and suggestion to relay the identity of a keyfile to a
clued friend, won't use the same key more than once with a surely encrypting
system (but will with something unsure like PGP) because, mistakenly, you
believe it will lower the value of the encryption (why not use multiple keys
then, jacko?) evidently won't send key through u.s. mail (but will use a
program know to be crippled by the u.s. government ofr the sake of the easy
cracking and perusal by the nsa and for all you know contains instrinsic
backdoor key in every key and/or encryption) and then you say
'well there's no perfect security'
well what do you want ?
i say if a person is too lazy to use a sure system with multiple keys and
to use their brain enough to tell a person what key(s) were used without
letting everybody in the chatroom in on it, then what of value do they
have to encrypt ? if they have something of value to encrypt, why were
they ever hired ? for the entertainment of the ceo or general ? somebody
who enjoys how the person's every other syllable is a story about their
childhood fantasy ?
get real
|
eyenot
|
|
response 43 of 55:
|
Apr 22 09:01 UTC 2000 |
|
jp2
|
|
response 44 of 55:
|
Apr 23 01:20 UTC 2000 |
This response has been erased.
|
mdw
|
|
response 45 of 55:
|
Apr 23 05:40 UTC 2000 |
I'm afraid the pseudo-code still isn't a good description of eyenot's
encryption. I was, after considerable experimentation, able to come up
with the following C that produces the same ciphertext as eyenot's example:
#define KEYSIZE 48
unsigned char key[48]={
'T','h','i','s',' ','i','s',' ','a',' ','k','e','y','
','u','s','e','d','' ,'t','o',' ','e','n','c','r','y','p','t',' ','a','
','t','e','x','t','' ,'1','0',' ','t','i','m','e','s','.',13, 10};
unsigned char text[33]={' T','h','i','s',' ','i','s',' ','a','
','t','e','x','t',' ','t','o',' ',' b','e','
','e','n','c','r','y','p','t','e','d','.',13, 10};
unsigned char cipher[33];
int keysize = KEYSIZE;
char ekey[KEYSIZE];
do_encrypt()
{
int passes = 14;
int i, plim, pass;
int datasize = 33;
for (i = 0; i < keysize; ++i)
{
cipher[i] = text[i];
plim = passes + 1;
if (i>=(datasize-passes)) --plim;
for (pass = 0; pass < plim; ++pass)
cipher[i] += key[(i+pass*datasize) % keysize];
}
}
The first 19 characters of ciphertext contain the sum of the plaintext
plus 15 bytes from the key string. The last 14 characters contain the
sum of the plaintext and only 14 characters from the key. Evidently
eyenot's program is quitting half-way through the last pass. It's not
clear to me how "14" relates to a pass count of 10. Summing key bytes
in this fashion is almost certainly bad; how bad depends on the key
size, data size, & pass count. If the key size & data size were equal,
& the pass count were 256, then the result would be the same as no
encryption at all, as adding a key byte to itself 256 times is
equivalent to a left shift of 8 bits, which will result in a null
character.
There is a myth that the major value of encryption is to hide files that
are shared between a small number of humans. This is absolutely false.
One of the most important uses of encryption is not to encrypt human
data, but to encrypt portions of network traffic. This may be useful
for authentication, integrity checks, and other purposes. Some of the
recent vandal tools (for instance, tfn) use encryption to hide packet
data - in fact, tfn uses a stronger encryption algorithm than that used
by most banks. AFS encrypts data checksums but not the actual data, for
data going to/from the file servers.
|
eyenot
|
|
response 46 of 55:
|
Apr 23 13:33 UTC 2000 |
> The first 19 characters of ciphertext contain the sum of the plaintext
> plus 15 bytes from the key string. The last 14 characters contain the
> sum of the plaintext and only 14 characters from the key. Evidently
> eyenot's program is quitting half-way through the last pass. It's not
if the intext is for this example 5 bytes ([#] will be a byte) and the
key 3 bytes, using 2 passes, an illustration of the encryption looks like
this...
! is the mark where EOF_InFile_Chk is set to TRUE
* is the mark where EOF_KeyFile_Chk is set to TRUE
pass# 0 1 2(fin)
plain [1] [2] [3] [4] [5]![1] [2] [3] [4] [5] loop close / process fin
key [a] [b] [c]*[a] [b] [c] [a] [b] [c] [a]
|
^at this point, two conditions for closing
the loop are met, but all passes (2) aren't
finished
|
^at this point the entire
infile has been read 2
times meaning 2 passes
you notice that upon completing the second pass, the keyfile has been read
in three complete times but the first byte is all that is read in the 4th
time. well, i can't say it's entirely true i didn't realize this would be
the case, but it doesn't bother me too much.
> clear to me how "14" relates to a pass count of 10. Summing key bytes
> in this fashion is almost certainly bad; how bad depends on the key
> size, data size, & pass count. If the key size & data size were equal,
> & the pass count were 256, then the result would be the same as no
> encryption at all, as adding a key byte to itself 256 times is
> equivalent to a left shift of 8 bits, which will result in a null
> character.
which is what i have been saying the full time... i know it's not 100%
secure in that sense. if you pick a key length same as infile length, and
you run 256 passes, you result in no encryption. on earlier versions i
forced the pass maximum to 256 for this reason, but on later versions i
allow it up to 65535.
of course, i don't understand your surprise. i have said the same thing
you are saying now from the beginning.
if you aren't smart with which key you pick, and the number of passes you
use, you will not encrypt your file at all.
for these reasons i added two features to the jima program, one that checks
a potential keyfile for 00h and another that checks the infile against the
encrypted file for number of unchanged bytes.
i could also set up a 'prediction' option that calculates the size of the
keyfile against the size of the infile and number of passes, and tells you
whether or not it would be safe to use the chosen configuration, possibly
suggesting another number of passes that would be suitable.
> There is a myth that the major value of encryption is to hide files that
> are shared between a small number of humans. This is absolutely false.
> One of the most important uses of encryption is not to encrypt human
> data, but to encrypt portions of network traffic. This may be useful
first of all, i see no difference between network 'traffic' and 'files that
are shared'.
they are both Data being shared between an exclusive number of humans.
as far as encrypting streams, i have thought of using a rotating buffer
and encrypting every byte before sending it back out to the communication
system. this would work , but what about the process ?
i cannot think of a way of securely encrypting each byte of a stream
using a file as key. i could use random numbers pre-generated and set
up in an array across a consecutive number of generations, say an array
of
[ 0..255 , 0..255 ] of Byte ;
and then based on the input character get the value of the first index and
from the key get the second , but which random numbers to use ?
in any case, the process used to encrypt a file can be figured out by
analyzing the machine language of a program. you can't effectively hide
a key or an 'algorithm' within the machine language itself , in any way ,
if it's required that the information remain secret.
that means that the entire vitality of the encryption relies on a
personal key that only the end-users know the nature of.
of course, this is why there is such a thing as 'key encryption'.
right now i am thinking of how to plausibly generate a public key using the
private key as a base. i am thinking...
A Public Key Must
(1) be used to encrypt a file that cannot be decrypted using the same
Public key
(2) be used to encrypt a file that can only be decrypted using the
Private key of the Public key's owner
(3) not be able to decrypt a file that has been encrypted using the Private
key of the Public key's owner
but there are some real problems.
A Public Key Must Not
(1) be able to be used as a way to discover the contents of the private key
of the public key's owner
not a whole lot of Must Nots but it's a big one considering the fact that
the public key is built based on the private key's contents.
supposing that i used random numbers to create a public key from the private
key's contents, as you've said before the exact contents of the private key
would be easy to detect since randomization on a computer is not truly
random and a sufficient processor can tell all the previous and consecutive
numbers that would be generated along the same algorithm used to generate
two or three 'random' numbers along said algorhithm.
RE: "yes there is a perfect process and you're isn't it"
well dorothy err "jp2" what is the perfect process, describe it in detail.
|
jp2
|
|
response 47 of 55:
|
Apr 23 19:57 UTC 2000 |
This response has been erased.
|
mdw
|
|
response 48 of 55:
|
Apr 24 01:15 UTC 2000 |
Actually, OTP is a "symmetric" algorithm, sometimes called "secret key".
Public key technology has a private key which is supposed to be only
known by one party so is truely "private" as opposed to a "shared
secret".
|
jp2
|
|
response 49 of 55:
|
Apr 24 01:25 UTC 2000 |
This response has been erased.
|