Re: Encryption on the AS/400 -- MIDRANGE-L

Nathan wrote:

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

Nathan, you should check the history of the encryption scheme used to
protect DVD. That relied on a secret algorithm which, as any cryptanalyst
could have told them would happen, was cracked almost at once. It's now
possible for anyone to download code from the Internet to decrypt DVD. PGP
OTOH has been completely open for years and it appears still to be secure.

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

No. If the key used to protect data is compromised then so is the data that
it protected. You have to assume that the attacker will now have the data
in clear. If you are foolish enough to re-encrypt the same data you will
give the attacker just the lever he needs to start cracking your new key.
One of the ways into the enigma machine during WWII was a daily weather
report that very often had the identical wording. If it did Bletchley Park
would have the key for the day just a few minutes after the intercept
arrived. As soon as the cryptanalyst saw the plaintext German beginning to
appear he would shout it out triumphantly and the whole hut would join in.
They all knew the standard weather report by heart.

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

With most (all?) modern algorithms you do not have to remember the key. The
key is not memorable because it is a string of random digits. The key
itself is encrypted using a pass phrase that can be remembered. The pass
phrase is not stored on the machine.

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

That is correct. But the great advantage of the key pair, the thing that
makes secure e-commerce possible, is that it is very simple to distribute
the public keys. With a single key system, distributing the key while
keeping it secure is a real problem.

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

If I were buying a commercial encryption package I would expect to be able
to use it to send data backwards and forwards between myself and any number
of partners. If I simply wanted to encrypt data on my local machine I could
knock up a program in about an hour that would give me 100% uncrackable
encryption. Simply use a random key the same length as the data to be
protected. XOR each byte of the message with the corresponding byte of the
key. The same process can be used to decrypt the message. There is no
pattern at all in the ciphertext and therefore no way in for a
cryptanalyst.

The real issues then are how random can I make key, and how do I stop an
attacker from intercepting it.

Dave...

=======================================================
The opinions expressed in this communication are my own and do not
necessarily reflect those of my employer.