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

From: David Brownell <[email-masked]>
Date: Mon, 03 Dec 2001 20:42:44 -0800

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.

---

From: "Raif S. Naffah" <[email-masked]>
Date: Tue, 04 Dec 2001 19:37:04 +1100

>       good HTML, though the MathML output may be a

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

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

>       not an immediate issue, but static linking will increasingly

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

>     - Seems that widely used hashes (MD5, SHA1; maybe MD2)

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

>       DES, 3DES-EDE; likely Blowfish; maybe CAST128.

same thing.

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

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

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

>API framework starts out immediately on the right foot.

good to hear :-)

>   And

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.

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

>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

---

From: "Nic Ferrier" <[email-masked]>
Date: Tue, 4 Dec 2001 11:56:09 -0000

>       like even one of those, sorry.

I agree with Dave, but the coding standard is relaxed here at ClasspathX. We
don't force people to use the GNU style (though I might in the future do a
batch update of the CVS with a style enforcer I will do it only with
people's agreement).

I hate hungarian for java code. It just seems dumb to me... but I'm not
prepared to force you guys to change it.

>       good HTML, though the MathML output may be a

Actually Dave, it's:  "info where possible please".

When there is an info generator for docbook I'll be happy for people to have
their documentation in docbook, until then I meerly tolerate it   /8->

I don't think the PDFs are generated by the project. If they are we must use
something else. We might still have to ditch them and link to them elsewhere
(which seems sensible anyway, if they're someone else's files).

>       package is there and how to use it.

We'll have to think about the "links to PDFs" in light of my comments above.

>       not an immediate issue, but static linking will increasingly

All code should be GPL + library exception.

Nic

---

From: "Nic Ferrier" <[email-masked]>
Date: Tue, 4 Dec 2001 12:02:11 -0000

> counting on the "snowball" effect :-)

Absolutely... release early and often...

Having said that the most popular ciphers are the ones that will encourage
the most use.

Nic

---

From: David Brownell <[email-masked]>
Date: Tue, 04 Dec 2001 10:38:56 -0800

> Actually Dave, it's:  "info where possible please".

OK, so I'm a heretic who things "info" should go away in favor
of a much more widely adopted standard, "HTML" ... :)

I guess I'm content to have the PDFs just survive as links
on the web page.  Does that mean they'll move out of the
project CVS?

- Dave

---

From: Olivier LF <[email-masked]>
Date: Thu, 6 Dec 2001 22:14:40 +1100

On Mon, Dec 03, 2001 at 08:42:44PM -0800, David Brownell wrote:
>     - Coding style ... three space indents?  No tabs?

3 spaces is not so unusual, it does save some precious space if you want
to keep your code within the common 80 columns range. 

As for tabs, space is the lowest common denominator between editors.
The brain dead ones display 8 spaces for TAB!!! and the good ones can 
always be configured to emulate tabs with spaces.
Many projects require "space only" for that reason actually (Apache projects). 
It ensures you'll be able to work on the source no matter how modest 
your system and editor is. Back 6 years ago I used to edit files from 
home with a Minitel (A very cheap text terminal you get with the phone 
in France). It only supported line editing with "ed", those where the days...

Olivier

-- 
----------------------------------------------------------------------
Olivier Louchart-Fletcher
Email: [email-masked]

---

From: David Brownell <[email-masked]>
Date: Thu, 06 Dec 2001 13:19:08 -0800

> to keep your code within the common 80 columns range. 

And the counter-argument is that "four spaces" is much more common,
doesn't fight against standard 8-space tabstops, and is still "nicer" than
"indent == tab" for cases where nested code constructs "must" be used.

And I'll note that Linux coding style certainly says "indent == tab", and
notes that when that's awkward, the algorithm is the problem, not the
coding standard.  That tends to be very true, in my observation.  Kernel
code, like crypto code, is a domain where "simple is better" normally wins
against the more "deadline oriented" application domains where "done
now is better" wins ... it's "done now" that argues against restructuring
code to get rid of excessive nesting/indentation, and argues for narrow
indents.  (80/4 = max 20 levels/line, 80/3 = 26, either is too complex...)

Not that I want to start such style flamewars ... on the other hand
I think it's completely reasonable to say "three spaces" or "no tabs"
are guidelines that I've never subscribed to.  And I'll criticize them
every time it comes up, particularly when they're added as exceptions
to guidelines that are otherwise largely reasonable, since such style
guidelines do add up to 

> always be configured to emulate tabs with spaces.

Displaying 8 spaces for tabstops is not the same as storing them
that way.  Some editors will silently correct spelling "mistakes"
for you too, and store the results.  I don't like either behavior.  In
both cases using a Real Text Editor is a reasonable requirement.

Think of tabs as an 8-to-1 compression scheme built in to the
standard text file format.

> Many projects require "space only" for that reason actually (Apache projects). 

The original motivation I heard for that was that a number of
early contributors didn't want to switch from Win32 editors which,
to this day, are often unable to handle tabbing correctly.
(MSFT discourages widespread use of monospaced fonts
and "ASCII art" tools.  Never mind that interop with other
operating systems gets worse that way.)

Many non-Apache projects still expect that Real Text Editors
will be used ... which know how to handle tabs! :)

- Dave