RE: Encryption on the AS/400

I can sympathize with the encryption methods used by software companies. One
of our software packages bit-shifts the password (probably a nibble, since
the same program can en-/de-crypt the input with the same algorithm). Much
of the encryption isn't to encrypt, but rather to keep honest folks honest.

I am no cryptographer, but it seems that with your variable length private
key, private algorithm, and iteration factor, that at least the iteration
factor must be stored with the encrypted text. It sounds like you're using a
symmetrical encryption method, since the same key is required for decryption
as encryption.

If you were to release the encryption module to the public, you are
essentially forced to divulge the encryption algorithm - not because of open
source issues, but because of reverse engineering, stack trace, and
memory/data analysis while the program is executing.

Now the only thing we are left with is the key. Provided the algorithm uses
outputs from a function as input for another (such as MD5 rounds), and the
encryption key is fully utilized within one round or multiple rounds, longer
keys will yield better results than shorter keys. This is provided the
longer key is sufficiently random.

Assuming your key is longer than 16 bytes ("128-bit encryption"), and the
algorithm itself is robust, it sounds like your encryption algorithm is
pretty neat. Judging from what I know, it sounds like the key is passed over
the data, and the iteration factor is randomly derived, probably for each
round. I think many smaller rounds are better than fewer larger ones, if the
key position is maintained and not reused, and a randomizing factor is used
on each round. You say the output "appears random" given a particular input.
Does identical input create identical output (a la MD5)? If not, then the
iteration factor must be randomly derived to produce seemingly random
results. Are you looking at the data at the byte level, or also at the bit
level? Perhaps looking at the data at the bit, nibble, byte, or round-size
level might reveal patterns one might miss when viewing another way. Do you
think your encryption would stand against differential analysis and other
more recent, more advanced cryptanalysis?

I'm not knocking your work - I don't have the mathematical skill or know-how
to write a good and robust encryption program. But with last year's
discussion on IBM's password vulnerabilities, and increased knowledge of
cryptanalysis, I can't believe that a secret algorithm will protect data.
Between a key, algorithm, and iteration factor, the easiest to keep secret
is undoubtedly the key, IMHO.

Loyd


-----Original Message-----
From: Nathan M. Andelin [mailto:nandelin@relational-data.com]
Sent: Tuesday, October 16, 2001 11:25 AM
To: midrange-l@midrange.com
Subject: Re: Encryption on the AS/400

A former employer of mine encrypted Personal Identification Numbers (PINs)
by converting each digit to it's HEX equivalent.  Another employer used a
table, similar to the ASCII to EBCDIC translation table to encode data.
Quite easy to discover the algorithm.  My thinking is that you can't rely on
a strong key to protect a weak algorithm.

I have written utilities that help discover algorithms.  I believe some
algorithms are harder to crack than others.  Most brute force strategies
rely on a knowledge of the algorithm and knowledge of the key size.  They
try every possible key until the encrypted data looks sensible.  My thinking
is that by using a key based algorithm, and keeping the algorithm secret,
you give the cracker two hurdles to overcome.

> Of course if the algorithm is open the secrecy of the key is
> everything.  A compromised key, however, can be revoked
> and replaced at any time.

Good point.  Presumably, any data that was encrypted with the old key and
stored, would need to be deciphered and encrypted with the new key.

It seems that most public algorithms rely on longer keys to produce stronger
encryption.  But some argue that longer keys are written and stored
somewhere because people can't remember them.  One counter strategy is to
use a long associative phrase as the key.  Something that is easily
memorized.  You can also encrypt the key.

> As a matter of interest, and without giving away any details,
> I presume the system you have developed is a public key /
> private key one?

No.  My intent was not to develop a message transport mechanism.  In message
transport, my understanding is that a public key is used to authenticate the
sender and a private key is used to decipher the message.

My API was intended to encrypt and decipher data locally.  My stragegy was
to use a combination of strong algorithm, a private variable length key, and
an iteration factor.  It appears to produce completely random output from
virtually any data input.


Nathan M. Andelin
www.relational-data.com