[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Classpathx-crypto] quick comments on gnu.crypto code
From: |
Raif S. Naffah |
Subject: |
Re: [Classpathx-crypto] quick comments on gnu.crypto code |
Date: |
Tue, 04 Dec 2001 19:37:04 +1100 |
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.