Re: Encryption algorithm used for the IBMi OS passwords.

I disagree that using an "unknown" encryption algorithm can be better than
using a known and widely trusted (by experts) algorithm. First, the
algoritm must be implemented in machine language (or bytecode). By
definition, this means that the algorithm is not known. Therefore, it is
impossible to use an "unknown" algorithm. Second, using an algorithm that
has not been vetted by math and encryption experts, is much more likely to
contain weaknesses. A weakness is a problem in the algorithm that allows
cleartext data to be retrieved much more quickly than by brute force.

Every encryption algortithm is susceptble to brute force attack. Thats why
the selection of the key, key length and how well the key is protected are
the defining factors in how well encrypted data is really protected. For
data that needs to be protected for relatively long periods of time, you
want to pick an algorithm (and key length) that requires a relatively large
number of CPU cycles and a key that is as close as possible to random. This
gives you the best possible protection against brute force attacks.

If the length of time data needs to be protected is relatively short -- a
Kerberos ticket, for example -- then it makes perfect sense to use
algorithms that have shorter brute force attack times and shorter key
lengths. But you key selection and protection is still critical. The
ability to accurately predict which key will be used obviates the strength
of the alhoritm.

In any case, the notion that risk can be reduced because attackers can't
know how you are protecting data is the equivalent of sticking your head in
the sand. IMHO, of course…
On Apr 1, 2016 11:54 AM, "Nathan Andelin" <nandelin@xxxxxxxxx> wrote:

I actually applaud auditors for wanting to know this information! Its
something they should know.

The irony is that auditors don't like to disclose information about the
tools they use to perform audits. In a lot of cases, they have built or
purchased tools which are based on known encryption algorithms, and they
can't run the tools without knowing a client's algorithm.

The safety of passwords does not (nor should it) depend on others not
knowing the process used. This is known as "security by obscurity" and
everyone knows that doesn't work!

The "security by obscurity" point tends to be misused a lot. It is usually
raised by vendors who have encryption API's for various language
environments, brute-force tools, tools which are used to expose weaknesses
in encrypted streams, tools which perform encryption and decryption.

Again, there is a huge industry based on products and services which rely
on the use of "known" algorithms. That includes promoters of conferences
where scientists expose weaknesses in known algorithms. Governments which
"need" to decipher encrypted streams using methods based on known
algorithms.

They have a point to a degree. Prior to the use of known algorithms, there
were a lot of amateur's that produced weak algorithms. But there are cases
where security is enhanced by experts developing unknown algorithms.

There is no way to prevent someone from
"learning" how a program does what it does.

The typical way of "learning" or "breaking" an algorithm is to repeated
push "known" streams through an encryption process and look for patterns
which can be viewed graphically. Begin with null streams, and work your way
through other character streams. Weak algorithms produce symmetrical
patterns. Strong algorithms produce random looking patterns.

The case against using known algorithms is simple, and algebraic. If C is a
product of A and B, and A and B are known, then you have a better
opportunity of discovering C.

Brute force techniques rely on known algorithms.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.