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.

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.

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.

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.)

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 

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.
 
 

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".

response 50 of 55:

Apr 24 04:18 UTC 2000

The multiple pass feature actually weakens the key.  How much it weakens
the key depends greatly on the relative sizes of the key file & data
file.  A pass count of exactly 256 on key & data files of identical size
is an extreme case, but it's easy to find other combinations that
results in an expanded key stream that is either always a constant, or
repeats with a small period.  Either of these is bad.  If the key file
is at least the length of the data file and contains "true random" (*not
generated by a PRNG) data, then there is no value to a pass count other
than 1.  If the key file is *not* "true random" then adding bytes
together does not improve the entropy and may well hurt it badly
depending on the exact values selected.

One of the problems with using addition to mix bytes is that it
introduces a 1 bit left shift dependency.  In the worst case (repeatedly
adding a value to itself) this can result in very bad things like the
all 0 expanded key case.  In the best case, a clever algorithm can use
this for bit avalanche, idea uses multiplication as a clever way to mix
bits and basically takes advantage of bit avalanche from addition in
doing so.

Encrypting a continuous stream of data is pretty common in the data
market; this is what you might want to use with a telephone
conversation, video, or with telnet/ssh.  Especially with video, you are
dealing with humongous amounts of data; reading through the key file
multiple times would not be very attractive even if the exact length of
the data stream were known in advance.  In any event, this is a pretty
obvious case where what's happening in the computer world doesn't match
up well at all with the "human wants to encrypt a file" model.

Public key technology generally relies on a set of one-way functions
that can be nested two different ways yet yield the same result.  For
instance, here's Diffie-Hellman (which can be used for key exchange, but
not directly for encryption or decryption):
        (1) Alice chooses a large random integer x and calculates
                X = (g**x)mod n
        (2) Bob choses a large ranodm integer y and calculates
                Y = (g**y)mod n
        (3) x,y are private keys; Alice & Bob don't suare these.
                X and Y are public keys, Alice & Bob tell each other
                their public keys.
        (4) Alice computes k = (Y**x)mod n
        (5) Bob computes k' = (X**x)mod n
        k and k' are both equal to (g**(x*y))mod n.  This value
        is the shared secret no one else can compute; this can be
        used in any ordinary block or stream cipher.
A 3rd party may know n,g,X,Y (the latter by evesdropping) but still
can't compute k unless they can solve the "discrete logarithm" problem;
this problem hasn't been solved despite considerable mathematical
attention.  n and g are public parameters (Alice & Bob need to agree on
this), n & g need to be chosen carefully to ensure best security.  n
should be prime, (n-1)/2 must also be prime, and n should be large, like
at least 1028 bits.  g should be a primitive root mod n.

response 52 of 55:

Apr 25 22:16 UTC 2000

for the process i have,

if you multiply the difference between size of infile and size of key,
by the number of passes , and the result is a number equal to the size of
the infile, and you multiply the number of passes in this case by 256,
you will end up with no change to the infile.

i have not tested this, say using a file of 3000 bytes and a key of 2999,
running 3000*256 passes (well # passes is limited to 65,535) but it
would theoretically result in 0 encryption

infile of 500 bytes and key of 295 bytes (diff of 5)
number of passes 25600, you will end up with 0 encryption

(theoretically)

i installed the passes feature ... well let's illustrate why

values in decimal (0-255)

Infile bytes:   010  033  050  009  017  100

key bytes :     000  001  005  013  100  255

(5 passes)
result 1 :      010  034  055  022  117  099
result 2 :      010  035  060  031  217  098
result 3 :      010  036  065  040  062  097
result 4 :      010  037  070  049  162  096
result 5 :      010  038  075  058  007  095

anyways, as you can see using the bytes 000 or 255 is foolish, but, only
in the following situations..

1. no.passes * (diff in file sizes) = size of one file

2. or, if the size of the one file is even divisible by the other
   (which would be the case if both files are same size or if say one file
    was 50 and the other was 1 (duh), 2, 5, 10, or 25 )

because these two situations are not hard to produce, i also added
features to mr.jima that will count the number of 00h value bytes in a
file, and a feature that, after encryption, will tell you how many bytes
of the original file have been left unchanged in the same position.

i am thinking of adding a third feature that will tell you whether or not
the byte values have been effectively 'scrambled'

for example, here are three bytes 003 , 010 , and 050 .

here they are encrypted,          013 , 020 , and 060 .

in this case the difference in three bytes was 10 bytes. mr.jima would see
that the bytes are indeed 'changed', but would not know that they are
effectively no different than before. 

 bytes           A B C D E           decrypted
                 a b c d e           encrypted
 
in another version i will install a feature that checks the diff. between
bytes A and a , and then the diff. between the bytes B and b. if they are
no different, then it will count this as a 'weak spot' . if they are
different, if will count by how much (diff. between 2 diff. between 2
diff.) and then keep this in the back of its mind. it will then compare
the diff. between the B and b ,  to the diff. between C and c. same as
before. if they are different, it will check by how much and compare this
to it's last 'back of the mind' 'diff between diff between diff' . if this
is the same, then it will count this as a 'pass weak spot'. if not, then
it will take the newer value to the 'back of its mind' and then keep
going.

hopefully this will tell a person more about the encryption they received. 
see what i mean ?