From wk at gnupg.org Wed Feb 2 16:46:03 2005 From: wk at gnupg.org (Werner Koch) Date: Wed Feb 2 16:45:40 2005 Subject: libgcrypt configure fixes In-Reply-To: <20050122201627.GG91810@mail1.thewrittenword.com> (Albert Chin's message of "Sat, 22 Jan 2005 14:16:27 -0600") References: <20050122201627.GG91810@mail1.thewrittenword.com> Message-ID: <87wttrj77o.fsf@wheatstone.g10code.de> Hi Albert, 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 ;-) Werner From bitbucket at securitypunk.com Sun Feb 6 04:48:12 2005 From: bitbucket at securitypunk.com (Anonymous) Date: Sun Feb 6 07:44:39 2005 Subject: How to compile libgcrypt.dll Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi -- Below are the steps necessary to compile libgcrypt v1.2.1 into a Windows DLL: 0.) Download & install MinGW, MSYS, and msysDTK (http://www.mingw.org/) 1.) Within an MSYS shell, compile and install libgpg-error: $ tar xjf libgpg-error-1.0.tar.bz2 $ cd libgpg-error-1.0 $ ./configure && make && make install 2.) Download this patch into the '~/libgcrypt-1.2.1' directory and apply it to the libgcrypt sources: http://www.securitypunk.com/misc/libgcrypt_dll.patch $ tar xjf libgcrypt-1.2.1.tar.bz2 $ cd libgcrypt-1.2.1 $ patch -p1 < libgcrypt_dll.patch 3.) Regenerate the 'configure' script: $ aclocal -I . $ automake --add-missing --copy $ autoconf 4.) Compile and install: $ ./configure && make && make install 5.) Download the DLL export list into the '~/libgcrypt-1.2.1' directory and build the DLL: http://www.securitypunk.com/misc/libgcrypt.def $ gcc -shared -o libgcrypt.dll libgcrypt.def \ /usr/local/lib/libgcrypt.a /usr/local/lib/libgpg-error.a 6.) Optionally, you may want to strip the DLL file of debugging symbols, as this will shrink the file size down from ~3MB to ~300KB: $ strip libgcrypt.dll 7.) If you are going to use MSYS to continue developing with the libgcrypt DLL, you need to remove the installed 'libgcrypt.a' file otherwise you'll get very strange linker errors (I think this is a MinGW bug...): $ rm /usr/local/lib/libgcrypt.a The patch applied to the libgcrypt sources should only be used to create the DLL. If you attempt to link libgcrypt staticly after the patch was applied, the random number generator will fail since it is initialized inside DllMain() (which is normally called by Windows after the DLL is loaded). So, all of the test programs in the 'tests/' directory will fail. This is normal. This patch also replaces the very slow win32 entropy gatherer included in libgcrypt with much faster CryptoAPI functions. - Joe P.S. To the libgcrypt team: could you please apply the 'acinclude.m4' patch block to the official sources? Thanks! - -- http://www.securitypunk.com/ http://www.hacktivismo.com/ http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD0E127F7 BF7E 3227 FF82 466E 7FA1 305D 02BC D51A D0E1 27F7 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCBYayArzVGtDhJ/cRAlJBAJ9LFEDAP6WXSUo6Q+pkKXeyyn4pHgCfY8I4 wYkXnHe1DtswBm+xo0gI+bI= =gm8w -----END PGP SIGNATURE----- -- This e-mail was sent anonymously. Do not reply to it. If this e-mail contains any threatening or harassing content, please visit http://www.securitypunk.com/mailer/abuse.hax From N.Durner at t-online.de Mon Feb 7 19:51:49 2005 From: N.Durner at t-online.de (N. Durner) Date: Mon Feb 7 21:26:44 2005 Subject: How to compile libgcrypt.dll In-Reply-To: References: Message-ID: <4207B8C5.6050300@t-online.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, > Below are the steps necessary to compile libgcrypt v1.2.1 into a > Windows DLL Good work! To create the DLL I had to append "-lintl": $ gcc -shared -o libgcrypt.dll libgcrypt.def \ /usr/local/lib/libgcrypt.a /usr/local/lib/libgpg-error.a -lintl I have created an import library with: $ dlltool -D libgcrypt.dll -d libgcrypt.def -l libgcrypt.dll.a To compile another application against libgcrypt I edited lib/libgcrypt.la by hand and removed the reference to gpg-error from bin/libgcrypt-config. A binary developer package is available at http://www.gnunet.org/download/win/libgcrypt-1.2.1.zip Signature: http://www.gnunet.org/download/win/libgcrypt-1.2.1.zip.asc Thanks, Nils Durner -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCB7jFzu0bosz8D+MRAgYGAJwORKf2xjtrVkFGTmfIc5ixLWDxNwCfdPf3 rXcHXu60EVH8rB7mS/PYMCw= =1cLl -----END PGP SIGNATURE----- From wk at gnupg.org Tue Feb 8 11:19:35 2005 From: wk at gnupg.org (Werner Koch) Date: Tue Feb 8 11:15:49 2005 Subject: How to compile libgcrypt.dll In-Reply-To: (bitbucket@securitypunk.com's message of "Sat, 5 Feb 2005 22:48:12 -0500 (EST)") References: Message-ID: <87k6pj5p6w.fsf@wheatstone.g10code.de> On Sat, 5 Feb 2005 22:48:12 -0500 (EST), Anonymous said: > $ gcc -shared -o libgcrypt.dll libgcrypt.def \ > /usr/local/lib/libgcrypt.a /usr/local/lib/libgpg-error.a Please do us all a favor and don't name the DLL libgcrypt - we might want to use this for an "official" DLL version. In particular not with a version changed in a way this patch does. > This patch also replaces the very slow win32 entropy gatherer included > in libgcrypt with much faster CryptoAPI functions. ... and unknown properties. Werner From bitbucket at securitypunk.com Thu Feb 10 03:41:16 2005 From: bitbucket at securitypunk.com (Anonymous) Date: Thu Feb 10 10:40:04 2005 Subject: How to compile libgcrypt.dll Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Please do us all a favor and don't name the DLL libgcrypt - we might > want to use this for an "official" DLL version. In particular not > with a version changed in a way this patch does. Agreed. The patch I provided wasn't meant for production uses; it was just to help developers get started on the Win32 platform. >> This patch also replaces the very slow win32 entropy gatherer included >> in libgcrypt with much faster CryptoAPI functions. > >... and unknown properties. True, but the provided entropy gatherer for win32 is too slow to be practical. On a 1.6Ghz desktop machine under 'normal' load, 1024-bit DSA signatures take *45 seconds* to compute. This delay is unacceptable for my application's handshake phase which is designed to timeout after 30 seconds of inactivity. Note that the same signing operation takes 1-2 seconds on that same machine when it runs Linux. Since it sounds like you're not a big fan of switching completely to the CryptoAPI, would you be interested if I wrote an improved patch to add a /configure option to include it? - Joe - -- http://www.securitypunk.com/ http://www.hacktivismo.com/ http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD0E127F7 BF7E 3227 FF82 466E 7FA1 305D 02BC D51A D0E1 27F7 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCCskMArzVGtDhJ/cRAkIaAJ9M9WPaT1RP6Sd7NZ8gIOroll/j7QCgjf1Q q7T0dHSfXOCVLc0d6FHJ/t4= =RK9V -----END PGP SIGNATURE----- -- This e-mail was sent anonymously. Do not reply to it. If this e-mail contains any threatening or harassing content, please visit http://www.securitypunk.com/mailer/abuse.hax From wk at gnupg.org Thu Feb 10 12:37:55 2005 From: wk at gnupg.org (Werner Koch) Date: Thu Feb 10 12:35:48 2005 Subject: How to compile libgcrypt.dll In-Reply-To: (bitbucket@securitypunk.com's message of "Wed, 9 Feb 2005 21:41:16 -0500 (EST)") References: Message-ID: <877jlgtzl8.fsf@wheatstone.g10code.de> On Wed, 9 Feb 2005 21:41:16 -0500 (EST), Anonymous said: > practical. On a 1.6Ghz desktop machine under 'normal' load, 1024-bit > DSA signatures take *45 seconds* to compute. This delay is unacceptable I don't have these problems. The trick is to keep the random state on disk so that random of quality GCRY_STRONG_RANDOM (which is sufficient for the DSA's K as well as for session keys) does not require to initialzie the pool from scratch. Simply do a gcry_control (GCRYCTL_SET_RANDOM_SEED_FILE, filename); at startup to read the existing random seed and a gcry_control (GCRYCTL_UPDATE_RANDOM_SEED_FILE); right before you exit your process. > Since it sounds like you're not a big fan of switching completely to the > CryptoAPI, would you be interested if I wrote an improved patch to add a No thanks. Werner From mo at g10code.com Sat Feb 12 18:25:59 2005 From: mo at g10code.com (Moritz Schulte) Date: Sat Feb 12 18:58:39 2005 Subject: RSA Key and signature lengths using gcry_pk_genkey/sign In-Reply-To: <57b7ed00050123055124692442@mail.gmail.com> References: <57b7ed00050123055124692442@mail.gmail.com> Message-ID: <20050212172559.GB9565@sarkutty> On Sun, Jan 23, 2005 at 01:51:51PM +0000, James Hume wrote: Hello James, > I am using the gcry_pk_* functions to generate keys and > signatures. I have seen that sometimes the key lengths can vary, as > can the signature length which either seems to be 128 bytes or 129 > bytes (in which case there always seems to be a leading null byte). I assume that you are converting an MPI into an octet string with gcry_mpi_print() according to GCRYMPI_FMT_STD. Whenever the given MPI has the most significant bit set and FMT_STD is requested, the mentioned function does add a null byte at the beginning of the octet string representation. This is done in order to be able to distinguish signed integers from unsigned ones (an integer is recognized as a negative one when the most signifant bit is set). In case you don't need to consider signed integers at all, just use GCRYMPI_FMT_USG, which does not do the padding you seem to have wondered about. 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/20050212/d357b10b/attachment.pgp From gcrypt at kaervek.net Wed Feb 23 22:41:20 2005 From: gcrypt at kaervek.net (Ralf H) Date: Wed Feb 23 23:52:58 2005 Subject: Using libgcrypt on large files Message-ID: <1109194880.18226.14.camel@helios> Hello, I am thinking about using libgcrypt to sign files, which I will deploy during an update phase to customers. With the signature I want to check the integrity (of course :)). Even though I would not use quite large files at the beginning, I am not sure if this will always be true. Right now I use the following code to get the signature: rc = gcry_sexp_build (&sign_parms, &errof, "(data (flags) (value \"%s\"))\n", data); rc = gcry_pk_sign (&sig, sign_parms, skey); (Found that code on the net). I am not sure about 2 things here. 1) I want to sign binary data, to use the code above, I would have to escape/remove nulls, otherwise gcry_sexp_build will fail. Is there any other function I could use instead? Performance wise this looks a little bit suspicous to me. 2) What can I do if the file is really large and will not fit into memory? My approach will obviously fail, as I need everything in 'data' :(. Is there a way to hash a file in little portions, so I can read in buffers and update my signatures in a loop? Thanks for you help Ralf From mo at g10code.com Thu Feb 24 06:37:56 2005 From: mo at g10code.com (Moritz Schulte) Date: Thu Feb 24 06:34:15 2005 Subject: Using libgcrypt on large files In-Reply-To: <1109194880.18226.14.camel@helios> References: <1109194880.18226.14.camel@helios> Message-ID: <20050224053756.GA8345@sarkutty> On Wed, Feb 23, 2005 at 10:41:20PM +0100, Ralf H wrote: > 2) What can I do if the file is really large and will not fit into > memory? My approach will obviously fail, as I need everything in > 'data' :(. Is there a way to hash a file in little portions, so I can > read in buffers and update my signatures in a loop? No, no: *hash* your file; with gcry_md_*() functions. And then, sign the *hash value* (optionally with pkcs1) - not the file data itself. Have a look at the Libgcrypt manual, 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/20050224/246fc5a1/attachment.pgp From jrydberg at gnu.org Thu Feb 24 06:44:23 2005 From: jrydberg at gnu.org (Johan Rydberg) Date: Thu Feb 24 07:20:45 2005 Subject: Using libgcrypt on large files In-Reply-To: <1109194880.18226.14.camel@helios> (Ralf H.'s message of "Wed, 23 Feb 2005 22:41:20 +0100") References: <1109194880.18226.14.camel@helios> Message-ID: <87hdk2h5qg.fsf@night.trouble.net> Ralf H writes: > Hello, > [...] > Even though I would not use quite large files at the beginning, I am not > sure if this will always be true. > 1) I want to sign binary data, to use the code above, I would have to > escape/remove nulls, otherwise gcry_sexp_build will fail. Is there any > other function I could use instead? Performance wise this looks a little > bit suspicous to me. > > 2) What can I do if the file is really large and will not fit into > memory? My approach will obviously fail, as I need everything in > 'data' :(. Is there a way to hash a file in little portions, so I can > read in buffers and update my signatures in a loop? I suggest that instead you just sign, for example, a SHA-1 hash of the file contents. ~j From gcrypt at kaervek.net Thu Feb 24 13:20:58 2005 From: gcrypt at kaervek.net (Ralf H) Date: Thu Feb 24 13:16:22 2005 Subject: Using libgcrypt on large files In-Reply-To: <20050224053756.GA8345@sarkutty> References: <1109194880.18226.14.camel@helios> <20050224053756.GA8345@sarkutty> Message-ID: <1109247658.32649.2.camel@helios> On Thu, 2005-02-24 at 06:37 +0100, Moritz Schulte wrote: > On Wed, Feb 23, 2005 at 10:41:20PM +0100, Ralf H wrote: > > > 2) What can I do if the file is really large and will not fit into > > memory? My approach will obviously fail, as I need everything in > > 'data' :(. Is there a way to hash a file in little portions, so I can > > read in buffers and update my signatures in a loop? > > No, no: *hash* your file; with gcry_md_*() functions. And then, sign > the *hash value* (optionally with pkcs1) - not the file data itself. > Have a look at the Libgcrypt manual, > Thanks a million, Moritz. That was the push in the right direction I needed. Everything works like a charm now :) From wk at gnupg.org Thu Feb 24 14:22:44 2005 From: wk at gnupg.org (Werner Koch) Date: Thu Feb 24 14:21:05 2005 Subject: Using libgcrypt on large files In-Reply-To: <1109194880.18226.14.camel@helios> (Ralf H.'s message of "Wed, 23 Feb 2005 22:41:20 +0100") References: <1109194880.18226.14.camel@helios> Message-ID: <87is4i5byz.fsf@wheatstone.g10code.de> On Wed, 23 Feb 2005 22:41:20 +0100, Ralf H said: > I am thinking about using libgcrypt to sign files, which I will deploy > during an update phase to customers. With the signature I want to check > the integrity (of course :)). Don't do this at all! Use an established protocol to sign stuff and nothing homegrown. Getting this all right is not easy in particular if you don't have any experience in this field. Libgcrypt merely provides the building blocksto implement such a protocol (OpenPGP, CMS). If you need a library, have a look at GPGME. Salam-Shalom, Werner From madelman at iname.com Thu Feb 24 13:41:00 2005 From: madelman at iname.com (Madelman) Date: Thu Feb 24 14:29:09 2005 Subject: Problem when hashing Message-ID: <421DCB5C.20404@iname.com> Hi, i have one problem trying to hash some data. This is the code: unsigned char hash[20]; gcry_md_hash_buffer(GCRY_MD_SHA1, hash, sessionKey, 16); gcry_mpi_scan(&mpiHash, GCRYMPI_FMT_USG, hash, 20, NULL); gcry_sexp_build(&data, &erroff, "(data (flags pkcs1) (hash sha1 %m))", mpiHash); err = gcry_pk_sign(&signedKey, data, privateKey); if (err) printf("%s", gcry_strerror(err)); The error it gives to me is Conflicting use. I've debugging it and the cause of this is the hash in the S-Expression has a length of 21 instead of 20, here is a print of it: (data (flags pkcs1) (hash sha1 #00EAE3734D9EA7394FCBEE92ADB05994B5083827FC#) ) So, I suppose it is caused by the leading zero byte in the hash, but where does this byte come from? How can I solve this problem? Thanks. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 1822 bytes Desc: S/MIME Cryptographic Signature Url : /pipermail/attachments/20050224/7f9ccb72/smime.bin From wk at gnupg.org Thu Feb 24 15:20:48 2005 From: wk at gnupg.org (Werner Koch) Date: Thu Feb 24 15:21:11 2005 Subject: Problem when hashing In-Reply-To: <421DCB5C.20404@iname.com> (madelman@iname.com's message of "Thu, 24 Feb 2005 13:41:00 +0100") References: <421DCB5C.20404@iname.com> Message-ID: <877jky59a7.fsf@wheatstone.g10code.de> On Thu, 24 Feb 2005 13:41:00 +0100, Madelman said: > So, I suppose it is caused by the leading zero byte in the hash, but where does > this byte come from? How can I solve this problem? That is to mark the number as positive. What you should do is to use unsigned char md[20]; ... rc = gcry_sexp_build (&hash, NULL, "(data (flags pkcs1) (hash sha1 %b))", (size_t)20, md); That's far easier, isn't it? Make sure that the first argument of %b has the type size_t, the second one is a pointer of course. Shalom-Salam, Werner From madelman at iname.com Fri Feb 25 12:11:39 2005 From: madelman at iname.com (Madelman) Date: Fri Feb 25 12:04:53 2005 Subject: Encrypting with ECB Message-ID: <421F07EB.5090102@iname.com> Hi, >That is to mark the number as positive. What you should do is to use > > unsigned char md[20]; > > ... > rc = gcry_sexp_build (&hash, NULL, > "(data (flags pkcs1) (hash sha1 %b))", > (size_t)20, md); > >That's far easier, isn't it? Make sure that the first argument of %b >has the type size_t, the second one is a pointer of course. Yeah, much better, thanks :) I have another question. I'm trying to encrypt a single block of data with the following code: gcry_cipher_open(&hd, GCRY_CIPHER_AES, GCRY_CIPHER_MODE_ECB, 0); gcry_cipher_setkey(hd, sessionKey, 16); gcry_cipher_encrypt(hd, cipherText, length, plainText, length); but i can't get a correct result, if i try to print the cipherText the result is (data BBBBBBBBBB) but if i try with a different mode like opening the handle with gcry_cipher_open(&hd, GCRY_CIPHER_AES, GCRY_CIPHER_MODE_CTR, 0); and setting the initial counter it works correctly and i can decipher the text. If I understood it correctly in ECB mode I don't need to set the IV, but even if I try setting it the result is the same. Do you know what I'm doing wrong? Thanks. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 1822 bytes Desc: S/MIME Cryptographic Signature Url : /pipermail/attachments/20050225/f17cd98a/smime.bin From madelman at iname.com Fri Feb 25 21:30:47 2005 From: madelman at iname.com (Madelman) Date: Fri Feb 25 21:24:12 2005 Subject: List of supported algorithms Message-ID: <421F8AF7.9060906@iname.com> Hi, is there any way to get a list of all supported algorithms, whether cipher algorithms or hash algorithms? Thanks. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 1822 bytes Desc: S/MIME Cryptographic Signature Url : /pipermail/attachments/20050225/f9cf3c7d/smime.bin From wk at gnupg.org Fri Feb 25 23:03:52 2005 From: wk at gnupg.org (Werner Koch) Date: Fri Feb 25 23:01:05 2005 Subject: Encrypting with ECB In-Reply-To: <421F07EB.5090102@iname.com> (madelman@iname.com's message of "Fri, 25 Feb 2005 12:11:39 +0100") References: <421F07EB.5090102@iname.com> Message-ID: <87mztsz48n.fsf@wheatstone.g10code.de> On Fri, 25 Feb 2005 12:11:39 +0100, Madelman said: > gcry_cipher_open(&hd, GCRY_CIPHER_AES, GCRY_CIPHER_MODE_ECB, 0); ECB? Not sure that has ever been tested. Better send plaintext than using ECB. > If I understood it correctly in ECB mode I don't need to set the IV, but even if There is no chaining at all with ECB thus no IV. Don't use it. Werner From mo at g10code.com Sun Feb 27 23:04:24 2005 From: mo at g10code.com (Moritz Schulte) Date: Sun Feb 27 23:00:38 2005 Subject: List of supported algorithms In-Reply-To: <421F8AF7.9060906@iname.com> References: <421F8AF7.9060906@iname.com> Message-ID: <20050227220424.GA5828@sarkutty> On Fri, Feb 25, 2005 at 09:30:47PM +0100, Madelman wrote: > is there any way to get a list of all supported algorithms, > whether cipher algorithms or hash algorithms? See the manual; gcry_{cipher,md,pubkey}_list() exist. Thanks, Moritz -- Moritz Schulte