Re: [CryptoAPI-devel] Coding style, or something.

[David B. <db...@du...>]

Suggestions below...

On Fri, 29 Mar 2002, Kyle McMartin wrote:

> I'm going to, after consensus, begin modifying the code to conform to
> the standards that are the result of this thread.
>
> Most of this is secondary and can wait until after a release...
>
> To begin with, all code should follow the Linux kernels
> Documentation/CodingStyle, with 8 space hard tabs (I need to convert the
> code I've already written which uses soft tabs) and K&R style bracing.
>
> However, the real problem is the lack of unification in the design of
> the ciphers. A quick look into the ciphers/ direction reveals everything
> is implemented with different variable names, etc. The code should be
> modified to be uniform throughout.
>
I think we should also unify our design for how the symmetric ciphers
should be implemented.  Great evidence of this being a Good Thing(tm)
would be the difference between blowfish and des.  The actual encryption
code looks great, it's easy to read and understand:
ROUND(leftword,rightword,roundnumber)
If we could try to stick as close as possible to this design it would
improve the readability of the ciphers and give us some kind of common
thread among them, in addition to the changes proposed by kyle.

> I propose, therefore, that all cipher dependant code, be prefixed with
> the name of the cipher, ie: a context for the cipher like bf_ctx, would
> be Blowfish_CTX. Perhaps all cipher dependant defines, like KEYLEN,
> BLOCKSIZE, etc. could be prefixed with the cipher name as well.
>
> Now the more pressing matter, there are a number of patented and
> GPL licensed modules in cryptoapi. If we wish to release and have people
> integrate our code into their kernels (distributions, for example) we
> must have the entire main cryptoapi package under the GPL or
> dual-licensed. For example, Mandrake currently uses loop-AES, but would
> be unable to include cryptoapi in their kernel, since we have patented and
> non-free ciphers right there.
>
> To remedy this, I propose a directory hierarchy extension to the
> ciphers/ directory. For example, all free, mainline ciphers could stay
> in their current place, and we could have cryptoapi-patented and
> cryptoapi-nonfree extension tarballs which fill up ciphers/patented/ and
> ciphers/non-free/

The rest of it looks great.  Although we should inclue in the makefile a
"make GPL" or something similar, and a "make nonfree".

Dave