[Classpathx-crypto] quick comments on gnu.crypto code

[David Brownell]

Hi,

I recently grabbed a copy of the code.  No comments yet on
the real guts -- though from the look of it I won't have many
complaints, clean and regular crypto code is usually a very
good sign!  So here's a random set of questions and comments
that came to mind as I skimmed what CVS told me.

Some peripheral points first leaped out at me:

    - Coding style ... three space indents?  No tabs?  And
      Hungarian "IamAnInterface" notation?  Yoiks!  I don't
      like even one of those, sorry.

    - PDFs in the docs.  DocBook XML where possible,
      please.  Though since these are original specs, I suspect
      that's not a real option.  Does CVS need to have those?
      (I hate TexInfo equally ... DocBook at least turns into
      good HTML, though the MathML output may be a
      bit lacking just now.)

    - javadoc.  The links to the PDFs were all broken, and
      there were no "package.html" files to describe why each
      package is there and how to use it.

    - License ... LGPL, not "GPL + library exception".  Maybe
      not an immediate issue, but static linking will increasingly
      matter.

OK, non-peripheral points:  functionality.  Seems to be a strange
selection in this first code drop.

    - Seems that widely used hashes (MD5, SHA1; maybe MD2)
      aren't there.

    - Block ciphers.  Again, common ones are not there yet.
      DES, 3DES-EDE; likely Blowfish; maybe CAST128.

    - And of less immediate concern (to me), stream ciphers.
      ARCFOUR, maybe AES in stream modes, and so on.

    - Looks like the factory always runs selftests on whatever
      it returns. (gnu.crypto.cipher.CipherFactory).  That should
      be conditionalized on a "if doing development" static final
      boolean flag, so it normally doesn't happen.

    - No public key crypto support (RSA, D-H, etc) or digital
      signature support.  Again, why?  The PKCS7 doc there
      strongly suggests it'll be added, along with lots of BER/DER
      style utilities for cert and public/private key management ...

That's just first reactions from a look at the code.  Of course
I like the fact that ciphers are interfaces and there's none of
that silly overhead of a java security layer to slow down calls
past abstract method overhead, so from that perspective the
API framework starts out immediately on the right foot.  And
since secure key storage is a quick hack [NOT!] I can easily
understand adding it later, after some hardware hooks have
been reasonably prototyped.

A lot of that is just wondering what the direction for this code
is expected to be.  I'll assume that what's there is a good start,
but since it doesn't do what I'd first need to be done ... :)

Not having support for today's most widely used cryptographic
algorithms seems to me like it'll be an adoption problem, and I
hope the plan is to make sure that several of those algorithms
get added before the first (beta?) release.

- Dave

p.s. I'm not currently subscribed to the list, so please cc me
    on any responses.