Re: MI a good use for encryption? -- MI400

A couple of thoughts:

> So, just thinking
> WAY out of the box, I was wondering if MI would be a good (better than
RPG)
> tool to encrypt/decrypt data?  Would we be able to save our clients from
> having to invest in IBM's crypto LPP?

First, Leif is right.  Many new algorithms will implement as fast or faster
in ILE C.  The new Rinjdael algorithm selected by the National Bureau of
Standards was almost certainly written in C and written with C optimization
in mind.  I haven't looked at it yet, but the other candidates I had
"rights" to look at did.  Moreover, that is the norm and was true for
crypto-related algorithms like SHA-1 and MD-5.  I personally think raw
performance is generally obsolete, now, as a reason to do MI, even for
crypto which once upon a time was a poster child.

Second, there is no security advantage whatever in doing crypto in MI in
the sense that it is "obscure".  No crypto algorithm that is worth anything
(and no commercial standard) will be secret anyway.  Most will have widely
available "reference implementations" in C.  This is hopefully obvious, but
I still see arguments in newsgroups that presume that "security by
obscurity" is important.  Well, in cryptography, at least, it is entirely
irrelevant and outright discouraged.

Third, pay very close attention to key management.  That is, how do you
generate keys and how do you pass them around.  Many systems are not
compromised by high falultin' theory as much as they are by stupid
programming tricks.  In particular, a surprising number of hacks into
systems have been mounted that rely upon, one way or another, finding a
cryptography key (or even a partial one) in the debris of previous
encryptions or in the ebb and flow of the library calls, network traffic,
and so on.

To pick an obvious no-no:  Don't, "for convenience," stick a crypto key in
a data area.  That is very obvious, I hope, but there are hundreds of less
obvious cases.  Rely on as little infrastructure as possible and see how
many "layers" of protection you can get.  For instance, one may think "if
someone can break into my system well enough to see data areas, I'm already
compromised, so why not use it."  That's not how the experts do it.

Finally, let me put in a very small commercial for my own product.  In many
contexts in many newsgroups over the years, I have said:  "These things are
harder than they look."  This is not a sine or cosine function that stands
alone.  It's a heavily integrated deployment that requires many
counter-intuitive things to be considered.

Conventional testing is easy (few functional bugs cause anything but
hopeless garbage results) -- security testing is the hard part.  Do you
know how?  It is generally held that unless you break crypto, you have no
business implementing it.  Ask around in sci.crypt or sci.crypt.research.
In any case, read any serious book on the subject (e.g. one that discusses
key management, not just raw algorithms) and you'll quickly appreciate how
hard it is to get this stuff right.  Meyer and Matyas' "Cryptography" was
written by two of IBM's DES designers a while back.  It is still an
excellent reference book that is widely available.  If you do it yourself,
please read one or two sources of this kind.  The make versus buy decision
is very unconventional here because the test cycle isn't what it appears to
be.


Larry W. Loen  -   Senior Linux, Java, and iSeries Performance Analyst
                          Dept HP4, Rochester MN

speaking on my own. . .