your gnupg patches

[Werner Koch]

[You may have noticed that we had some problems with Mailman the last
days; this is hopefully now resolved.  If one of your postings didn't
show up, please resend it. ]

- ----------  Forwarded Message  ----------

Subject: Re: your gnupg patches
Date: March 29, 2004 12:17 am
From: Tom St Denis <tom at securescience.net>
To: gnupg-devel at gnupg.org

- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On March 28, 2004 10:38 am, Werner Koch wrote:
> Hi Tom,
>
> I have heard about your complaints from a third party and like to
> comment on that.
>
> I have once heard about your project on the former coderpunks list but
> I am not aware about any posting send to me.  If you send something to
> the webmasters, they will probably have asked you to send it to
> gnupg-devel at gnupg.org.  Given that you are not subscribed there it
> might have happen that your message was accidently not approved -
> given the current percentage of spam we receive and the bugs in
> Mailman, this is very likely.

I did email the webmaster and the list.

> However, the AUTHORS files tells you the address of the maintainer
>
>  Program: GnuPG
>  Maintainer:  Werner Koch <wk at gnupg.org>
>  Bug reports: bug-gnupg at gnu.org
>  Security related bug reports: security at gnupg.org

I didn't notice that.  Mostly because I was simply looking in the cipher
directory to clean up that code.

> and I can't remember that I recently received a message by you (modulo
> accidently spam filtering) or noticed one to the bug list.

I emailed three different "accounts" about the patches.  I even tried to fill
in a "BTS PR" form as suggested by the webmaster [the submission failed...].

I posted the patches to sci.crypt as well....

Not like I was hiding here.

> Regarding your patches: I have not seen them and I would be reluctant
> to add them to the stable branch if they do not address serious
> problems.  They might be useful for Libgcrypt, though.

Why?  I took the non-portable and messy code and cleaned it up.  While I
didn't fix readily exploitable bugs having cleaner code is a desireable goal
right?

> Even if I'd like to add them, I have to ask you for a copyright
> assignment to the FSF - this is what core GNU software always requires.
> I am not so sure whether you would sign this given the quote from your
> website "Normally I release all of my work under a public domain
> license but in this case you guys can have it for yer silly GPL-2 ;-)"
> - you know that there is no public domain in many countries before 70
> years after the death of the author.

Well I'd think that a public release would inherently fall under the GPL
 since the GPL mandates that.

> Nevertheless, would you mind to describe what you mean by
>
>   "I changed out some questionable load/store code with portable
>   macros"

You had things like

[from /cipher/blowfish.c]
#ifdef BIG_ENDIAN_HOST
    a = ((byte*)&x)[0];
    b = ((byte*)&x)[1];
    c = ((byte*)&x)[2];
    d = ((byte*)&x)[3];
#else
    a = ((byte*)&x)[3];
    b = ((byte*)&x)[2];
    c = ((byte*)&x)[1];
    d = ((byte*)&x)[0];
#endif

Which is not portable.  A "u32" must be *at least* 32-bits and a "byte" must
be *at least* 8-bits.  There are no portable C types of a given exact size
[specifically because some platforms don't natively support anything other
than a machine register, e.g. the ARM IIRC].

Not only that but my replacement code

[from /cipher/blowfish.c]
/* TSD: Big/Little endianess are not guarantees!
 *
 * Also "byte" is not guranteed to be 8-bits so the original code is not
always gonna work
 */
    a = (x >> 24UL) & 255;
    b = (x >> 16UL) & 255;
    c = (x >> 8UL ) & 255;
    d = x & 255;
    return ((bc->s0[a] + bc->s1[b]) ^ bc->s2[c] ) + bc->s3[d];

Is shorter, portable and more ameniable to platforms without shorter data
types.

I did such changes to essentially all of the ciphers/hashes.  I also added
test vectors to the hashes, made testing part of the initialization process
[e.g. when GPG registers the hash/ciphers so a user/tester doesn't have to
specifically --cipher-algo [etc] to test them].  I replaced your AES code
with a much cleaner portable implementation.  I finally added the macros for
cipher/hash identifiers instead of using constants like 7 for AES128
[etc...].

Note that I never expected the development team to drop everything you're
doing and auto-merge my patches in.  Ideally I was expecting a reply the same
day and maybe see them in the next stable release.  However, if all I get as
a reward of spending 6 hours writing patches [and porting over my public
domain LibTomCrypt test vectors/AES code] is a wall of silence can you really
wonder why progress is slow?

The FSF exists for this very reason, to prevent dead-locks and barriers in
software development.  The fact that this is *GNU* PG should reflect this.

Note that I also don't have a vested interest in the crypto lib from GNUPG. 
 I do happen to have my own crypto library which has served myself [as well
 as many others] just fine.  I wrote these patches as a courtesy to the GNUPG
 team not as a justification for using the code.

Tom
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAZ7F/sP+tEsHHY0ARAiN7AJ9PugiPqJP4XYtLbN42u+5UxGi9rACbBWPi
1MYQvoe2lSWfWNpCOg1MWS0=
=Xjpq
- -----END PGP SIGNATURE-----

- -------------------------------------------------------