From lowhalo at hush.com  Thu Jun  3 00:04:53 2004
From: lowhalo at hush.com (low halo, Defender of Truth and Liberty)
Date: Sun Jun  6 18:42:49 2004
Subject: Win32 build
Message-ID: <200406022204.i52M4r7N061703@mailserver3.hushmail.com>

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



Hi --

    I've created a complete build system for libgpg-error and
libgcrypt for Windows.  Instead of fighting against autoconf
quirks, I wrote custom makefiles just for Windows builds.  The
Gaim project (http://gaim.sourceforge.net) does the same thing, and
its worked well for them for over a year.

    So, here's what you need to do if you want to build a
'libgcrypt.dll':

1.) Download and install Cygwin (http://www.cygwin.com).  Be sure to
install the 'make', 'patchutils', and 'perl' packages as well.

2.) Download and install MinGW (http://prdownloads.sf.net/mingw/
MinGW-3.1.0-1.exe?download).

3.) Start a Cygwin bash shell, and type:

    export PATH=/cygdrive/c/MinGW/bin:$PATH

.. assuming that you installed MinGW at the 'C:\' default.  This will
set your path so that later on you will compile everything with MinGW's
tools instead of Cygwin's.  If you start another shell later, remember
to re-set this PATH.

4.) Extract libgpg-error, and copy 'win32_gpg-error_makefiles.tar.bz2'
and 'win32_gpg-error.patch' into the newly-created
'libgpg-error-0.7' directory.  'cd' into this directory, and apply the
patch with:

    patch -p1 < win32_gpg-error.patch

Then extract the 'win32_gpg-error_makefiles.tar.bz2' file here too.

5.) Start building libgpg-error with:

    make -f Makefile.mingw

6.) Extract libgcrypt, and copy 'win32_gcrypt.patch' and
'win32_gcrypt_makefiles.tar.bz2' into the newly-created
'libgcrypt-1.2.0' directory.  'cd' into this directory, and apply the
patch with:

    patch -p1 < win32_gcrypt.patch

Then extract the 'win32_gcrypt_makefiles.tar.bz2' file here too.

7.) Start building libgcrypt with:

    make -f Makefile.mingw



.. and that's all there is to it!  You should end up with a
'libgcrypt.dll' file if you followed these instructions correctly.
There will also be EXEs in the tests/ subdirectory for you to play with.

    Over the next few days, I plan on improving the Win32 entropy
gatherer (rndw32.c) also.  Sit tight.

    - low halo

P.S.  To the libgcrypt/libgpg-error maintainers:  could you have a look
at my patches and consider them for inclusion into CVS?  Thanks!

- --
low halo <lowhalo at-s1gn hacktivismo d0t c0m>
Defender of Truth and Liberty
http://ultramagnetic.sourceforge.net/
http://www.hacktivismo.com/
 
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x3AFB17F6
9AB1 FF04 016F 89A3 5B4E  A585 BDBB 5FBE 3AFB 17F6

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Your Mother)

iD8DBQFAvlAVvbtfvjr7F/YRAh9vAJ9CHN9GeMOsisMBkNzfa9pStlBK3ACfZwbJ
warzBq/HO48whXTGp97N7hM=
=Rb9p
-----END PGP SIGNATURE-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: win32_stuff.tar.bz2
Type: application/x-bzip2
Size: 9826 bytes
Desc: not available
Url : /pipermail/attachments/20040602/57cbb556/win32_stuff.tar.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: win32_stuff.tar.bz2.sig
Type: application/octet-stream
Size: 65 bytes
Desc: not available
Url : /pipermail/attachments/20040602/57cbb556/win32_stuff.tar.bz2.exe
From marcus.brinkmann at ruhr-uni-bochum.de  Sun Jun  6 20:56:02 2004
From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann)
Date: Sun Jun  6 20:53:14 2004
Subject: Win32 build
In-Reply-To: <200406022204.i52M4r7N061703@mailserver3.hushmail.com>
References: <200406022204.i52M4r7N061703@mailserver3.hushmail.com>
Message-ID: <877jukh5x9.wl@ulysses.g10code.de>

At Wed,  2 Jun 2004 15:04:53 -0700,
low halo, Defender of Truth and Liberty wrote:
>     I've created a complete build system for libgpg-error and
> libgcrypt for Windows.  Instead of fighting against autoconf
> quirks, I wrote custom makefiles just for Windows builds.  The
> Gaim project (http://gaim.sourceforge.net) does the same thing, and
> its worked well for them for over a year.

Can you please fight against autoconf quirks (if they are that, and
not windows or ming32 quirks)?  I can't really see us baby-sitting
hand-written Makefiles for Windows.

Thanks,
Marcus

From t.fromm at DResearch.de  Mon Jun  7 18:06:51 2004
From: t.fromm at DResearch.de (Fromm, Thilo)
Date: Mon Jun  7 18:03:59 2004
Subject: Memory leak in gcry_pk_sign (libgcrypt v1.2.0)
Message-ID: <9DFFE5714304D71187480002B3286DDBA4DD78@trugat.intern.dresearch.de>

Hello list,

While playing with libgcrypt-1.2.0 I found a small memory leak in
cipher/pubkey.c, function gcry_pk_sign: "gcry_mpi_t * result" is freed
without having its resources freed first. The attached patch seems to fix
the problem. Please have a look at it -  I rather guessed there as I'm new
to libgcrypt land...

Sincerely,
Thilo


/* Dipl.-Ing. (FH) Thilo Fromm, MSc., Hardware & Software
 * DResearch Digital Media Systems GmbH
 * Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
 * Tel: +49 (30) 515932-228  mailto:t.fromm@dresearch.de
 * Fax: +49 (30) 515932-299      http://www.dresearch.de  */

-------------- next part --------------
A non-text attachment was scrubbed...
Name: lgc-1.2.0-pubkey.patch
Type: application/octet-stream
Size: 401 bytes
Desc: not available
Url : /pipermail/attachments/20040607/4b96db6f/lgc-1.2.0-pubkey-0001.exe
From lowhalo at hush.com  Tue Jun  8 04:47:38 2004
From: lowhalo at hush.com (low halo, Defender of Truth and Liberty)
Date: Tue Jun  8 04:44:46 2004
Subject: Win32 build
Message-ID: <200406080247.i582ldDH044775@mailserver2.hushmail.com>

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


> I can't really see us baby-sitting hand-written Makefiles for
> Windows.

Can _I_ baby-sit the Windows Makefiles?  My project is very
dependent upon a working Win32 version, and so you can count on
me sticking around.

    - low halo

- --
low halo <lowhalo at-s1gn hacktivismo d0t c0m>
Defender of Truth and Liberty
http://ultramagnetic.sourceforge.net/
http://www.hacktivismo.com/
 
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x3AFB17F6
9AB1 FF04 016F 89A3 5B4E  A585 BDBB 5FBE 3AFB 17F6

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Your Mother)

iD8DBQFAxSgivbtfvjr7F/YRAkvOAJ45Jk6v3VH/VBv2zknpP/GmY9zAhQCeP92n
LbBHC/+lJfdYhLPV7KdtZLU=
=QT4Y
-----END PGP SIGNATURE-----




Concerned about your privacy? Follow this link to get
FREE encrypted email: https://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
https://www.hushmail.com/services.php?subloc=messenger&l=434

Promote security and make money with the Hushmail Affiliate Program: 
https://www.hushmail.com/about.php?subloc=affiliate&l=427

From lowhalo at hush.com  Tue Jun  8 04:59:40 2004
From: lowhalo at hush.com (low halo, Defender of Truth and Liberty)
Date: Tue Jun  8 04:56:46 2004
Subject: A useful test prog
Message-ID: <200406080259.i582xjbc045826@mailserver2.hushmail.com>

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


Attached is a test prog for the tests/ subdir.  This small prog
will dump a specified number of random bytes to a file for use
by statistical analyzers.  Note that you'll need to modify the
Makefile.am file so that it will automatically compile.

I wrote this while testing my changes to the Win32 entropy
gatherer.  I figure that other people might be interested in
running their own tests.

I offer this code under the LGPL.  I can also relinquish my
copyright upon it if the libgcrypt team chooses to include it
in the official package.

    - low halo

- --
low halo <lowhalo at-s1gn hacktivismo d0t c0m>
Defender of Truth and Liberty
http://ultramagnetic.sourceforge.net/
http://www.hacktivismo.com/
 
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x3AFB17F6
9AB1 FF04 016F 89A3 5B4E  A585 BDBB 5FBE 3AFB 17F6

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Your Mother)

iD8DBQFAxStQvbtfvjr7F/YRAsLKAJ0dzUAQpx85G63wqp9eGu90pBBfYgCdGn+A
f6Cujde8xc10TcKBPVMLMSg=
=axdu
-----END PGP SIGNATURE-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: random.c.sig
Type: application/octet-stream
Size: 65 bytes
Desc: not available
Url : /pipermail/attachments/20040607/01dc01ef/random.c.exe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: random.c
Type: application/octet-stream
Size: 2607 bytes
Desc: not available
Url : /pipermail/attachments/20040607/01dc01ef/random.exe
From marcus.brinkmann at ruhr-uni-bochum.de  Tue Jun  8 20:10:40 2004
From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann)
Date: Tue Jun  8 20:08:14 2004
Subject: Win32 build
In-Reply-To: <200406080247.i582ldDH044775@mailserver2.hushmail.com>
References: <200406080247.i582ldDH044775@mailserver2.hushmail.com>
Message-ID: <87llix6hun.wl@ulysses.g10code.de>

At Mon,  7 Jun 2004 19:47:38 -0700,
low halo, Defender of Truth and Liberty wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> > I can't really see us baby-sitting hand-written Makefiles for
> > Windows.
> 
> Can _I_ baby-sit the Windows Makefiles?  My project is very
> dependent upon a working Win32 version, and so you can count on
> me sticking around.

Well, of course you can babysit them.  But the requirements for
inclusion into our main source tree include that we are willing to
accept responsibility for the code and maintain it even if you abandon
it.

This alone is not a reason against including it per se, but it
increases the barrier.  The real reason not to include it is that we
_want_ to use autoconf consistently.  It's the right thing to do, and
there should be no major obstacle in the way.

I don't know why you think that this is any harder than writing custom
makefiles.  I know that autoconf has a somewhat steep learning curve,
but by all means, if you stumble upon something that you can't easily
resolve with the existing examples in gpg or with the instructions in
the manual, you are more than welcome to raise them here on the
mailing list so we can help you out or discuss alternatives.  Everyone
of us had their own hair-pulling autoconf adventure, but that's no
reason to just bypass it a priori.

Thanks,
Marcus

From wk at gnupg.org  Tue Jun  8 21:54:00 2004
From: wk at gnupg.org (Werner Koch)
Date: Tue Jun  8 21:50:57 2004
Subject: A useful test prog
In-Reply-To: <200406080259.i582xjbc045826@mailserver2.hushmail.com> (low
	halo's message of "Mon,  7 Jun 2004 19:59:40 -0700")
References: <200406080259.i582xjbc045826@mailserver2.hushmail.com>
Message-ID: <87k6yhbzc7.fsf@vigenere.g10code.de>

On Mon,  7 Jun 2004 19:59:40 -0700, low halo, Defender of Truth and Liberty said:

> Attached is a test prog for the tests/ subdir.  This small prog
> will dump a specified number of random bytes to a file for use
> by statistical analyzers.  Note that you'll need to modify the

It is a common mistake to believe that any statictical analysys will
give you information on the quality of an RNG like the one used in
GnuPG.  Note, that the output is passed through a hash function and
the only thing you may be able to check is whether the hash function
works as desired.

To analyse a RNG you have to scrutinize the code.


Salam-Shalom,

   Werner


From lowhalo at hush.com  Wed Jun  9 03:23:41 2004
From: lowhalo at hush.com (low halo, Defender of Truth and Liberty)
Date: Wed Jun  9 03:20:49 2004
Subject: A useful test prog
Message-ID: <200406090123.i591NgbK016893@mailserver3.hushmail.com>

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



> To analyse a RNG you have to scrutinize the code.

I agree with you here, but I believe that black-box testing
the PRNG can give you a separate (and useful) point of view.
The DIEHARD and ENT tests cannot tell you that the PRNG is
good, but they can hint that there is a problem--one that
your eyes perhaps missed during the code review.

Given that (almost) all cryptographic operations depend
upon random numbers, I think that it is worth it to take the
extra step and run the bytes through analyzers.  There just
seems too much at risk to neglect this step.

    - low halo

- --
low halo <lowhalo at-s1gn hacktivismo d0t c0m>
Defender of Truth and Liberty
http://ultramagnetic.sourceforge.net/
http://www.hacktivismo.com/
 
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x3AFB17F6
9AB1 FF04 016F 89A3 5B4E  A585 BDBB 5FBE 3AFB 17F6
 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Your Mother)

iD8DBQFAxmYdvbtfvjr7F/YRAqsSAJ0WqGlCXyw5D5onGruRfsXH1ElM/wCfdgtJ
WI6ZRI19ngAO1dkzzBigwrk=
=WoEk
-----END PGP SIGNATURE-----




Concerned about your privacy? Follow this link to get
FREE encrypted email: https://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
https://www.hushmail.com/services.php?subloc=messenger&l=434

Promote security and make money with the Hushmail Affiliate Program: 
https://www.hushmail.com/about.php?subloc=affiliate&l=427

From lowhalo at hush.com  Wed Jun  9 03:25:37 2004
From: lowhalo at hush.com (low halo, Defender of Truth and Liberty)
Date: Wed Jun  9 03:22:46 2004
Subject: Win32 build
Message-ID: <200406090125.i591PdVH017041@mailserver3.hushmail.com>

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



> we _want_ to use autoconf consistently.

Very well.  I will try my hand at it again.

What environment do you want me to do this in?  Last time
I tried this, I noticed that MSYS + MinGW had a seperate
set of quirks vs. Cygwin + MinGW.  I personally vote for the
MSYS + MinGW (unless it turns out to be harder =P).

    - low halo

- --
low halo <lowhalo at-s1gn hacktivismo d0t c0m>
Defender of Truth and Liberty
http://ultramagnetic.sourceforge.net/
http://www.hacktivismo.com/
 
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x3AFB17F6
9AB1 FF04 016F 89A3 5B4E  A585 BDBB 5FBE 3AFB 17F6
 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Your Mother)

iD8DBQFAxmXfvbtfvjr7F/YRAnX3AJ0conwKTdUOL55wJl1bOKaDFtkp8ACfYOHA
axqkDtxA7Ya6vmSJKpo1KYA=
=o8uN
-----END PGP SIGNATURE-----




Concerned about your privacy? Follow this link to get
FREE encrypted email: https://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
https://www.hushmail.com/services.php?subloc=messenger&l=434

Promote security and make money with the Hushmail Affiliate Program: 
https://www.hushmail.com/about.php?subloc=affiliate&l=427

From marcus.brinkmann at ruhr-uni-bochum.de  Wed Jun  9 06:34:44 2004
From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann)
Date: Wed Jun  9 06:32:22 2004
Subject: Win32 build
In-Reply-To: <200406090125.i591PdVH017041@mailserver3.hushmail.com>
References: <200406090125.i591PdVH017041@mailserver3.hushmail.com>
Message-ID: <87fz955oyj.wl@ulysses.g10code.de>

At Tue,  8 Jun 2004 18:25:37 -0700,
low halo, Defender of Truth and Liberty wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> > we _want_ to use autoconf consistently.
> 
> Very well.  I will try my hand at it again.
> 
> What environment do you want me to do this in?  Last time
> I tried this, I noticed that MSYS + MinGW had a seperate
> set of quirks vs. Cygwin + MinGW.  I personally vote for the
> MSYS + MinGW (unless it turns out to be harder =P).

As far as I understand it the idea is to cross compile from GNU/Linux
to MS Windows using GNU/Linux and Werner's hacked MingW.  I guess this
is matched closer by Cygwin+MinGW.  I suggest not to bend over
backwards to get it working in MSYS (unless you want to improve MSYS
until it is capable of doing the job).

Thanks,
Marcus




From wk at gnupg.org  Wed Jun  9 14:15:35 2004
From: wk at gnupg.org (Werner Koch)
Date: Wed Jun  9 14:15:55 2004
Subject: Win32 build
In-Reply-To: <87fz955oyj.wl@ulysses.g10code.de> (Marcus Brinkmann's message
	of "Wed, 09 Jun 2004 06:34:44 +0200")
References: <200406090125.i591PdVH017041@mailserver3.hushmail.com>
	<87fz955oyj.wl@ulysses.g10code.de>
Message-ID: <87llix9bbs.fsf@vigenere.g10code.de>

On Wed, 09 Jun 2004 06:34:44 +0200, Marcus Brinkmann said:

> As far as I understand it the idea is to cross compile from GNU/Linux
> to MS Windows using GNU/Linux and Werner's hacked MingW.  I guess this

Just for the record: mingw32/cpd is older than the mingw.org thing
used today.  They both stem from Colin Peter's orginal mingw32.

Marcus is right, we do not want to support anything else than
mingw32/cpd.  The reasons for this are: Less modifications to the
source, if something useful is missing we can add it to the
mingw32/cpd and we use the same build environment for all platforms.
This ain't no problem because that libgcrypt.dll shall be a
self-contained W32 API thing (except for the parts were we can't do it
(entropy gatherer)).

> is matched closer by Cygwin+MinGW.  I suggest not to bend over
> backwards to get it working in MSYS (unless you want to improve MSYS

There are subtle incompatibilities between the different environments
and you need to make sure that all parts of GnuPG are build in the
same environment.  A Cygwin GnuPG and a MSYS GPGME won't work in all
cases.

  Werner



From wk at gnupg.org  Wed Jun  9 14:17:08 2004
From: wk at gnupg.org (Werner Koch)
Date: Wed Jun  9 14:16:02 2004
Subject: A useful test prog
In-Reply-To: <200406090123.i591NgbK016893@mailserver3.hushmail.com> (low
	halo's message of "Tue,  8 Jun 2004 18:23:41 -0700")
References: <200406090123.i591NgbK016893@mailserver3.hushmail.com>
Message-ID: <87hdtl9b97.fsf@vigenere.g10code.de>

On Tue,  8 Jun 2004 18:23:41 -0700, low halo, Defender of Truth and Liberty said:

> I agree with you here, but I believe that black-box testing
> the PRNG can give you a separate (and useful) point of view.
> The DIEHARD and ENT tests cannot tell you that the PRNG is

Just compress a few K of random and you will note a fatal flwa
immediatley.  Diehard is useless overkill.

  Werner


From craig at twolips-translations.co.uk  Fri Jun 11 15:29:32 2004
From: craig at twolips-translations.co.uk (Craig Graham)
Date: Tue Jun 15 08:49:41 2004
Subject: GPGME and callbacks
Message-ID: <023b01c44fb8$2135b080$fe01010a@craigloft>

I have another gpgme problem.

The language I'm using (Labview) doesn't seem to do callbacks.This gives me
a problem in generating a signature since I cannot provide a callback
function in order to obtain the pass phrase. I need a mechanism by which I
can send the pass phrase through myself, either by pre-loading it into the
library as is done with the signing keys, or by passing it as one of the
arguments to a sign function.

Does a mechanism already exist for this, or do I have to change the library
myself?

--
Dr. Craig Graham, Software Engineer
Advanced Analysis and Integration Limited, UK. http://www.aail.co.uk/




From steven_n_truong at yahoo.com  Fri Jun 11 23:59:19 2004
From: steven_n_truong at yahoo.com (Steven Truong)
Date: Tue Jun 15 14:48:55 2004
Subject: newbie needs helps
Message-ID: <20040611215919.80955.qmail@web52103.mail.yahoo.com>

Hi, everybody.  I am interested in developing some
multi-threaded apps that would use the AES in Linux
Fedora FC2 PC. However, I have not been able to use
AES alone just to encrypt some files for testing.
Here is what I do:

After setting the handle I would pick the cipher and
specified CBC mode and CBC_CTS for AES256 using
cipher_open. Then do a get_algo_keylen, and setkey (my
key is of 128/8 bits.  Then I would setiv(handle, HDD,
NULL, 0) and then read from file and do encrypting.  I
would ask if this is the right sequence because I
studies the tests/basic.c to do this.  I think it is
right. However, since I also set CBC_CTS, but I got
error for the last block of the file that is less than
16 bytes and I have to pad it up with something to
have 16 byte block.  What is wrong?  Did I miss
something or misunderstand anything?  For decryption,
I followed the same sequence, except I don't worry
about the last block size since ....

My other question is I plan to use Pthread, however,
after reading the mailing list about
>> > gnunetd: ath.c:181: _gcry_ath_mutex_lock:
Assertion `*lock ==
>> > ((ath_mutex_t) 0)' failed.
 I saw that we have this file ath.c (thread-safeness
library).  So what this file and the api?  Only for
internal use right because no exported apis in the
gcrypt.info and etc...  

I would like to see more examples of how to use
symmetric encryption/decryption as well as how to use
Pthread to work with libgcrypt-1.20.  Could you please
give me some pointers to what sources with these
information so I can learn more?

Thank you very much.
Steven.


	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 

From jas at extundo.com  Tue Jun 15 15:33:38 2004
From: jas at extundo.com (Simon Josefsson)
Date: Tue Jun 15 15:37:56 2004
Subject: newbie needs helps
References: <20040611215919.80955.qmail@web52103.mail.yahoo.com>
Message-ID: <ilu4qpdaqtp.fsf@latte.josefsson.org>

Steven Truong <steven_n_truong@yahoo.com> writes:

> Hi, everybody.  I am interested in developing some
> multi-threaded apps that would use the AES in Linux
> Fedora FC2 PC. However, I have not been able to use
> AES alone just to encrypt some files for testing.
> Here is what I do:
>
> After setting the handle I would pick the cipher and
> specified CBC mode and CBC_CTS for AES256 using
> cipher_open. Then do a get_algo_keylen, and setkey (my
> key is of 128/8 bits.  Then I would setiv(handle, HDD,
> NULL, 0) and then read from file and do encrypting.  I
> would ask if this is the right sequence because I
> studies the tests/basic.c to do this.  I think it is
> right. However, since I also set CBC_CTS, but I got
> error for the last block of the file that is less than
> 16 bytes and I have to pad it up with something to
> have 16 byte block.  What is wrong?  Did I miss
> something or misunderstand anything?  For decryption,
> I followed the same sequence, except I don't worry
> about the last block size since ....

It is not clear if you intend to use CBC with Cipher Text Stealing
(CTS).  Not many application use this.  If you don't need it, you will
likely get a mismatch on the last bock.  So I guess the question is
whether you want CBC or CBC-CTS?

It isn't unlikely that the CTS behaviour is incorrect, the test
vectors used in the self tests is from only one source.  If you really
want CBC-CTS, do you have any test vectors for your application?


From lowhalo at hush.com  Mon Jun 21 16:26:07 2004
From: lowhalo at hush.com (low halo, Defender of Truth and Liberty)
Date: Mon Jun 21 16:23:11 2004
Subject: mingw/cpd problem
Message-ID: <200406211426.i5LEQ7SE007747@mailserver2.hushmail.com>

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

Hi --

    With mingw/cpd, I've successfully compiled a 'libgcrypt.a'.  My
next step is to create a 'libgcrypt.dll', but the instructions on
how to do so in mingw/cpd's README file are quite vague.  The best
I've been able to do results in creating an EXE file instead of a 
DLL (!):

    mingw32 gcc -c -dll test.c
    mingw32 gcc -Wl,--base-file=a.base test.o
    mingw32 dlltool --as `mingw32 --get-path as` --base-file a.base \
        -e exports.o test.o
    mingw32 gcc test.o exports.o -o test.dll

    What am I doing wrong?

    -- low halo

P.S. The 'WkLib' package fails to compile on Debian stable (3.0r2).
Bit-rot, I guess?

- --
low halo <lowhalo at-s1gn hacktivismo d0t c0m>
Defender of Truth and Liberty
http://ultramagnetic.sourceforge.net/
http://www.hacktivismo.com/
 
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x3AFB17F6
9AB1 FF04 016F 89A3 5B4E  A585 BDBB 5FBE 3AFB 17F6

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Your Mother)

iD8DBQFAy7+kvbtfvjr7F/YRAvqDAJ9ACkyZFGzDlKdVX3sxXzcM7rN0nwCeKIa8
jU7Xc+8xbsQ96T+u0nUAb6Q=
=nAs3
-----END PGP SIGNATURE-----




Concerned about your privacy? Follow this link to get
secure FREE email: http://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
http://www.hushmail.com/services.php?subloc=messenger&l=434

Promote security and make money with the Hushmail Affiliate Program: 
http://www.hushmail.com/about.php?subloc=affiliate&l=427

From robey at danger.com  Fri Jun 25 01:16:24 2004
From: robey at danger.com (Robey Pointer)
Date: Tue Jun 29 15:20:06 2004
Subject: patch for libgcrypt 1.2.0 on pthreads
Message-ID: <40DB60C8.7050100@danger.com>

The new 1.2.0 gcrypt release has an include file that won't build if you 
use GCRY_THREAD_OPTION_PTHREAD_IMPL because the types are wrong, and the 
pthread struct isn't completely filled out.  Here's the patch.

robey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: libcrypt-pthreads.diff
Type: text/x-patch
Size: 1575 bytes
Desc: not available
Url : /pipermail/attachments/20040624/81ed0bee/libcrypt-pthreads.bin
From sturm at sec.informatik.tu-darmstadt.de  Tue Jun 22 05:14:38 2004
From: sturm at sec.informatik.tu-darmstadt.de (Nikolay Sturm)
Date: Tue Jun 29 16:22:36 2004
Subject: serpent fix for sparc64
Message-ID: <20040622031438.GB18868@marvin.sec.informatik.tu-darmstadt.de>

Hi!

Following diff fixes serpent on sparc64/OpenBSD. (please cc me in
answers, as I am not subscribed)

--- cipher/serpent.c.orig	Mon Jun 21 17:49:22 2004
+++ cipher/serpent.c	Mon Jun 21 17:50:05 2004
@@ -78,8 +78,8 @@ typedef struct serpent_context
 
 #define SBOX0(a, b, c, d, w, x, y, z) \
   { \
-    register unsigned long t02, t03, t05, t06, t07, t08, t09; \
-    register unsigned long t11, t12, t13, t14, t15, t17, t01; \
+    register u32_t t02, t03, t05, t06, t07, t08, t09; \
+    register u32_t t11, t12, t13, t14, t15, t17, t01; \
     t01 = b   ^ c  ; \
     t02 = a   | d  ; \
     t03 = a   ^ b  ; \
@@ -102,8 +102,8 @@ typedef struct serpent_context
 
 #define SBOX0_INVERSE(a, b, c, d, w, x, y, z) \
   { \
-    register unsigned long t02, t03, t04, t05, t06, t08, t09, t10; \
-    register unsigned long t12, t13, t14, t15, t17, t18, t01; \
+    register u32_t t02, t03, t04, t05, t06, t08, t09, t10; \
+    register u32_t t12, t13, t14, t15, t17, t18, t01; \
     t01 = c   ^ d  ; \
     t02 = a   | b  ; \
     t03 = b   | c  ; \
@@ -127,8 +127,8 @@ typedef struct serpent_context
 
 #define SBOX1(a, b, c, d, w, x, y, z) \
   { \
-    register unsigned long t02, t03, t04, t05, t06, t07, t08; \
-    register unsigned long t10, t11, t12, t13, t16, t17, t01; \
+    register u32_t t02, t03, t04, t05, t06, t07, t08; \
+    register u32_t t10, t11, t12, t13, t16, t17, t01; \
     t01 = a   | d  ; \
     t02 = c   ^ d  ; \
     t03 =     ~ b  ; \
@@ -151,8 +151,8 @@ typedef struct serpent_context
 
 #define SBOX1_INVERSE(a, b, c, d, w, x, y, z) \
   { \
-    register unsigned long t02, t03, t04, t05, t06, t07, t08; \
-    register unsigned long t09, t10, t11, t14, t15, t17, t01; \
+    register u32_t t02, t03, t04, t05, t06, t07, t08; \
+    register u32_t t09, t10, t11, t14, t15, t17, t01; \
     t01 = a   ^ b  ; \
     t02 = b   | d  ; \
     t03 = a   & c  ; \
@@ -175,8 +175,8 @@ typedef struct serpent_context
 
 #define SBOX2(a, b, c, d, w, x, y, z) \
   { \
-    register unsigned long t02, t03, t05, t06, t07, t08; \
-    register unsigned long t09, t10, t12, t13, t14, t01; \
+    register u32_t t02, t03, t05, t06, t07, t08; \
+    register u32_t t09, t10, t12, t13, t14, t01; \
     t01 = a   | c  ; \
     t02 = a   ^ b  ; \
     t03 = d   ^ t01; \
@@ -197,8 +197,8 @@ typedef struct serpent_context
 
 #define SBOX2_INVERSE(a, b, c, d, w, x, y, z) \
   { \
-    register unsigned long t02, t03, t04, t06, t07, t08, t09; \
-    register unsigned long t10, t11, t12, t15, t16, t17, t01; \
+    register u32_t t02, t03, t04, t06, t07, t08, t09; \
+    register u32_t t10, t11, t12, t15, t16, t17, t01; \
     t01 = a   ^ d  ; \
     t02 = c   ^ d  ; \
     t03 = a   & c  ; \
@@ -221,8 +221,8 @@ typedef struct serpent_context
 
 #define SBOX3(a, b, c, d, w, x, y, z) \
   { \
-    register unsigned long t02, t03, t04, t05, t06, t07, t08; \
-    register unsigned long t09, t10, t11, t13, t14, t15, t01; \
+    register u32_t t02, t03, t04, t05, t06, t07, t08; \
+    register u32_t t09, t10, t11, t13, t14, t15, t01; \
     t01 = a   ^ c  ; \
     t02 = a   | d  ; \
     t03 = a   & d  ; \
@@ -245,8 +245,8 @@ typedef struct serpent_context
 
 #define SBOX3_INVERSE(a, b, c, d, w, x, y, z) \
   { \
-    register unsigned long t02, t03, t04, t05, t06, t07, t09; \
-    register unsigned long t11, t12, t13, t14, t16, t01; \
+    register u32_t t02, t03, t04, t05, t06, t07, t09; \
+    register u32_t t11, t12, t13, t14, t16, t01; \
     t01 = c   | d  ; \
     t02 = a   | d  ; \
     t03 = c   ^ t02; \
@@ -268,8 +268,8 @@ typedef struct serpent_context
 
 #define SBOX4(a, b, c, d, w, x, y, z) \
   { \
-    register unsigned long t02, t03, t04, t05, t06, t08, t09; \
-    register unsigned long t10, t11, t12, t13, t14, t15, t16, t01; \
+    register u32_t t02, t03, t04, t05, t06, t08, t09; \
+    register u32_t t10, t11, t12, t13, t14, t15, t16, t01; \
     t01 = a   | b  ; \
     t02 = b   | c  ; \
     t03 = a   ^ t02; \
@@ -293,8 +293,8 @@ typedef struct serpent_context
 
 #define SBOX4_INVERSE(a, b, c, d, w, x, y, z) \
   { \
-    register unsigned long t02, t03, t04, t05, t06, t07, t09; \
-    register unsigned long t10, t11, t12, t13, t15, t01; \
+    register u32_t t02, t03, t04, t05, t06, t07, t09; \
+    register u32_t t10, t11, t12, t13, t15, t01; \
     t01 = b   | d  ; \
     t02 = c   | d  ; \
     t03 = a   & t01; \
@@ -316,8 +316,8 @@ typedef struct serpent_context
 
 #define SBOX5(a, b, c, d, w, x, y, z) \
   { \
-    register unsigned long t02, t03, t04, t05, t07, t08, t09; \
-    register unsigned long t10, t11, t12, t13, t14, t01; \
+    register u32_t t02, t03, t04, t05, t07, t08, t09; \
+    register u32_t t10, t11, t12, t13, t14, t01; \
     t01 = b   ^ d  ; \
     t02 = b   | d  ; \
     t03 = a   & t01; \
@@ -339,8 +339,8 @@ typedef struct serpent_context
 
 #define SBOX5_INVERSE(a, b, c, d, w, x, y, z) \
   { \
-    register unsigned long t02, t03, t04, t05, t07, t08, t09; \
-    register unsigned long t10, t12, t13, t15, t16, t01; \
+    register u32_t t02, t03, t04, t05, t07, t08, t09; \
+    register u32_t t10, t12, t13, t15, t16, t01; \
     t01 = a   & d  ; \
     t02 = c   ^ t01; \
     t03 = a   ^ d  ; \
@@ -362,8 +362,8 @@ typedef struct serpent_context
 
 #define SBOX6(a, b, c, d, w, x, y, z) \
   { \
-    register unsigned long t02, t03, t04, t05, t07, t08, t09, t10; \
-    register unsigned long t11, t12, t13, t15, t17, t18, t01; \
+    register u32_t t02, t03, t04, t05, t07, t08, t09, t10; \
+    register u32_t t11, t12, t13, t15, t17, t18, t01; \
     t01 = a   & d  ; \
     t02 = b   ^ c  ; \
     t03 = a   ^ d  ; \
@@ -387,8 +387,8 @@ typedef struct serpent_context
 
 #define SBOX6_INVERSE(a, b, c, d, w, x, y, z) \
   { \
-    register unsigned long t02, t03, t04, t05, t06, t07, t08, t09; \
-    register unsigned long t12, t13, t14, t15, t16, t17, t01; \
+    register u32_t t02, t03, t04, t05, t06, t07, t08, t09; \
+    register u32_t t12, t13, t14, t15, t16, t17, t01; \
     t01 = a   ^ c  ; \
     t02 =     ~ c  ; \
     t03 = b   & t01; \
@@ -412,8 +412,8 @@ typedef struct serpent_context
 
 #define SBOX7(a, b, c, d, w, x, y, z) \
   { \
-    register unsigned long t02, t03, t04, t05, t06, t08, t09, t10; \
-    register unsigned long t11, t13, t14, t15, t16, t17, t01; \
+    register u32_t t02, t03, t04, t05, t06, t08, t09, t10; \
+    register u32_t t11, t13, t14, t15, t16, t17, t01; \
     t01 = a   & c  ; \
     t02 =     ~ d  ; \
     t03 = a   & t02; \
@@ -437,8 +437,8 @@ typedef struct serpent_context
 
 #define SBOX7_INVERSE(a, b, c, d, w, x, y, z) \
   { \
-    register unsigned long t02, t03, t04, t06, t07, t08, t09; \
-    register unsigned long t10, t11, t13, t14, t15, t16, t01; \
+    register u32_t t02, t03, t04, t06, t07, t08, t09; \
+    register u32_t t10, t11, t13, t14, t15, t16, t01; \
     t01 = a   & b  ; \
     t02 = a   | b  ; \
     t03 = c   | t01; \

From wk at gnupg.org  Tue Jun 29 16:19:07 2004
From: wk at gnupg.org (Werner Koch)
Date: Tue Jun 29 16:38:00 2004
Subject: patch for libgcrypt 1.2.0 on pthreads
In-Reply-To: <40DB60C8.7050100@danger.com> (Robey Pointer's message of "Thu,
	24 Jun 2004 16:16:24 -0700")
References: <40DB60C8.7050100@danger.com>
Message-ID: <878ye64fc4.fsf@wheatstone.g10code.de>

On Thu, 24 Jun 2004 16:16:24 -0700, Robey Pointer said:

> -  pthread_mutex_t *lock = malloc (sizeof (pthread_mutex_t));		      \
> +  pthread_mutex_t *lock = (pthread_mutex_t *)malloc (sizeof (pthread_mutex_t));	\

malloc returns void* and that type must be assignable to any other
pointer object.  Thus this patch does not make sense for C.

> -  { int err = pthread_mutex_destroy (*lock);  free (*lock); return err; }     \
> +{ int err = pthread_mutex_destroy ((pthread_mutex_t *)*lock);  free (*lock); return err; } \

See above.

> -  gcry_pthread_mutex_lock, gcry_pthread_mutex_unlock }
> +  gcry_pthread_mutex_lock, gcry_pthread_mutex_unlock, 0, 0, 0, 0, 0, 0, 0, 0}
Leaving out initializers will set the remaining elements to zero:

      [#21]  If  there  are fewer initializers in a brace-enclosed
       list than there are elements or members of an aggregate,  or
       fewer  characters  in a string literal used to initialize an
       array of known size than there are elements  in  the  array,
       the   remainder   of  the  aggregate  shall  be  initialized
       implicitly the same as  objects  that  have  static  storage
       duration.

Thus I can't see a reason to change it.



Shalom-Salam,

   Werner

 


From robey at danger.com  Tue Jun 29 19:24:37 2004
From: robey at danger.com (Robey Pointer)
Date: Tue Jun 29 20:18:52 2004
Subject: patch for libgcrypt 1.2.0 on pthreads
In-Reply-To: <878ye64fc4.fsf@wheatstone.g10code.de>
References: <40DB60C8.7050100@danger.com>
	<878ye64fc4.fsf@wheatstone.g10code.de>
Message-ID: <40E1A5D5.1060103@danger.com>

Werner Koch wrote:

>On Thu, 24 Jun 2004 16:16:24 -0700, Robey Pointer said:
>
>  
>
>>-  pthread_mutex_t *lock = malloc (sizeof (pthread_mutex_t));		      \
>>+  pthread_mutex_t *lock = (pthread_mutex_t *)malloc (sizeof (pthread_mutex_t));	\
>>    
>>
>
>malloc returns void* and that type must be assignable to any other
>pointer object.  Thus this patch does not make sense for C.
>  
>

I won't try to defend gcc.  But it gives these errors without the patch:

TLSStream.cpp: In function `int gcry_pthread_mutex_init(void**)':
TLSStream.cpp:18: error: invalid conversion from `void*' to 
`pthread_mutex_t*'
TLSStream.cpp: In function `int gcry_pthread_mutex_destroy(void**)':
TLSStream.cpp:18: error: invalid conversion from `void*' to 
`pthread_mutex_t*'
TLSStream.cpp: In function `int gcry_pthread_mutex_lock(void**)':
TLSStream.cpp:18: error: invalid conversion from `void*' to 
`pthread_mutex_t*'
TLSStream.cpp: In function `int gcry_pthread_mutex_unlock(void**)':
TLSStream.cpp:18: error: invalid conversion from `void*' to 
`pthread_mutex_t*'
TLSStream.cpp: At global scope:
TLSStream.cpp:18: warning: missing initializer for member `
   gcry_thread_cbs::read'
TLSStream.cpp:18: warning: missing initializer for member `
   gcry_thread_cbs::write'
TLSStream.cpp:18: warning: missing initializer for member `
   gcry_thread_cbs::select'
TLSStream.cpp:18: warning: missing initializer for member `
   gcry_thread_cbs::waitpid'
TLSStream.cpp:18: warning: missing initializer for member `
   gcry_thread_cbs::accept'
TLSStream.cpp:18: warning: missing initializer for member `
   gcry_thread_cbs::connect'
TLSStream.cpp:18: warning: missing initializer for member `
   gcry_thread_cbs::sendmsg'
TLSStream.cpp:18: warning: missing initializer for member `
   gcry_thread_cbs::recvmsg'
make: *** [TLSStream.o] Error 1


Line 18 is:
GCRY_THREAD_OPTION_PTHREAD_IMPL;


So gcc (3.3.4) apparently doesn't think these conversions are valid 
without casts.

robey


From lowhalo at hush.com  Fri Jun 18 02:33:12 2004
From: lowhalo at hush.com (low halo, Defender of Truth and Liberty)
Date: Wed Jun 30 06:44:25 2004
Subject: mingw/cpd problem
Message-ID: <200406180033.i5I0XDZd077104@mailserver2.hushmail.com>

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

Hi --

    With mingw/cpd, I've successfully compiled a 'libgcrypt.a'.  My
next step is to create a 'libgcrypt.dll', but the instructions on
how to do so in mingw/cpd's README file are quite vague.  The best
I've been able to do results in creating an EXE file instead of a 
DLL (!):

    mingw32 gcc -c -dll test.c
    mingw32 gcc -Wl,--base-file=a.base test.o
    mingw32 dlltool --as `mingw32 --get-path as` --base-file a.base \
        -e exports.o test.o
    mingw32 gcc test.o exports.o -o test.dll

    What am I doing wrong?

    -- low halo

P.S. The 'WkLib' package fails to compile on Debian stable (3.0r2).
Bit-rot, I guess?

- --
low halo <lowhalo at-s1gn hacktivismo d0t c0m>
Defender of Truth and Liberty
http://ultramagnetic.sourceforge.net/
http://www.hacktivismo.com/
 
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x3AFB17F6
9AB1 FF04 016F 89A3 5B4E  A585 BDBB 5FBE 3AFB 17F6

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Your Mother)

iD8DBQFAy7+kvbtfvjr7F/YRAvqDAJ9ACkyZFGzDlKdVX3sxXzcM7rN0nwCeKIa8
jU7Xc+8xbsQ96T+u0nUAb6Q=
=nAs3
-----END PGP SIGNATURE-----




Concerned about your privacy? Follow this link to get
secure FREE email: http://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
http://www.hushmail.com/services.php?subloc=messenger&l=434

Promote security and make money with the Hushmail Affiliate Program: 
http://www.hushmail.com/about.php?subloc=affiliate&l=427

From craig at twolips-translations.co.uk  Wed Jun 30 16:03:57 2004
From: craig at twolips-translations.co.uk (Craig Graham)
Date: Wed Jun 30 16:03:59 2004
Subject: Ping
Message-ID: <001b01c452bc$a6d03a10$fe01010a@craigloft>

Is this list alive? Even my own posts aren't showing up and I've had nothing
since the 9th.

--
Dr. Craig Graham, Software Engineer
Advanced Analysis and Integration Limited, UK. http://www.aail.co.uk/




From marcus.brinkmann at ruhr-uni-bochum.de  Wed Jun 30 19:50:09 2004
From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann)
Date: Tue Jul  6 16:40:57 2004
Subject: GPGME and callbacks
In-Reply-To: <023b01c44fb8$2135b080$fe01010a@craigloft>
References: <023b01c44fb8$2135b080$fe01010a@craigloft>
Message-ID: <87u0wt0wby.wl@ulysses.g10code.de>

At Fri, 11 Jun 2004 14:29:32 +0100,
Craig Graham wrote:
> 
> I have another gpgme problem.

Juast as a side note: Please post gpgme related questions to gnupg-devel.
This list seems to be mostly for libgcrypt.

> The language I'm using (Labview) doesn't seem to do callbacks.This gives me
> a problem in generating a signature since I cannot provide a callback
> function in order to obtain the pass phrase. I need a mechanism by which I
> can send the pass phrase through myself, either by pre-loading it into the
> library as is done with the signing keys, or by passing it as one of the
> arguments to a sign function.
> 
> Does a mechanism already exist for this, or do I have to change the library
> myself?

This is an interesting problem.  However, if you are using labview,
then I guess you are not using the C language.  Which raises the
question how you use GPGME at all.  If you are using a wrapper, then
this is an issue for the wrapper to solve for you.

Thanks,
Marcus


From marcus.brinkmann at ruhr-uni-bochum.de  Wed Jun 30 19:51:20 2004
From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann)
Date: Tue Jul  6 16:40:59 2004
Subject: Ping
In-Reply-To: <001b01c452bc$a6d03a10$fe01010a@craigloft>
References: <001b01c452bc$a6d03a10$fe01010a@craigloft>
Message-ID: <87smcd0w9z.wl@ulysses.g10code.de>

At Tue, 15 Jun 2004 10:39:27 +0100,
Craig Graham wrote:
> 
> Is this list alive? Even my own posts aren't showing up and I've had nothing
> since the 9th.

There was an issue with the mailserver on gnupg.org, I think.  It
doesn't hurt to repost your mails that didn't come through yet.
However, in general the mail server is quite slow these days, so give
it 12 hours or a day or so to get through.

Thanks,
Marcus


From wk at gnupg.org  Wed Jun 30 12:19:11 2004
From: wk at gnupg.org (Werner Koch)
Date: Tue Jul  6 16:41:26 2004
Subject: patch for libgcrypt 1.2.0 on pthreads
In-Reply-To: <40E1A5D5.1060103@danger.com> (Robey Pointer's message of "Tue,
	29 Jun 2004 10:24:37 -0700")
References: <40DB60C8.7050100@danger.com>
	<878ye64fc4.fsf@wheatstone.g10code.de> <40E1A5D5.1060103@danger.com>
Message-ID: <87vfh9z6u8.fsf@wheatstone.g10code.de>

On Tue, 29 Jun 2004 10:24:37 -0700, Robey Pointer said:

> I won't try to defend gcc.  But it gives these errors without the patch:

> TLSStream.cpp: In function `int gcry_pthread_mutex_init(void**)':
> TLSStream.cpp:18: error: invalid conversion from `void*' to
> `pthread_mutex_t*'

You are using C++ and not C.

C++ is a different language than C - you have to make sure that your
C++ code uses plain C code correctly.  The only thing we have made
sure is that the link conventions of Libgcrypt won't conflict with
C++.

GCRY_THREAD_OPTION_PTHREAD_IMPL is a convenience macro.  Yo should use
your own implementation with C++.  The manual describes how to do it.


Salam-Shalom,

   Werner



From robey at danger.com  Wed Jun 30 19:21:02 2004
From: robey at danger.com (Robey Pointer)
Date: Tue Jul  6 16:42:33 2004
Subject: patch for libgcrypt 1.2.0 on pthreads
In-Reply-To: <87vfh9z6u8.fsf@wheatstone.g10code.de>
References: <40DB60C8.7050100@danger.com>	<878ye64fc4.fsf@wheatstone.g10code.de>
	<40E1A5D5.1060103@danger.com>
	<87vfh9z6u8.fsf@wheatstone.g10code.de>
Message-ID: <40E2F67E.9050703@danger.com>

Werner Koch wrote:

>On Tue, 29 Jun 2004 10:24:37 -0700, Robey Pointer said:
>
>  
>
>>I won't try to defend gcc.  But it gives these errors without the patch:
>>    
>>
>
>  
>
>>TLSStream.cpp: In function `int gcry_pthread_mutex_init(void**)':
>>TLSStream.cpp:18: error: invalid conversion from `void*' to
>>`pthread_mutex_t*'
>>    
>>
>
>You are using C++ and not C.
>
>C++ is a different language than C - you have to make sure that your
>C++ code uses plain C code correctly.  The only thing we have made
>sure is that the link conventions of Libgcrypt won't conflict with
>C++.
>
>GCRY_THREAD_OPTION_PTHREAD_IMPL is a convenience macro.  Yo should use
>your own implementation with C++.  The manual describes how to do it.
>  
>

That's okay.  I was mostly passing the patch up as a convenience -- 
we're okay with using our forked version with it fixed the right way.

You probably want to remove the lines saying 'extern "C"' at the top of 
gcrypt.h to avoid giving the impression that you support C++ usage.

robey