From sergi at calcurco.cat Thu Jan 1 18:48:24 2009 From: sergi at calcurco.cat (Sergi Blanch i =?utf-8?q?Torn=C3=A9?=) Date: Thu, 1 Jan 2009 18:48:24 +0100 Subject: howto do a hash Message-ID: <200901011848.25309.sergi@calcurco.cat> Hi! In side a method I need to do a hash, but this hash can be from different lengths. I mean. I'm thinking in use the 'gcry_md_spec_t' to point to the correct one depending on the runtime length, and call the references when is need. Something like: gcry_md_spec_t *hash; if (kek_len == 128) hash = &_gcry_digest_spec_sha256;//algo SHA256 else if (kek_len == 192) hash = &_gcry_digest_spec_sha384;//algo SHA384 else if (kek_len == 256) hash = &_gcry_digest_spec_sha512;//algo SHA512 else return GPG_ERR_NOT_SUPPORTED; So far, so good? Then I the procedure I think I have to do is: hash->init(context); hash->write(context,buffer,sizeof(buffer)); hash->final(context); result = hash->read(context); What I don't know now is how to correctly create this 'context'? Everywhere this is a 'pointer to void', and I cannot read the how. Thanks! /Sergi. From mo at g10code.com Thu Jan 1 20:44:01 2009 From: mo at g10code.com (Moritz Schulte) Date: 1 Jan 2009 20:44:01 +0100 Subject: howto do a hash In-Reply-To: <200901011848.25309.sergi@calcurco.cat> References: <200901011848.25309.sergi@calcurco.cat> Message-ID: <495D1D01.5010208@g10code.com> > What I don't know now is how to correctly create this 'context'? Everywhere > this is a 'pointer to void', and I cannot read the how. Why are you trying to fiddle around with Libgcrypt internals instead of using the exported programing interface as it is documented in the manual? Have a look at the manual and the included test programs. To answer your specific question about the origin of the hash context: the gcry_md_spec_t structure contains the info about the required size for the context buffer. This is allocated in md.c and then initialized with the algorithm-specific initialization function (also contained in that struct). Hope that helps, moritz -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From sergi at calcurco.cat Fri Jan 2 01:21:27 2009 From: sergi at calcurco.cat (Sergi Blanch i =?utf-8?q?Torn=C3=A9?=) Date: Fri, 2 Jan 2009 01:21:27 +0100 Subject: howto do a hash In-Reply-To: <495D1D01.5010208@g10code.com> References: <200901011848.25309.sergi@calcurco.cat> <495D1D01.5010208@g10code.com> Message-ID: <200901020121.28415.sergi@calcurco.cat> On Thursday 01 January 2009 20:44:01 Moritz Schulte wrote: > > What I don't know now is how to correctly create this 'context'? > > Everywhere this is a 'pointer to void', and I cannot read the how. > > Why are you trying to fiddle around with Libgcrypt internals instead of > using the exported programing interface as it is documented in the manual? Yes, probably I am try from the wrong way. I'm writting in the libgcrypt the elliptic curve encrypt algorithm from the 'ECC in OpenPGP' internet draft. By the way this code is in, also I can write the methods from module to module as an external view. > Have a look at the manual and the included test programs. > > To answer your specific question about the origin of the hash context: > the gcry_md_spec_t structure contains the info about the required size > for the context buffer. This is allocated in md.c and then initialized > with the algorithm-specific initialization function (also contained in > that struct). I found this, are you talking about the 'gcry_md_context' struct? You answer more than you think because I was declaring the buffer as a byte array, and it must be a gcry_md_hd_t? I'm checking it. > Hope that helps, > moritz To avoid future questions and wrong way coding I like to explain what I did by now. In the cipher/ecc.c, the interface methods ecc_encrypt and ecc_decrypt are add also with the 'gcry_pk_spec_t', 'pk_extra_spec_t' and the aliases. Internally also exists the encrypt and decrypt methods but some auxiliaries are need. From the standard I said a 'key derivation function' has to be implemented. Also in the document is explained, it comes from the Nist SP800-56A. Next step will be the AESkeyWrap (and the unwrap) from the rfc3394. But this will be further discussion. Using this moment, I like to prepare a patch that disturbs yous work at the minimum. Not like it was on ecdsa, when hundreds of things needs to be rewritten (not by me). Which communication can be the best? Really thanks! /Sergi. From sergi at calcurco.cat Fri Jan 2 11:36:44 2009 From: sergi at calcurco.cat (Sergi Blanch i =?utf-8?q?Torn=C3=A9?=) Date: Fri, 2 Jan 2009 11:36:44 +0100 Subject: howto do a hash In-Reply-To: <200901020121.28415.sergi@calcurco.cat> References: <200901011848.25309.sergi@calcurco.cat> <495D1D01.5010208@g10code.com> <200901020121.28415.sergi@calcurco.cat> Message-ID: <200901021136.45399.sergi@calcurco.cat> Hi, Understood, and also I feel little silly, the way is so similar to what was write for the gnupg-1.4 patch. The encrypt ecc algorithm is very similar to what we did, but with a couple of details different. What I write now is similar. I avoid here error checks and memory wipes. gcry_md_hd_t hd; int algo; if (kek_len == 128) algo=GCRY_MD_SHA256; else if (kek_len == 192) algo=GCRY_MD_SHA384; else if (kek_len == 256) algo=GCRY_MD_SHA512; else return GPG_ERR_NOT_SUPPORTED; err = gcry_md_open(&hd,algo,GCRY_MD_FLAG_SECURE); err = gcry_md_enable(hd,algo); Then the buffer can be a 'byte array', and after the values concatenation, the hash calculation can be called like: gcry_md_write(hd, buffer,sizeof(buffer)); HB = gcry_md_read(hd,algo); Could be this the way you said? Thanks /Sergi. On Friday 02 January 2009 01:21:27 Sergi Blanch i Torn? wrote: > On Thursday 01 January 2009 20:44:01 Moritz Schulte wrote: > > > What I don't know now is how to correctly create this 'context'? > > > Everywhere this is a 'pointer to void', and I cannot read the how. > > > > Why are you trying to fiddle around with Libgcrypt internals instead of > > using the exported programing interface as it is documented in the > > manual? > > Yes, probably I am try from the wrong way. I'm writting in the libgcrypt > the elliptic curve encrypt algorithm from the 'ECC in OpenPGP' internet > draft. By the way this code is in, also I can write the methods from module > to module as an external view. > > > Have a look at the manual and the included test programs. > > > > To answer your specific question about the origin of the hash context: > > the gcry_md_spec_t structure contains the info about the required size > > for the context buffer. This is allocated in md.c and then initialized > > with the algorithm-specific initialization function (also contained in > > that struct). > > I found this, are you talking about the 'gcry_md_context' struct? You > answer more than you think because I was declaring the buffer as a byte > array, and it must be a gcry_md_hd_t? I'm checking it. > > > Hope that helps, > > moritz > > To avoid future questions and wrong way coding I like to explain what I did > by now. In the cipher/ecc.c, the interface methods ecc_encrypt and > ecc_decrypt are add also with the 'gcry_pk_spec_t', 'pk_extra_spec_t' and > the aliases. Internally also exists the encrypt and decrypt methods but > some auxiliaries are need. > > From the standard I said a 'key derivation function' has to be implemented. > Also in the document is explained, it comes from the Nist SP800-56A. Next > step will be the AESkeyWrap (and the unwrap) from the rfc3394. But this > will be further discussion. > > Using this moment, I like to prepare a patch that disturbs yous work at the > minimum. Not like it was on ecdsa, when hundreds of things needs to be > rewritten (not by me). Which communication can be the best? > > Really thanks! > > /Sergi. -- ?Success is not the key to happiness. Happiness is the key to success. If you love what you are doing, you will be successful? ? Albert Schweitzer. From wk at gnupg.org Mon Jan 5 13:56:15 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 05 Jan 2009 13:56:15 +0100 Subject: howto do a hash In-Reply-To: <200901021136.45399.sergi@calcurco.cat> ("Sergi Blanch i. =?utf-8?Q?Torn=C3=A9=22's?= message of "Fri, 2 Jan 2009 11:36:44 +0100") References: <200901011848.25309.sergi@calcurco.cat> <495D1D01.5010208@g10code.com> <200901020121.28415.sergi@calcurco.cat> <200901021136.45399.sergi@calcurco.cat> Message-ID: <87fxjxgbdc.fsf@wheatstone.g10code.de> On Fri, 2 Jan 2009 11:36, sergi at calcurco.cat said: > err = gcry_md_open(&hd,algo,GCRY_MD_FLAG_SECURE); > err = gcry_md_enable(hd,algo); The gcry_md_enable call is superfluous because you enabled algorithm ALGO already with gcry_md_open. > Then the buffer can be a 'byte array', and after the values concatenation, the I don't understand why you insist on a byte array; you may pass any memory block to gcry_md_write. Given that you know the hash algorithm in advance and that there is just one contiguous memory range to hash, I suggest to use gcry_md_hash_buffer instead. This has the advantage that it can be highly optimized on some CPUs (modern VIA CPUs ferature a SHA-1 and a SHA-256 implementation which work on an entire buffer and return the finalized hash). Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From christof.schulze at gmx.net Mon Jan 19 20:59:31 2009 From: christof.schulze at gmx.net (Christof Schulze) Date: Mon, 19 Jan 2009 20:59:31 +0100 Subject: behavior of gcrypt depending on input data: "conflicting use" Message-ID: <20090119205931.7c2a6e01@ccschu935> Hello everyone, currentrly I am writing a program to sign a given data string using a secret key and verifying it using a public key. I followed the documentation and did things like in the tests from libgcrypt. Yet Some strings (like "Hello World!") can be signed and verified ok while other strings (like "Objekt1") lead to errors like "invalid object" or "conflicting use" I cannot make anything out of these error codes so I am turning to this mailinglist. Also google did not turn up anything. I am guessing that sometimes gcry_mpi_scan (in make_sign_parameters) returns something and sometimes it does not but I am only guessing because nscanned sometimes - even when the string is signed successfully - is 0. I am at a loss and I would greatly appreciate some input on this matter. I am using this code: testlog.c http://pastebin.com/f6051a825 logging.c: http://pastebin.com/f4bf4f55f logging.h: http://pastebin.com/f5e601a0f kind Regards Christof Schulze -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: not available URL: From wk at gnupg.org Tue Jan 20 09:38:43 2009 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Jan 2009 09:38:43 +0100 Subject: behavior of gcrypt depending on input data: "conflicting use" In-Reply-To: <20090119205931.7c2a6e01@ccschu935> (Christof Schulze's message of "Mon, 19 Jan 2009 20:59:31 +0100") References: <20090119205931.7c2a6e01@ccschu935> Message-ID: <87k58qs770.fsf@wheatstone.g10code.de> Hi, Instead of: error = gcry_mpi_scan (&mpival, GCRYMPI_FMT_USG, digest, hash_len, &nscanned ); assert ( error == 0 ); printf ( "nscanned: %lu\n", nscanned ); rc = gcry_sexp_build ( sign_parms, &errof, "(data (flags pkcs1) (hash %s %m))", HASH_NAME, mpival ); assert ( rc == 0 ); gcry_mpi_release ( mpival ); you should better do: rc = gcry_sexp_build (sign_parms, NULL, "(data (flags pkcs1)(hash %s %b))", HASH_NAME, (int)hash_len, digest); I have not looked at the actual problem with %m. If you want to figure that out, you need to check the MPI and the resulting S-expression, for example by inserting gcry_mpi_dump (mpival); putc (.'\n', stderr); gcry_sexp_dump (*sign_parms) Shalom-Salam, Werner p.s. In general it is better to insert the actual code into the message so that it is possible to answer even without an online connection. -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From gisvlad at rambler.ru Tue Jan 20 11:27:28 2009 From: gisvlad at rambler.ru (GIS GIS) Date: Tue, 20 Jan 2009 13:27:28 +0300 Subject: libgcrypt Message-ID: <483708560.1232447248.160272644.39964@mcgi56.rambler.ru> Hi all. How use this key in labrary: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.7 (MingW32) - GPGshell v3.64 mI0DRTdn+AAAAQQAoN1Z575sGelB46K2PA3vpoAeiDojvis6jNF4KXLo+S5wuJn9 qyMzApoGkc1pC3J4p/r1xHwhTz+X29xb898fJo4IltLlpLwL1L6s0Bo4fM+UU4HX FM3tAreWMvrr0T2HYzhR/0yeoO2I5i4KsDOsU5RGQR/yxdL6jafGj6Lndv8ABRG0 M1Rlc3QgWWFuZGV4Lk1vbmV5IEhUVFAgRGVwb3NpdCA8c3VwcG9ydEB5YW1vbmV5 LnJ1PoiVAwUQRTdn+I2nxo+i53b/AQGRMgP/ej33fJGAvXO36sBAB7VoBZpcARvd oN8V6zHLB7R3nAkvoYJzJFwZHF7Y1JIt+h0838R5D2UziAqW8bvwvK98SfRQvtDi 6AYnsQUtBSJuHNLqEUaJQUoZbA3ULpcWsq5cYM63Q4H7XBFYqZxtrxsU8SanOMWE s377NEClNMt2h48= =JIs1 -----END PGP PUBLIC KEY BLOCK----- From wk at gnupg.org Tue Jan 20 12:19:15 2009 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Jan 2009 12:19:15 +0100 Subject: libgcrypt In-Reply-To: <483708560.1232447248.160272644.39964@mcgi56.rambler.ru> (GIS GIS's message of "Tue, 20 Jan 2009 13:27:28 +0300") References: <483708560.1232447248.160272644.39964@mcgi56.rambler.ru> Message-ID: <87priiql70.fsf@wheatstone.g10code.de> On Tue, 20 Jan 2009 11:27, gisvlad at rambler.ru said: > How use this key in labrary: > > -----BEGIN PGP PUBLIC KEY BLOCK----- Libgcrypt is a low-level library and not aware of any protocol like OpenPGP. Thus it is not for you. If you need a library to work with OpenPGP messages, checkout gpgme. http://gnupg.org/related_software/gpgme Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Thu Jan 22 19:57:08 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 22 Jan 2009 19:57:08 +0100 Subject: Libgcrypt 1.4.4 released Message-ID: <87ab9jp3sr.fsf@wheatstone.g10code.de> Hello! The GNU project is pleased to announce the availability of Libgcrypt version 1.4.4. Libgcrypt is a general purpose library of cryptographic building blocks. It is originally based on code used by GnuPG. It does not provide any implementation of OpenPGP or other protocols. Thorough understanding of applied cryptography is required to use Libgcrypt. Noteworthy changes in version 1.4.4: * Publish GCRY_MODULE_ID_USER and GCRY_MODULE_ID_USER_LAST constants. This functionality has been in Libgcrypt since 1.3.0. * MD5 may now be used in non-enforced fips mode. * Fixed HMAC for SHA-384 and SHA-512 with keys longer than 64 bytes. * In fips mode, RSA keys are now generated using the X9.31 algorithm and DSA keys using the FIPS 186-2 algorithm. * The transient-key flag is now also supported for DSA key generation. DSA domain parameters may be given as well. Source code is hosted at the GnuPG FTP server and its mirrors as listed at http://www.gnupg.org/download/mirrors.html . On the primary server the source file and its digital signatures is: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.4.tar.bz2 (1116k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.4.tar.bz2.sig This file is bzip2 compressed. A gzip compressed version is also available: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.4.tar.gz (1387k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.4.tar.gz.sig Alternativley you may upgrade version 1.4.3 using this patch file: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.3-1.4.4.diff.bz2 (90k) The SHA-1 checksums are: 6f156593ce0833856b59580a7d430d0a5153b324 libgcrypt-1.4.4.tar.gz 3987f0efcbb7048c136d5c859e88eee1763a14f6 libgcrypt-1.4.4.tar.bz2 51947f0753ac61af96e075fcb5a1d4a6305c284b libgcrypt-1.4.3-1.4.4.diff.bz2 For help on developing with Libgcrypt you should read the included manual and optional ask on the gcrypt-devel mailing list [1]. Improving Libgcrypt is costly, but you can help! We are looking for organizations that find Libgcrypt useful and wish to contribute back. You can contribute by reporting bugs, improve the software [2], order extensions or support or more general by donating money to the Free Software movement [3]. Commercial support contracts for Libgcrypt are available [4], and they help finance continued maintenance. g10 Code GmbH, a Duesseldorf based company, is currently funding Libgcrypt development. We are always looking for interesting development projects. Many thanks to all who contributed to Libgcrypt development, be it bug fixes, code, documentation, testing or helping users. Happy hacking, Werner [1] See http://www.gnupg.org/documentation/mailing-lists.html . [2] Note that copyright assignments to the FSF are required. [3] For example see http://donate.fsf.org . [4] See the service directory at http://www.gnupg.org/service.html . -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 205 bytes Desc: not available URL: From wk at gnupg.org Thu Jan 22 20:29:57 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 22 Jan 2009 20:29:57 +0100 Subject: "initializer does not fit or is out of range" warnings with Sun C compiler In-Reply-To: <20081017192426.GC2792@honinbu.il.thewrittenword.com> (Albert Chin's message of "Fri, 17 Oct 2008 14:24:26 -0500") References: <20081017192426.GC2792@honinbu.il.thewrittenword.com> Message-ID: <87fxjbnnpm.fsf@wheatstone.g10code.de> On Fri, 17 Oct 2008 21:24, gcrypt-devel at mlists.thewrittenword.com said: > The Sun C compiler gives the following warning when compiling > src/hmac256.c: > > cc -DHAVE_CONFIG_H -I. -I.. -DSTANDALONE -mr -Qn -xstrconst -xO2 -xtarget=ultra2 -xarch=v8plusa -c -o hmac256-hmac256.o `test -f 'hmac256.c' || echo './'`hmac256.c > "hmac256.c", line 535: warning: initializer does not fit or is out of range: 220 I guess that char is signed and initializing with a value > 127 leads to this error. I changed the type to an unsigned char array in 1.4.4. Thanks, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Thu Jan 22 20:27:52 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 22 Jan 2009 20:27:52 +0100 Subject: Returning value in void function in 1.4.3 In-Reply-To: <20081017182837.GA2792@honinbu.il.thewrittenword.com> (Albert Chin's message of "Fri, 17 Oct 2008 13:28:37 -0500") References: <20081017182837.GA2792@honinbu.il.thewrittenword.com> Message-ID: <87ocxznnt3.fsf@wheatstone.g10code.de> On Fri, 17 Oct 2008 20:28, gcrypt-devel at mlists.thewrittenword.com said: > "random.c", line 322: void function cannot return value Fixed in 1.4.4. Thanks, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Thu Jan 22 20:27:19 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 22 Jan 2009 20:27:19 +0100 Subject: CL_AS_NOEXECSTACK assumes grep understands -q In-Reply-To: <20081017182756.GF2789@honinbu.il.thewrittenword.com> (Albert Chin's message of "Fri, 17 Oct 2008 13:27:56 -0500") References: <20081017182756.GF2789@honinbu.il.thewrittenword.com> Message-ID: <87sknbnnu0.fsf@wheatstone.g10code.de> On Fri, 17 Oct 2008 20:27, gcrypt-devel at mlists.thewrittenword.com said: > Solaris grep doesn't understand -q, used in CL_AS_NOEXECSTACK by > m4/noexecstack.m4 for libgcrypt-1.4.3. Done. Thanks, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Thu Jan 22 20:28:17 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 22 Jan 2009 20:28:17 +0100 Subject: Duplicate const type specifier In-Reply-To: <20081017192145.GB2792@honinbu.il.thewrittenword.com> (Albert Chin's message of "Fri, 17 Oct 2008 14:21:45 -0500") References: <20081017192145.GB2792@honinbu.il.thewrittenword.com> Message-ID: <87k58nnnse.fsf@wheatstone.g10code.de> On Fri, 17 Oct 2008 21:21, gcrypt-devel at mlists.thewrittenword.com said: > The Sun, HP, and IRIX C compilers complain (or error out) with a > duplicate type specifier for the following in libgcrypt-1.4.3: > const char const ... Changed for 1.4.4. Thanks, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Thu Jan 22 20:32:29 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 22 Jan 2009 20:32:29 +0100 Subject: [PATCH] optional test code building In-Reply-To: <200811041641.47742.dragonheart@gentoo.org> (Daniel Black's message of "Tue, 4 Nov 2008 16:41:43 +1100") References: <200811041641.47742.dragonheart@gentoo.org> Message-ID: <87bptznnle.fsf@wheatstone.g10code.de> On Tue, 4 Nov 2008 06:41, dragonheart at gentoo.org said: > Diego protested[1] and blogged[2] not to build examples or tests when > distributors make code. To facilitate this an example[3] was suggested and I I don't think that this is a good idea. This won't allow to run the selftests. The selftests are there for a reason. If you don't like that just change it in your system. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From christof.schulze at gmx.net Wed Jan 28 21:43:59 2009 From: christof.schulze at gmx.net (Christof Schulze) Date: Wed, 28 Jan 2009 21:43:59 +0100 Subject: behavior of gcrypt depending on input data: "conflicting use" In-Reply-To: <87k58qs770.fsf@wheatstone.g10code.de> References: <20090119205931.7c2a6e01@ccschu935> <87k58qs770.fsf@wheatstone.g10code.de> Message-ID: <200901282144.05336.christof.schulze@gmx.net> Hello Werner, thank you very much, after replacing the line the code works. Christof Am Dienstag 20 Januar 2009 09:38:43 schrieb Werner Koch: > Hi, > > Instead of: > > error = gcry_mpi_scan (&mpival, GCRYMPI_FMT_USG, > digest, hash_len, &nscanned ); > assert ( error == 0 ); > printf ( "nscanned: %lu\n", nscanned ); > > rc = gcry_sexp_build ( sign_parms, &errof, > "(data (flags pkcs1) (hash %s %m))", > HASH_NAME, mpival ); > assert ( rc == 0 ); > gcry_mpi_release ( mpival ); > > you should better do: > > rc = gcry_sexp_build (sign_parms, NULL, > "(data (flags pkcs1)(hash %s %b))", > HASH_NAME, (int)hash_len, digest); > > > I have not looked at the actual problem with %m. If you want to figure > that out, you need to check the MPI and the resulting S-expression, for > example by inserting > > gcry_mpi_dump (mpival); putc (.'\n', stderr); > gcry_sexp_dump (*sign_parms) > > > > Shalom-Salam, > > Werner > > > > p.s. In general it is better to insert the actual code into the message > so that it is possible to answer even without an online connection. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: