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

[Raif S. Naffah]

At 08:42 PM 12/3/01 -0800, David Brownell wrote:
> 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.)

as i mentioned in an earlier message, those documents are published by the 
designers not us.


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

these are in the process of being fixed.  before the existence of a web 
page, the idea was to bundle and include them in the release.  i'm not 
doing this anymore;  instead they will be pointing to the web page.  this 
has the added advantage of making the release smaller in size.


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

again.  this is being changed 'as-we-speak'.


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

well;  if you have implementations of them that you'd like to contribute 
then pls ;-)


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

same thing.


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

same thing for arc4.  i'm expecting, with the first release to start 
receiving these common algorithms.

unfortunately the implementations i've already done for these are under a 
different license and hence i cannot include them here.  somebody else will 
have to step forward.


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

noted.  i'd like to open a discussion thread on 'how we can ensure a degree 
of trust in the code'.  the self-test approach is far from being optimal 
and hence i'm looking forward to a fruitful brain-storming exchange.


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

re. PK algos, the same as above.

re. ASN.1 stuff, i'm already the maintainer/sole-programmer of a 
sourceforge project (cryptix-asn1) that addresses that and is under a 
BSD-like license (see <http://sourceforge.net/projects/cryptix-asn1>).  why 
did i mention this?  because all DER related stuff, in gnu.crypto can 
extend/use classes generated by the cryptix-asn1 library.


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

good to hear :-)


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

i've done in the past (JNI hooks) to plug native implementations of 
algorithms with the first jce beta with an open-source project, but that 
code never got published.  the justification at the time was that pure java 
code was as fast, and in some instances faster, than using the native 
code.  while this is true if you have a choice between the two, i take your 
point that sometimes you dont.  i will add that to the TODO list.


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

i hoped the README explained where we're going.  this is the start.  the 
next step is to build the adapters that will allow this library to _also_ 
work the jca/jce way hence offering programmers a _choice_.

i'm confident that people/developers will join in, contributing 
implementations of the "every-day" algorithms soon.  in the meantime if you 
and/or others know of the existence of java implementations out there of 
those algorithms with a licence that would allow to re-work them under the 
XGPL i'm happy to do that myself.


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

my hope is that contributors will come forward _when_ it is released.  i'm 
counting on the "snowball" effect :-)


cheers;
rsn


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