× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



From: <David.X.Kahn@gsk.com>

> There is a fundamental flaw with relying on the secrecy
> of the algorithm. No matter how cryptic it is someone
> will eventually crack it, possibly by taking the shortcut
> of buying your product and reverse engineering it.

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




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.