Re: Encryption on the AS/400

["Nathan M. Andelin" <nandelin@xxxxxxxxxxxxxxxxxxx>]

From: "Goodbar, Loyd (AFS-Water Valley)" <LGoodbar@afs.bwauto.com>


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

This underscores my sentiment that, even with encryption, different
situations will dictate different priorities.  For example, with the DES
algorithm one priority was that it be easy to implement on a wide range of
platforms by using a wide range of languages.  Over a number of years, a
large number of shops have been supplied with psuedo code to aid in the
implementation.

Under a different situation, speed could be the top priority.

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

Based on what I've revealed about my method I'm not sure that I would arrive
at the same conclusions.  But I think a cracker would use similar logic.
That's to say, use known information as a basis of narrowing possibilities.

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

My thinking is that it's more difficult to reverse engineer an algorithm
than it is to look it up on the Web.  But I tend to agree that encryption
algorithms can be discovered with the right tools, enough time, and enough
effort.

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

In the case of my algorithm, and based on my own attempts to crack it, I'd
have to agree that a longer key produces stronger encryption.  It seems to
me that an algorithm could be produced that provided strong encryption based
on a shorter key.  Longer keys applied to known algorithms thwart brute
force attacks by dramatically increasing the number of possible keys.

My thinking on using a variable length key is that it provides an element of
control to the user.  A longer key offers stronger encryption but may be
more difficult to remember.  It may also put a wrench in the gears of some
brute force techniques that expect a fixed length key.  But that's not the
primary objective.

I think the maximum size of my key is 128 bytes (1024 bits).

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

More interesting logic!

> You say the output "appears random" given a particular input.
> Does identical input create identical output (a la MD5)?

If you're asking whether the process is repeatable, the answer is yes.
Given the same data, key, and iteration factor, the output will be the same.
The algorithm is not based on the time of day, for example.

> If not, then the iteration factor must be randomly derived to produce
> seemingly random results.

Good logic.  Actually the iteration factor is controlled by the user.  In
the case of my algorithm, a factor of 3 tends to yields more random looking
results than a factor of 1, for example.


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

Excellent point!  A determined cracker would probably look at both.

> Do you think your encryption would stand against differential
> analysis and other more recent, more advanced cryptanalysis?

I think so.  I have used differential analysis against it.  But there are
much better mathematicians out there!  My thinking is that the more advanced
techniques are still designed around the basis of various assumptions.  Just
don't give them all the variables.

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

A secret algorithm is no silver bullet.  I believe it could be cracked.  The
real problem seems to be when people rely on secrecy to protect an otherwise
weak algorithm.

> Between a key, algorithm, and iteration factor, the easiest to keep secret
> is undoubtedly the key, IMHO.

I agree.

Nathan M. Andelin
www.relational-data.com