From slowhog at jxta.org  Thu Apr 14 04:15:59 2005
From: slowhog at jxta.org (Henry Jen)
Date: Thu Apr 14 11:04:26 2005
Subject: Undefined symbols libgcrypt-1.2.0/tests/ac.c (Solaris 2.7)
References: <20041210085124.GA13850@flower.theory.informatik.uni-kassel.de>
	<yova8y70npc4.fsf@relaskop.wsl.ch>
Message-ID: <loom.20050414T041253-945@post.gmane.org>

 <lanz <at> wsl.ch> writes:

> 
> On 10 Dec 2004, stamer <at> flower.theory.informatik.uni-kassel.de wrote:
> 
> >
> > Hello libgrypt-team,
> >
> > the following error appears during the build of libgcrypt-1.2.0 on
> > Solaris (with non-gnu linker). It seems to me, that the listed
> > symbols are not in libgcrypt.so but they appear in
> > libgcrypt.a. --disable-ld-version-script does not help. The created
> > config.log is attached.
> >
> > .... (dropped)
> 
> I can confirm the build error under Sun Sparc Solaris 2.9 (non-gnu
> linker). I still get a very similar error with the new libgcrypt
> version 1.2.1 (see below).
> 
>

I have same problem with 1.2.1 on Solaris 10(non-gnu linker). Have you figured
out  this? If so, would you please let me know how to solve this?

Many thanks,
Henry



From eduardo.espejo at t-empresas.com.pe  Thu Apr 14 16:42:47 2005
From: eduardo.espejo at t-empresas.com.pe (Eduardo Espejo Gavilano)
Date: Thu Apr 14 16:34:53 2005
Subject: Undefined symbols libgcrypt-1.2.0/tests/ac.c (Solaris 2.7)
In-Reply-To: <loom.20050414T041253-945@post.gmane.org>
Message-ID: <OF3FD28C67.A0CB6608-ON05256FE3.004F19C5-05256FE3.00508986@tp.com.pe>

I have the same problem on solaris 2.6, I think it is about the linker or
libtool. On Solaris with non-gnu linker, libtool generate this command for
the shared library:

gcc -shared -Wl,-h -Wl,libgcrypt.so.11 -o .libs/libgcrypt.so.11.2.0
.libs/libgcrypt_la-misc.o .libs/libgcrypt_la-global.o
.libs/libgcrypt_la-sexp.o .libs/libgcrypt_la-stdmem.o
.libs/libgcrypt_la-secmem.o .libs/libgcrypt_la-missing-string.o
.libs/libgcrypt_la-module.o .libs/libgcrypt_la-ath.o -z allextract
../cipher/.libs/libcipher.a ../mpi/.libs/libmpi.a -z defaultextract
-R/usr/local/lib -R/usr/local/lib -L/usr/local/lib
/usr/local/lib/libgpg-error.so -lnsl -lsocket -lc

It seems that the linker can not extract all symbols from libcipher.a
because "allextract" does not  work fine at all,  I solved the problem with
the gnu linker, just rename the path of the non-gnu linker so gcc or cc
will take the gnu-linker commonly installed in /usr/local/bin. With gnu
linker the command looks like this :

gcc -shared  .libs/libgcrypt_la-misc.o .libs/libgcrypt_la-global.o
.libs/libgcrypt_la-sexp.o .libs/libgcrypt_la-stdmem.o
.libs/libgcrypt_la-secmem.o .libs/libgcrypt_la-missing-string.o
.libs/libgcrypt_la-module.o .libs/libgcrypt_la-ath.o -Wl,--whole-archive
../cipher/.libs/libcipher.a ../mpi/.libs/libmpi.a -Wl,--no-whole-archive
-Wl,--rpath -Wl,/usr/local/lib -Wl,--rpath -Wl,/usr/local/lib
-L/usr/local/lib /usr/local/lib/libgpg-error.so -lnsl
-Wl,--version-script=./libgcrypt.vers -Wl,-soname -Wl,libgcrypt.so.11 -o
.libs/libgcrypt.so.11.2.0

--whole-archive instead allextract

Hope this help

Regards
Eduardo Espejo




                                                                           
             Henry Jen                                                     
             <slowhog@jxta.org                                             
             >                                                        Para 
             Enviado por:              gcrypt-devel@gnupg.org              
             gcrypt-devel-boun                                          cc 
             ces@gnupg.org                                                 
                                                                    Asunto 
                                       Re: Undefined symbols               
             13/04/2005 21:15          libgcrypt-1.2.0/tests/ac.c (Solaris 
                                       2.7)                                
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




 <lanz <at> wsl.ch> writes:

>
> On 10 Dec 2004, stamer <at> flower.theory.informatik.uni-kassel.de wrote:
>
> >
> > Hello libgrypt-team,
> >
> > the following error appears during the build of libgcrypt-1.2.0 on
> > Solaris (with non-gnu linker). It seems to me, that the listed
> > symbols are not in libgcrypt.so but they appear in
> > libgcrypt.a. --disable-ld-version-script does not help. The created
> > config.log is attached.
> >
> > .... (dropped)
>
> I can confirm the build error under Sun Sparc Solaris 2.9 (non-gnu
> linker). I still get a very similar error with the new libgcrypt
> version 1.2.1 (see below).
>
>

I have same problem with 1.2.1 on Solaris 10(non-gnu linker). Have you
figured
out  this? If so, would you please let me know how to solve this?

Many thanks,
Henry



_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

ForwardSourceID:NT000114EA




From bradh at frogmouth.net  Sat Apr 16 03:22:17 2005
From: bradh at frogmouth.net (Brad Hards)
Date: Sat Apr 16 03:18:47 2005
Subject: HMAC-SHA384/HMAC-SHA512 testng?
Message-ID: <200504161122.24863.bradh@frogmouth.net>

Has anyone tested HMAC with SHA384 and SHA512? 

I've tried the test vectors in 
http://www.ietf.org/internet-drafts/draft-nystrom-smime-hmac-sha-00.txt
and they work for SHA-256, but almost identical code fails for SHA-384 and 
SHA-512.

I contacted Magnus Nystrom, and he asked:
"Did you use blocksize = 128 for SHA-384 and SHA-512? It affects the key 
padding."

I am passing the key data and actual length to gcry_md_setkey(). Is that 
correct operation of HMAC within libgcrypt?

Brad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20050416/3c4c0f10/attachment-0001.pgp
From vincent.deffontaines at inl.fr  Mon Apr 18 17:51:03 2005
From: vincent.deffontaines at inl.fr (Vincent Deffontaines)
Date: Mon Apr 18 18:21:14 2005
Subject: Thread safety problem (?)
Message-ID: <4263D767.30709@inl.fr>

Greetings,

I use gcrypt in a multithreaded server app (namely, nufw [1]) (also uses 
glib and gnutls).

We experiment an occasionnal (hard to reproduce) crash which seems to 
always occur at the gnutls call : gnutls_handshake(). The crash is quite 
rare (and occurs in an often called loop), which leads us to believe 
this might be a thread safety problem.

Gnutls people pointed us (on this thread [2]) to the gcrypt, and told us 
we should use some locking mechanisms. Also, the "Multi-threaded 
applications" [3] webpage seems to be of interest.

Our server runs this :
static struct gcry_thread_cbs gcry_threads_gthread =
{
         GCRY_THREAD_OPTION_USER, NULL,
         gcry_gthread_mutex_init, gcry_gthread_mutex_destroy,
         gcry_gthread_mutex_lock, gcry_gthread_mutex_unlock
};

and this :

g_thread_init(NULL);
gcry_control (GCRYCTL_SET_THREAD_CBS, &gcry_threads_gthread);
gnutls_global_init();

which doesn't seem to be enough to solve our problem.

As usual, the thread safety problems are very delicate, and we of course 
cannot be sure this is gcrypt's "fault" or ours, or whatever.

If anyone on this list has more ideas about what to check/add, we will 
be very interested to hear about it.

Any help/pointer will be appreciated.

Thanks for reading me,

Vincent Deffontaines



[1] http://www.nufw.org/
[2] http://lists.gnu.org/archive/html/help-gnutls/2005-04/msg00009.html
[3] 
http://www.gnu.org/software/gnutls/manual/html_node/Multi_002dthreaded-applications.html#Multi_002dthreaded-applications

From bradh at frogmouth.net  Tue Apr 19 04:48:37 2005
From: bradh at frogmouth.net (Brad Hards)
Date: Tue Apr 19 04:44:58 2005
Subject: HMAC-SHA384/HMAC-SHA512 testng?
In-Reply-To: <200504161122.24863.bradh@frogmouth.net>
References: <200504161122.24863.bradh@frogmouth.net>
Message-ID: <200504191248.38264.bradh@frogmouth.net>

On Sat, 16 Apr 2005 11:22 am, Brad Hards wrote:
> Has anyone tested HMAC with SHA384 and SHA512?
>
> I've tried the test vectors in
> http://www.ietf.org/internet-drafts/draft-nystrom-smime-hmac-sha-00.txt
> and they work for SHA-256, but almost identical code fails for SHA-384 and
> SHA-512.
>
> I contacted Magnus Nystrom, and he asked:
> "Did you use blocksize = 128 for SHA-384 and SHA-512? It affects the key
> padding."
OK, I'm pretty confident that gcrypt is doing it wrong.

FIPS 180-2 section 5.1.2 says the blocksize is 128 bytes.

RFC2104 says that the padding should be blocksize.

src/md.c:prepare_macpads() is pretty much hardwired to 64byte blocks. 
Similarly, md_open() and md_copy both malloc a fixed 128 bytes (for ipad and 
opad).

I'm considering two options - an intrusive patch that adds a blocksize 
function pointer to gcry_md_spec_t, and then working in terms of the 
ctx->blocksize(), or alternatively a less intrusive, but much uglier special 
casing (if algo == GCRY_MD_SHA384 || algo == GCRY_MD_SHA512). I'd prefer to 
do the first, but the concern I have is that there might be external modules, 
and if I change the size of gcry_md_spec_t, then they might break.

Thoughts? Help?

Brad

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20050419/120cd567/attachment.pgp
From bradh at frogmouth.net  Tue Apr 19 08:20:59 2005
From: bradh at frogmouth.net (Brad Hards)
Date: Tue Apr 19 08:17:26 2005
Subject: [patch] HMAC-SHA384/HMAC-SHA512 fixes
In-Reply-To: <200504191248.38264.bradh@frogmouth.net>
References: <200504161122.24863.bradh@frogmouth.net>
	<200504191248.38264.bradh@frogmouth.net>
Message-ID: <200504191621.06964.bradh@frogmouth.net>

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20050419/8535e0b6/attachment.pgp
From mo at g10code.com  Tue Apr 19 16:14:25 2005
From: mo at g10code.com (Moritz Schulte)
Date: Tue Apr 19 16:10:51 2005
Subject: Thread safety problem (?)
In-Reply-To: <4263D767.30709@inl.fr>
References: <4263D767.30709@inl.fr>
Message-ID: <20050419141425.GA7182@sarkutty>

On Mon, Apr 18, 2005 at 05:51:03PM +0200, Vincent Deffontaines wrote:

Hello Vincent,

> We experiment an occasionnal (hard to reproduce) crash which seems
> to always occur at the gnutls call : gnutls_handshake(). The crash
> is quite rare (and occurs in an often called loop), which leads us
> to believe this might be a thread safety problem.

Since your initialization in respect to the threading system looks
correct, there are two possibilities:

  1) the problem is indeed in Libgcrypt and thus you have found a new
     bug;
  2) the problem is not in Libgcrypt.

I cannot exclude the one or the other.  You could try to do the
following: protect all calls into Libgcrypt by a shared lock; this
way, Libgcrypt would never be used by two threads at the same time.
If the problem keeps being reproducible, 1) should be excludable.

Thanks,
Moritz

-- 
Moritz Schulte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 193 bytes
Desc: not available
Url : /pipermail/attachments/20050419/fbc637d6/attachment.pgp
From mo at g10code.com  Tue Apr 19 17:05:35 2005
From: mo at g10code.com (Moritz Schulte)
Date: Tue Apr 19 17:01:40 2005
Subject: HMAC-SHA384/HMAC-SHA512 testng?
In-Reply-To: <200504191248.38264.bradh@frogmouth.net>
References: <200504161122.24863.bradh@frogmouth.net>
	<200504191248.38264.bradh@frogmouth.net>
Message-ID: <20050419150535.GB9739@sarkutty>

Hello Brad,

thanks for your research; it will be fixed one way or another.

Moritz

-- 
Moritz Schulte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 193 bytes
Desc: not available
Url : /pipermail/attachments/20050419/1325c293/attachment.pgp
From flebool at libero.it  Tue Apr 19 21:00:14 2005
From: flebool at libero.it (flebool)
Date: Tue Apr 19 19:39:27 2005
Subject: extracting mpi from a S-exp crypted with RSA
Message-ID: <200504191900.14263.flebool@libero.it>

I haven't understood correctly the model for crypted keys:
in the documentation, i've found that,if i crypt with the rsa algorythm a 
S-exp TEXT in the form:

          (data
            (flags raw)
            (value MPI))

 the crypted S-exp CRYPTED is represented as:

          (enc-val
            (rsa
              (a A-MPI)))


Calling the function:
int legth=gcrypt_sexp_length(CRYPTED);
I get length=2.

i want to get the mpi (a A-MPI),(that i've understood to be the crypted text 
in MPI format) but the function

gcry_mpi_t internal_mpi = gcry_sexp_nth_mpi(CRYPTED,1,GCRYMPI_FMT_USG);

fails.

for completeness,i post the output of a 
writt= gcry_sexp_sprint ( CRYPTED , GCRYSEXP_FMT_DEFAULT , buf_test2 ,(size_t) 
500);

(i do it only to show that it seems (at least to me) to be a good S-exp in the 
format described in the documentation)

the results are: writt=166,buf_test2[500]="\000?\004\b@?\004\b(7:enc-val\n 
(3:rsa\n  (1:a128:
\003t??\215?\020+9D?\016\002\032\226?\025O?4]?RU\025\003\001*\000?-o\210\211~\217i\020\f??\225?d?\207?\222)????d_?/\036}??\203?u\r?\fo\bC?Y\227l?P\026?\020\206?\224??J\"8??\005NYUCN?\211?.m\215.W?R??.
\212z?J?\222\f\037\2269\e????d\025?\234$)\n"

i'm not a good coder, neither a good english writer, so sorry if i haven't 
been clear, or if i haven't understood well the documentation.

thanks in advance for any help.

Flebool

PS if you prefer i can post a source of an example program.
PPS:it may take some time before i can answer your replys


From bradh at frogmouth.net  Tue Apr 19 22:21:19 2005
From: bradh at frogmouth.net (Brad Hards)
Date: Tue Apr 19 22:17:48 2005
Subject: HMAC-SHA384/HMAC-SHA512 testng?
In-Reply-To: <20050419150535.GB9739@sarkutty>
References: <200504161122.24863.bradh@frogmouth.net>
	<200504191248.38264.bradh@frogmouth.net>
	<20050419150535.GB9739@sarkutty>
Message-ID: <200504200621.29046.bradh@frogmouth.net>

On Wed, 20 Apr 2005 01:05 am, Moritz Schulte wrote:
> thanks for your research; it will be fixed one way or another.
Is there any thing else I can do for this? For example, write a test case?

Brad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20050420/507c98fc/attachment.pgp
From wk at gnupg.org  Wed Apr 20 11:40:41 2005
From: wk at gnupg.org (Werner Koch)
Date: Wed Apr 20 11:41:45 2005
Subject: HMAC-SHA384/HMAC-SHA512 testng?
In-Reply-To: <20050419150535.GB9739@sarkutty> (Moritz Schulte's message of
	"Tue, 19 Apr 2005 17:05:35 +0200")
References: <200504161122.24863.bradh@frogmouth.net>
	<200504191248.38264.bradh@frogmouth.net>
	<20050419150535.GB9739@sarkutty>
Message-ID: <87br89lrae.fsf@wheatstone.g10code.de>

On Tue, 19 Apr 2005 17:05:35 +0200, Moritz Schulte said:

> thanks for your research; it will be fixed one way or another.

Thanks for your work.  However to include this into libgcrypt the FSf
requires a copyright assignment or a disclaimer.  If you can do so,
please contact me by private mail.

Thanks,

  Werner


From wk at gnupg.org  Wed Apr 20 11:44:59 2005
From: wk at gnupg.org (Werner Koch)
Date: Wed Apr 20 11:41:52 2005
Subject: HMAC-SHA384/HMAC-SHA512 testng?
In-Reply-To: <200504191248.38264.bradh@frogmouth.net> (Brad Hards's message
	of "Tue, 19 Apr 2005 12:48:37 +1000")
References: <200504161122.24863.bradh@frogmouth.net>
	<200504191248.38264.bradh@frogmouth.net>
Message-ID: <877jixlr38.fsf@wheatstone.g10code.de>

On Tue, 19 Apr 2005 12:48:37 +1000, Brad Hards said:

> OK, I'm pretty confident that gcrypt is doing it wrong.

Very likley.  At the time I implemented the HMAC thing the SHA-2
algorithms were not known.

> I'm considering two options - an intrusive patch that adds a blocksize 
> function pointer to gcry_md_spec_t, and then working in terms of the 

We can't do this because it breaks the ABI.

ctx-> blocksize(), or alternatively a less intrusive, but much uglier special 
> casing (if algo == GCRY_MD_SHA384 || algo == GCRY_MD_SHA512). I'd prefer to 
> do the first, but the concern I have is that there might be external modules, 
Yes, we need to do this hack.  Which also means that external modules
requiring a blocksize other that 64 can't be used.


Shalom-Salam,

   Werner


From mo at g10code.com  Wed Apr 20 16:22:41 2005
From: mo at g10code.com (Moritz Schulte)
Date: Wed Apr 20 16:18:43 2005
Subject: extracting mpi from a S-exp crypted with RSA
In-Reply-To: <200504191900.14263.flebool@libero.it>
References: <200504191900.14263.flebool@libero.it>
Message-ID: <20050420142241.GC31378@sarkutty>

On Tue, Apr 19, 2005 at 07:00:14PM +0000, flebool wrote:

Hello,

>  the crypted S-exp CRYPTED is represented as:
> 
>           (enc-val
>             (rsa
>               (a A-MPI)))

Correct.

> Calling the function:
> int legth=gcrypt_sexp_length(CRYPTED);
> I get length=2.

Correct, you have two objects in that S-Expression:

 1. "enc-val"
 2. (rsa (a A-MPI))

> i want to get the mpi (a A-MPI),(that i've understood to be the crypted text 
> in MPI format) but the function
> 
> gcry_mpi_t internal_mpi = gcry_sexp_nth_mpi(CRYPTED,1,GCRYMPI_FMT_USG);
> 
> fails.

You need to distringuish between the S-Expression containing the MPI
and it's label `(a A-MPI)' and the actual MPI value, which is `A-MPI'.

So, before you can use gcry_sexp_nth_mpi(), you need to extract the
sub-S-Expression, i.e.:

a = (enc-val (rsa (a A-MPI)));
b = sexp_nth (a, 1); // extract `(rsa (a A-MPI))'
mpi = sexp_mpi (b, 1; // extract `A-MPI'.

Alternatively, you can also use gcry_sexp_find_token().

> for completeness,i post the output of a 
> writt= gcry_sexp_sprint ( CRYPTED , GCRYSEXP_FMT_DEFAULT , buf_test2 ,(size_t) 
> 500);

By the way: GCRYSEXP_FMT_ADVANCED is much more appropriate for output
intended to be human-readable.

Thanks,
Moritz

-- 
Moritz Schulte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 193 bytes
Desc: not available
Url : /pipermail/attachments/20050420/b1ab0212/attachment-0001.pgp
From gcrypt-devel at mlists.thewrittenword.com  Thu Apr 21 22:29:54 2005
From: gcrypt-devel at mlists.thewrittenword.com (Albert Chin)
Date: Thu Apr 21 23:18:28 2005
Subject: libgcrypt configure fixes
In-Reply-To: <87wttrj77o.fsf@wheatstone.g10code.de>
References: <20050122201627.GG91810@mail1.thewrittenword.com>
	<87wttrj77o.fsf@wheatstone.g10code.de>
Message-ID: <20050421202953.GB22965@mail1.thewrittenword.com>

On Wed, Feb 02, 2005 at 04:46:03PM +0100, Werner Koch wrote:
> you wrote quite some fixes; whoever I can't apply them unless you can
> sign a disclaimer or copyright assignment for the FSF.  If you are
> inclined to, please contact me by private mail. 
> 
> As a general note, both Moritz and me are quite busy with other
> things, so libgcrypt repplies are delayed.  I still read them and hope
> to find the time to answer them ASAP.  However, carnival starts
> tomorrow and thus I am not sure whether I find the time to do much
> work ;-)

We now have a corporate copyright assignment form on file with the FSF
for gcrypt.

-- 
albert chin (china@thewrittenword.com)

From bradh at frogmouth.net  Fri Apr 22 12:18:03 2005
From: bradh at frogmouth.net (Brad Hards)
Date: Fri Apr 22 12:15:04 2005
Subject: [patch] SHA-224 implementation
Message-ID: <200504222018.09645.bradh@frogmouth.net>

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20050422/d1d879cc/attachment.pgp
From bradh at frogmouth.net  Fri Apr 22 12:38:10 2005
From: bradh at frogmouth.net (Brad Hards)
Date: Fri Apr 22 12:34:36 2005
Subject: [patch] SHA-224 implementation
In-Reply-To: <200504222018.09645.bradh@frogmouth.net>
References: <200504222018.09645.bradh@frogmouth.net>
Message-ID: <200504222038.11347.bradh@frogmouth.net>

On Fri, 22 Apr 2005 20:18 pm, Brad Hards wrote:
> Apart from needing to sort out the copyright issues, is this technically
> acceptable?
One issue I forgot to ask: can someone check my oid translation is correct? I 
only got the ASN.1 spec this afternoon, and it is very hard to understand.

Brad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20050422/6b92df12/attachment.pgp
From krokodylek at tenbit.pl  Mon Apr 25 00:29:03 2005
From: krokodylek at tenbit.pl (=?ISO-8859-2?Q?Maciej_Zi=EAba?=)
Date: Mon Apr 25 01:25:24 2005
Subject: Libgcrypt and Windows - again :(
Message-ID: <426C1DAF.30000@tenbit.pl>

Hi  :)

I'm very sorry to disturb you all but I desperately need help.

I need RSA encryption / decryption for my little project in VC++ 6.0.

When searching Internet for some cryptographic library, I've found
libgcrypt. It seems it is very much what I would need but I have na idea
how to use it in Windows.

I've downloaded the latest version from CVS. README says there's a
possibility to create a DLL but it doesn't say exactly how to do it :(

I've found and tried a suggestion to issue theese commands (in Linux):

./autogen.sh --build-w32
./configure --enable-maintainer-mode
make

Something is compiling but a DLL isn't created.

I've also tried:
cd w32-dll
./build-dll

getting this error:
./build-dll: line 14: mingw32: command not found

I've been searching Internet almost all day and still don't know what to
do :( Is there some HOWTO I could follow?

Or maybe someone can tell me what to do? I have WinXP with Microsoft
Visual C++ 6.0 and Gentoo Linux (.

As you've probably guessed I'm quite a newbie... I would be very, very
grateful for any suggestions.

Again, I'm really sorry if I'm missing something obvious.


Best regards,
Maciej Zieba


PS. If you think that getting libgcrypt to work is too hard for me maybe
you could suggest (please, don't hit me) some other free cryptographic
library I could use?

From bradh at frogmouth.net  Mon Apr 25 05:24:41 2005
From: bradh at frogmouth.net (Brad Hards)
Date: Mon Apr 25 05:21:20 2005
Subject: [patch] docs for SHA224, and other fixes
Message-ID: <200504251324.46856.bradh@frogmouth.net>

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20050425/be3af224/attachment.pgp
From wk at gnupg.org  Mon Apr 25 09:23:14 2005
From: wk at gnupg.org (Werner Koch)
Date: Mon Apr 25 09:21:03 2005
Subject: Libgcrypt and Windows - again :(
In-Reply-To: <426C1DAF.30000@tenbit.pl> (
	=?utf-8?q?Maciej_Zi=C4=99ba's_message_of?= "Mon, 25 Apr 2005 00:29:03
	+0200")
References: <426C1DAF.30000@tenbit.pl>
Message-ID: <87hdhv721p.fsf@wheatstone.g10code.de>

On Mon, 25 Apr 2005 00:29:03 +0200, Maciej Zi?ba said:

> ./autogen.sh --build-w32
> ./configure --enable-maintainer-mode
> make

Don't run the configure again.  The first line does it for you and
supplies all required arguments.  You need to build and install
libgpg-error first; put it below ~/w32root.  libgpg-error comes with
the same autogen.sh thingie and by defaults installs below ~/w32root.

> ./build-dll

That may or may not work but anyway the DLL is not yet specified, so I
can't suggest to create and distribute such a DLL.

> ./build-dll: line 14: mingw32: command not found

That part of the old cross-compiler kit (see
ftp.gnupg.org/people/werner/cpd/).  It is however better to use the
new mingw32 cross compiler kit which is under Debian available as the
package "mingw32".  Don't know about Gentoo.



Shalom-Salam,

   Werner


From flebool at libero.it  Tue Apr 26 00:29:47 2005
From: flebool at libero.it (flebool)
Date: Mon Apr 25 21:49:47 2005
Subject: extracting mpi from a S-exp crypted with RSA
In-Reply-To: <20050420142241.GC31378@sarkutty>
References: <200504191900.14263.flebool@libero.it>
	<20050420142241.GC31378@sarkutty>
Message-ID: <200504252229.47465.flebool@libero.it>

thank you, you've been very clear:
using the function gcry_sexp_find_token() suggested, i've managed to extract 
the MPI from the S-exp.

then i've tried to extract the crypted data from the MPI:

gcry_mpi_print(GCRYMPI_FMT_USG, buf_test, 4000, &written, mpi_extracted)

the function works well: 

i've used as text to be crypted & decrypted: "clear text", with a pair of 1024 
bit RSA keys(I've tested them with the function gcry_pk_testkey(),so they 
should be right).there are two things i don't understand:

1)the value returned in written doesn't depend upon the legth of the 
crypt/decrypt string:
i've increased the length of the crypt/decrypt string(up to 940 bytes), but 
the value returned in written is always 128.

2)why the value returned in the variable written by the function is 128: i was 
expecting it to be a multiple of the size of the keys(something like 
1024,2048,3072,ecc)


i've thougth that this could depend on the fact that the MPI data type can 
accept string up to 128 bytes length long: if so, I have to divide my strings 
in blocks of 128bytes,but i haven't found anything like this in the manual.

thanks in advance for any help.

From tthomas at chubb.com  Thu Apr 28 19:38:31 2005
From: tthomas at chubb.com (Tod Thomas)
Date: Thu Apr 28 20:23:05 2005
Subject: libgcrypt - Initialization Vector
Message-ID: <42711F97.3040901@chubb.com>

Please correct me if this the wrong list to post this type of question to.

My understanding from reading the libgcrypt info is that the 
Initialization Vector "is a non-secret random string acting as a kind of 
salt value".

I wrote two seperate programs using libgcrypt, one to perform encryption 
and one to perform decryption.  Whan I pass a string to the encryption 
module and then pipe its output to the decryption module I get the 
correct value returned - as long as the IV is the same.

Once I change the IV in one I no longer get the correct, decrypted 
string back.  I discovered this because I decided to make my IV a truly 
random value by using the output of gcry_randomize to set it and that 
failed.

My question then is if the IV should behave as the documentation 
suggests why isn't my test working?  I suspect I have misunderstood 
something in the reading or in my implementation, just not sure what.

I'll be happy to provide more details upon request.


Thanks - Tod

From mo at g10code.com  Thu Apr 28 21:22:37 2005
From: mo at g10code.com (Moritz Schulte)
Date: Thu Apr 28 21:18:30 2005
Subject: libgcrypt - Initialization Vector
In-Reply-To: <42711F97.3040901@chubb.com>
References: <42711F97.3040901@chubb.com>
Message-ID: <20050428192237.GA783@sarkutty>

On Thu, Apr 28, 2005 at 01:38:31PM -0400, Tod Thomas wrote:

> My understanding from reading the libgcrypt info is that the
> Initialization Vector "is a non-secret random string acting as a
> kind of salt value".
[...]
> Once I change the IV in one I no longer get the correct, decrypted
> string back.  I discovered this because I decided to make my IV a
> truly random value by using the output of gcry_randomize to set it
> and that failed.

Well, the IV needs to be the same for encryption and decryption; this
is so, since it has direct influence on the ciphertext (in case of
encryption) and plaintext (in case of decryption).

Moritz

-- 
Moritz Schulte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 193 bytes
Desc: not available
Url : /pipermail/attachments/20050428/f42d4d6f/attachment.pgp
From bradh at frogmouth.net  Thu Apr 28 23:53:36 2005
From: bradh at frogmouth.net (Brad Hards)
Date: Fri Apr 29 00:50:31 2005
Subject: libgcrypt - Initialization Vector
In-Reply-To: <42711F97.3040901@chubb.com>
References: <42711F97.3040901@chubb.com>
Message-ID: <200504290753.41716.bradh@frogmouth.net>

On Fri, 29 Apr 2005 03:38 am, Tod Thomas wrote:
> I wrote two seperate programs using libgcrypt, one to perform encryption
> and one to perform decryption.  Whan I pass a string to the encryption
> module and then pipe its output to the decryption module I get the
> correct value returned - as long as the IV is the same.
This is the correct usage.

> Once I change the IV in one I no longer get the correct, decrypted
> string back.  I discovered this because I decided to make my IV a truly
> random value by using the output of gcry_randomize to set it and that
> failed.
This is the intended behaviour. As Moritz explained, the ciphertext is a 
function of the plain text, the key and the IV. The IV is intended to protect 
from the case when you use the same key over and over, and you might encrypt 
the same plaintext. In this case, if you don't have a salt/IV anyone who can 
see the ciphertext knows that it the plaintext. IV also makes dictionary 
attacks much harder.

> My question then is if the IV should behave as the documentation
> suggests why isn't my test working?  I suspect I have misunderstood
> something in the reading or in my implementation, just not sure what.
>
> I'll be happy to provide more details upon request.
Can you tell me which part of the documentation led you think it might be OK 
to use a different IV for encryption and decryption?  I can take a look at 
it, and perhaps propose some changes.

Brad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20050429/6fc37a84/attachment.pgp
From tthomas at chubb.com  Fri Apr 29 15:47:17 2005
From: tthomas at chubb.com (Tod Thomas)
Date: Fri Apr 29 15:47:27 2005
Subject: libgcrypt - Initialization Vector
In-Reply-To: <200504290753.41716.bradh@frogmouth.net>
References: <42711F97.3040901@chubb.com>
	<200504290753.41716.bradh@frogmouth.net>
Message-ID: <42723AE5.3080103@chubb.com>

Brad Hards wrote:
> On Fri, 29 Apr 2005 03:38 am, Tod Thomas wrote:
> 
>>I wrote two seperate programs using libgcrypt, one to perform encryption
>>and one to perform decryption.  Whan I pass a string to the encryption
>>module and then pipe its output to the decryption module I get the
>>correct value returned - as long as the IV is the same.
> 
> This is the correct usage.
> 
> 
>>Once I change the IV in one I no longer get the correct, decrypted
>>string back.  I discovered this because I decided to make my IV a truly
>>random value by using the output of gcry_randomize to set it and that
>>failed.
> 
> This is the intended behaviour. As Moritz explained, the ciphertext is a 
> function of the plain text, the key and the IV. The IV is intended to protect 
> from the case when you use the same key over and over, and you might encrypt 
> the same plaintext. In this case, if you don't have a salt/IV anyone who can 
> see the ciphertext knows that it the plaintext. IV also makes dictionary 
> attacks much harder.

But what if I take my testing scenario from above and rather than 
running them both on the same machine piping the output of one to the 
other, instead run each program on a seperate machine?

Using your description wouldn't I have to pass the IV's value along with 
the ciphertext to be able to decrypt it on the other end?  Wouldn't I 
then have the burden of passing the IV in a secured fashion instead of 
just needing to pass the resulting ciphertext?  Maybe I wouldn't want to 
use symmetric encryption for that kind of task?

>>My question then is if the IV should behave as the documentation
>>suggests why isn't my test working?  I suspect I have misunderstood
>>something in the reading or in my implementation, just not sure what.
>>
>>I'll be happy to provide more details upon request.
> 
> Can you tell me which part of the documentation led you think it might be OK 
> to use a different IV for encryption and decryption?  I can take a look at 
> it, and perhaps propose some changes.

What I want to do is be able to encrypt a value using libgcrypt and then 
provide the decryption algorithm to an internal customer so they can 
decrypt it for their own purposes.

The statement the IV "is a non-secret random string acting as a kind of 
salt value." gave me the impression it was a random number that was 
somehow used by the encryption algorithm to provide a set of random 
numbers to be used in the encryption process.

I see now that it is more of a random value used to 'mask' the key value 
on an encryption by encryption basis.  But this unique quality prevents 
its value from being reproduced, requiring that it somehow be made 
available to the process that will ultimately perform the decryption.

This would mean either the decryption routine would need to know how to 
replicate the salt (not likely due to its randomness) or have it passed 
as a value along with the ciphertext.

Please bear with me, I'm just learning the inner workings of encryption 
so my conceptual knowledge is just beginning to grow.


Thanks - Tod

From bradh at frogmouth.net  Sat Apr 30 01:25:27 2005
From: bradh at frogmouth.net (Brad Hards)
Date: Sat Apr 30 01:22:05 2005
Subject: libgcrypt - Initialization Vector
In-Reply-To: <42723AE5.3080103@chubb.com>
References: <42711F97.3040901@chubb.com>
	<200504290753.41716.bradh@frogmouth.net>
	<42723AE5.3080103@chubb.com>
Message-ID: <200504300925.34970.bradh@frogmouth.net>

On Fri, 29 Apr 2005 23:47 pm, Tod Thomas wrote:
> But what if I take my testing scenario from above and rather than
> running them both on the same machine piping the output of one to the
> other, instead run each program on a seperate machine?
You must have the same IV on each machine.

> Using your description wouldn't I have to pass the IV's value along with
> the ciphertext to be able to decrypt it on the other end?  Wouldn't I
> then have the burden of passing the IV in a secured fashion instead of
> just needing to pass the resulting ciphertext?  Maybe I wouldn't want to
> use symmetric encryption for that kind of task?
The IV doesn't need to remain secret. You can pass it any way you like.

> What I want to do is be able to encrypt a value using libgcrypt and then
> provide the decryption algorithm to an internal customer so they can
> decrypt it for their own purposes.
OK.

> I see now that it is more of a random value used to 'mask' the key value
> on an encryption by encryption basis.  But this unique quality prevents
> its value from being reproduced, requiring that it somehow be made
> available to the process that will ultimately perform the decryption.
I think of it as an extra bit of plain text that goes at the front of the 
plain text, that masks the plain text and makes it harder for an attacker to 
pre-compute all the possible plaintext/ciphertext combinations.

> This would mean either the decryption routine would need to know how to
> replicate the salt (not likely due to its randomness) or have it passed
> as a value along with the ciphertext.
You must pass it.

> Please bear with me, I'm just learning the inner workings of encryption
> so my conceptual knowledge is just beginning to grow.
It would be well worth looking at how Electronic Code Book mode varies from 
Cipher Block Chaining mode. ECB works on just a key, and has some serious 
limitations / weaknesses if you don't use it exactly as intended. CBC (or 
CFB, or OFB - look those up too!) is much more robust.

Brad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20050430/f8967bd7/attachment.pgp