From tthomas at chubb.com Wed Jun 1 13:09:27 2005 From: tthomas at chubb.com (Tod Thomas) Date: Wed Jun 1 13:08:48 2005 Subject: **SPAM** Re: Little help please... In-Reply-To: <873bsexcd8.fsf@wheatstone.g10code.de> References: <428E3980.3010505@chubb.com> <42907D82.8000004@hunt.org> <4291DEAF.2070001@chubb.com> <873bsexcd8.fsf@wheatstone.g10code.de> Message-ID: <429D9767.8020203@chubb.com> Werner Koch wrote: > On Mon, 23 May 2005 09:46:23 -0400, Tod Thomas said: > > >>err = gcry_cipher_setkey(hd, key, keylen); > > > Use a fixed key for testing, like > > err = gcry_cipher_setkey(hd, "123456789abcdef0", 16 ); This triggered something that led me to solve my problem. My key length was too short, for some reason I thought the key length was variable. Oddly though, none of the API calls flagged me for an invalid key length... >>gcry_cipher_decrypt(hd,decryptedtext,strlen(ciphertext),ciphertext,strlen(ciphertext)); > > > This won't work: You can't use strlen on CIPHERTEXT becuase that one > is binary. Won't it? All strings ultimately are just binary data. > > Shalom-Salam, > > Werner Thanks for your help. From bradh at frogmouth.net Wed Jun 1 13:18:00 2005 From: bradh at frogmouth.net (Brad Hards) Date: Wed Jun 1 13:14:48 2005 Subject: **SPAM** Re: Little help please... In-Reply-To: <429D9767.8020203@chubb.com> References: <428E3980.3010505@chubb.com> <873bsexcd8.fsf@wheatstone.g10code.de> <429D9767.8020203@chubb.com> Message-ID: <200506012118.08131.bradh@frogmouth.net> On Wed, 1 Jun 2005 21:09 pm, Tod Thomas wrote: > >>gcry_cipher_decrypt(hd,decryptedtext,strlen(ciphertext),ciphertext,strlen > >>(ciphertext)); > > > > This won't work: ?You can't use strlen on CIPHERTEXT becuase that one > > is binary. > > Won't it? ?All strings ultimately are just binary data. But binary data will contain arbitrary nulls. strlen just looks for the first one. 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/20050601/8a219296/attachment.pgp From tthomas at chubb.com Wed Jun 1 17:11:59 2005 From: tthomas at chubb.com (Tod Thomas) Date: Wed Jun 1 17:11:35 2005 Subject: Little help please... In-Reply-To: <200506012118.08131.bradh@frogmouth.net> References: <428E3980.3010505@chubb.com> <873bsexcd8.fsf@wheatstone.g10code.de> <429D9767.8020203@chubb.com> <200506012118.08131.bradh@frogmouth.net> Message-ID: <429DD03F.7010802@chubb.com> Brad Hards wrote: > On Wed, 1 Jun 2005 21:09 pm, Tod Thomas wrote: > >>>>gcry_cipher_decrypt(hd,decryptedtext,strlen(ciphertext),ciphertext,strlen >>>>(ciphertext)); >>> >>>This won't work: You can't use strlen on CIPHERTEXT becuase that one >>>is binary. >> >>Won't it? All strings ultimately are just binary data. > > But binary data will contain arbitrary nulls. strlen just looks for the first > one. > > Brad I was wondering about that. What is the accepted way to gather the 'length' of a binary value like this? sizeof()? From wk at gnupg.org Wed Jun 1 18:44:46 2005 From: wk at gnupg.org (Werner Koch) Date: Wed Jun 1 18:40:58 2005 Subject: Little help please... In-Reply-To: <429DD03F.7010802@chubb.com> (Tod Thomas's message of "Wed, 01 Jun 2005 11:11:59 -0400") References: <428E3980.3010505@chubb.com> <873bsexcd8.fsf@wheatstone.g10code.de> <429D9767.8020203@chubb.com> <200506012118.08131.bradh@frogmouth.net> <429DD03F.7010802@chubb.com> Message-ID: <87zmuayqkh.fsf@wheatstone.g10code.de> On Wed, 01 Jun 2005 11:11:59 -0400, Tod Thomas said: > I was wondering about that. What is the accepted way to gather the > 'length' of a binary value like this? sizeof()? You need to track the length somewhere. Salam-Shalom, Werner From tthomas at chubb.com Wed Jun 1 18:51:21 2005 From: tthomas at chubb.com (Tod Thomas) Date: Wed Jun 1 18:50:40 2005 Subject: Little help please... In-Reply-To: <87zmuayqkh.fsf@wheatstone.g10code.de> References: <428E3980.3010505@chubb.com> <873bsexcd8.fsf@wheatstone.g10code.de> <429D9767.8020203@chubb.com> <200506012118.08131.bradh@frogmouth.net> <429DD03F.7010802@chubb.com> <87zmuayqkh.fsf@wheatstone.g10code.de> Message-ID: <429DE789.2030409@chubb.com> Werner Koch wrote: > On Wed, 01 Jun 2005 11:11:59 -0400, Tod Thomas said: > > >>I was wondering about that. What is the accepted way to gather the >>'length' of a binary value like this? sizeof()? > > > You need to track the length somewhere. > > > Salam-Shalom, > > Werner > > Ok, thanks. From bradh at frogmouth.net Sun Jun 5 03:13:45 2005 From: bradh at frogmouth.net (Brad Hards) Date: Sun Jun 5 03:10:40 2005 Subject: Constructing a public key (pair) from component parts Message-ID: <200506051113.52125.bradh@frogmouth.net> Given the components of an RSA key (n, e, p, q, d), is there any way to construct a key that I can use for encryption/decryption/signing/verifying ops withing gcrypt? If so, can I have a hint? 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/20050605/54ecefa9/attachment.pgp From wk at gnupg.org Mon Jun 6 10:58:34 2005 From: wk at gnupg.org (Werner Koch) Date: Mon Jun 6 10:56:07 2005 Subject: Constructing a public key (pair) from component parts In-Reply-To: <200506051113.52125.bradh@frogmouth.net> (Brad Hards's message of "Sun, 5 Jun 2005 11:13:45 +1000") References: <200506051113.52125.bradh@frogmouth.net> Message-ID: <874qcbamkl.fsf@wheatstone.g10code.de> On Sun, 5 Jun 2005 11:13:45 +1000, Brad Hards said: > Given the components of an RSA key (n, e, p, q, d), is there any way to > construct a key that I can use for encryption/decryption/signing/verifying > ops withing gcrypt? Create an S-expression: (private-key (rsa (n NNNNNNNNNNNNN) (e EEEEEEEEEEEEE) (d DDDDDDDDDDDDD) (p PPPPPPPPPPPPP) (q QQQQQQQQQQQQQ) (u UUUUUUUUUUUUU))) Here is a snippet to create a canonical encoded S-expression using plain C. You may also use libgcrypt functions, which is easier. sexp = p = xmalloc_secure (30 + rsa_n_len + rsa_e_len + rsa_p_len + rsa_q_len + 4*sizeof (numbuf) + 25 + sizeof(numbuf) + 20); p = stpcpy (p,"(11:private-key(3:rsa(1:n"); sprintf (numbuf, "%u:", rsa_n_len); p = stpcpy (p, numbuf); memcpy (p, rsa_n, rsa_n_len); p += rsa_n_len; sprintf (numbuf, ")(1:e%u:", rsa_e_len); p = stpcpy (p, numbuf); memcpy (p, rsa_e, rsa_e_len); p += rsa_e_len; sprintf (numbuf, ")(1:p%u:", rsa_p_len); p = stpcpy (p, numbuf); memcpy (p, rsa_p, rsa_p_len); p += rsa_p_len; sprintf (numbuf, ")(1:q%u:", rsa_q_len); p = stpcpy (p, numbuf); memcpy (p, rsa_q, rsa_q_len); p += rsa_q_len; p = stpcpy (p,"))(10:created-at"); sprintf (numbuf2, "%lu", (unsigned long)sk->timestamp); sprintf (numbuf, "%d:", strlen (numbuf2)); p = stpcpy (stpcpy (stpcpy (p, numbuf), numbuf2), "))"); rc = agent_scd_writekey (keyno, sexp, p - sexp); Change above to also include D an U. If you don't have them, you may create them from P,Q,N,E. There is code in gnupg-1.9/agent/protect-tool.c#rsa_key_check which shows how to do it. Salam-Shalom, Werner From latze at iam.unibe.ch Wed Jun 8 12:54:32 2005 From: latze at iam.unibe.ch (Carolin Latze) Date: Wed Jun 8 13:44:50 2005 Subject: How to import external RSA keys Message-ID: <42A6CE68.3020405@iam.unibe.ch> Hello everybody, I'm looking for a possibility to import extern RSA keys into a program which is written using gcrypt.h. I want to encrypt and decrypt data using this program but I want to use RSA keys which are stored on a Cryptoflex Smartcard by Schlumberger. These keys should be stored an ASCII format (or something similar). Has anybody an idea how to import these keys into a program written with the gcrypt.h? Till now, I didn't find any.. :( Bye Carolin From EBopp at pelco.com Wed Jun 8 00:52:09 2005 From: EBopp at pelco.com (Bopp, Eric) Date: Wed Jun 8 14:05:22 2005 Subject: gcry_sexp_find_token() error checking Message-ID: Hello, We have found that passing bad data for the "list" parameter to the function gcry_sexp_find_token() can result in a segmentation fault. We are looking at ways to prevent sending bad data to the function but we also want to investigate ways to improve error checking in the function. The problem we are seeing is that when the function scans through the bad data it may find an ST_DATA (0x01) byte. When this happens the next two bytes are extracted and used to increment "p". The next dereference of "p" may cause a seg fault. One thing we are considering doing to decrease the chances of a seg fault occurring is to check the value of the first byte that "list" points to prior to entering the while loop. Here's what we have in mind: p = list->d; if ((*p != ST_OPEN) && (*p != ST_DATA)) return NULL; while (... Could someone more knowledgeable about the library tell me whether doing this will break the function? Thank you, Eric Bopp From wk at gnupg.org Fri Jun 10 12:00:04 2005 From: wk at gnupg.org (Werner Koch) Date: Fri Jun 10 11:56:15 2005 Subject: gcry_sexp_find_token() error checking In-Reply-To: (Eric Bopp's message of "Tue, 7 Jun 2005 15:52:09 -0700") References: Message-ID: <87k6l2pm57.fsf@wheatstone.g10code.de> On Tue, 7 Jun 2005 15:52:09 -0700 , Bopp, Eric said: > gcry_sexp_find_token() can result in a segmentation fault. We are looking > at ways to prevent sending bad data to the function but we also want to > investigate ways to improve error checking in the function. The problem we The really question here is how did it happen that you came up with inconsistent data. LIST is an internalmobject of libgcrypt and thus the actual must be somewhere in Libgcrypt at a place where LIST has been created or modified. > and used to increment "p". The next dereference of "p" may cause a seg while ( *p != ST_STOP ) { if ( *p == ST_OPEN && p[1] == ST_DATA ) { Failing at p[1] we can conclude that the CLOSE token is missing. > Could someone more knowledgeable about the library tell me whether doing > this will break the function? You would hide the real problem with such a workaround. Salam-Shalom, Werner From mo at g10code.com Sat Jun 11 17:15:06 2005 From: mo at g10code.com (Moritz Schulte) Date: Sat Jun 11 17:10:56 2005 Subject: How to import external RSA keys In-Reply-To: <42A6CE68.3020405@iam.unibe.ch> References: <42A6CE68.3020405@iam.unibe.ch> Message-ID: <20050611151506.GA12643@sarkutty> On Wed, Jun 08, 2005 at 12:54:32PM +0200, Carolin Latze wrote: > Has anybody an idea how to import these keys into a program written > with the gcrypt.h? I cannot give advice on the procedure of extracting the key from that specific card, I can give general advice, though: as you probably know, an RSA key consists of a few numbers (the so called `key material'). What you have to do is: * extract these numbers * figure out the format of the numbers * convert the numbers into a format supported by Libgcrypt * make sure that the semantics regarding the numbers p, q, u match those of Libgcrypt (u might need to be recomputed), * convert the numbers to Libgcrypt MPI objects * construct a complete key from the raw key material using either the sexp/pk interface or the ac interface. Hope this help a bit, Moritz -- Moritz Schulte From alangley at gmail.com Tue Jun 14 18:50:32 2005 From: alangley at gmail.com (Adam Langley) Date: Tue Jun 14 19:46:41 2005 Subject: CTR mode broken in libgcrypt 1.2.1 Message-ID: <396556a2050614095047c53910@mail.gmail.com> CTR mode is defined as[1]: Let C be the XOR (excusive-or) of M and the first |M| bits of the pad E(ctr) | E(ctr+1) | ... With libgcrypt 1.2.1 there is a message boundary bug. In short, E('abc') will cause E(ctr) to be calculated and the last 13 bytes to be discarded. E('def') will use another, fresh, E(ctr+1) and will discard another 13 bytes. This is incorrect (by [1] above, and by OpenSSL's implementation) The attached patch fixes this. This patch has been tested against code which uses OpenSSL for AES128 CTR. [1] http://csrc.nist.gov/CryptoToolkit/modes/workshop1/papers/lipmaa-ctr.pdf AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org (+44) (0)7906 332512 PGP: 9113 256A CC0F 71A6 4C84 5087 CDA5 52DF 2CB6 3D60 -------------- next part -------------- A non-text attachment was scrubbed... Name: ctr-mode.agl.patch Type: application/octet-stream Size: 2373 bytes Desc: not available Url : /pipermail/attachments/20050614/21ed1262/ctr-mode.agl-0001.obj From wk at gnupg.org Fri Jun 17 19:46:19 2005 From: wk at gnupg.org (Werner Koch) Date: Fri Jun 17 19:46:11 2005 Subject: CTR mode broken in libgcrypt 1.2.1 In-Reply-To: <396556a2050614095047c53910@mail.gmail.com> (Adam Langley's message of "Tue, 14 Jun 2005 17:50:32 +0100") References: <396556a2050614095047c53910@mail.gmail.com> Message-ID: <8764wcg9lg.fsf@wheatstone.g10code.de> On Tue, 14 Jun 2005 17:50:32 +0100, Adam Langley said: > With libgcrypt 1.2.1 there is a message boundary bug. In short, > E('abc') will cause E(ctr) to be calculated and the last 13 bytes to > be discarded. E('def') will use another, fresh, E(ctr+1) and will > discard another 13 bytes. This is incorrect (by [1] above, and by > OpenSSL's implementation) Thanks for reporting and for the patch. However, to apply this patch we need to get a copyright assignment for the FSF from you. That is a bit of a lengthly process so maybe we better fix it for ourself. If you are willing to sign a such an assignment (or a disclaimer) anyway and save us some work, please contact me by private mail. Shalom-Salam, Werner From alangley at gmail.com Fri Jun 17 20:53:06 2005 From: alangley at gmail.com (Adam Langley) Date: Fri Jun 17 20:49:14 2005 Subject: CTR mode broken in libgcrypt 1.2.1 In-Reply-To: <8764wcg9lg.fsf@wheatstone.g10code.de> References: <396556a2050614095047c53910@mail.gmail.com> <8764wcg9lg.fsf@wheatstone.g10code.de> Message-ID: <396556a2050617115352384b9c@mail.gmail.com> On 6/17/05, Werner Koch wrote: > Thanks for reporting and for the patch. However, to apply this patch > we need to get a copyright assignment for the FSF from you. That is a > bit of a lengthly process so maybe we better fix it for ourself. If > you are willing to sign a such an assignment (or a disclaimer) anyway > and save us some work, please contact me by private mail. The patch is tiny, so if the copyright assignment is a pain it might well be easier to close your eyes and type it in again. I should point out that since submitting the patch it has been noted that the NIST is contradictory on the subject of counter mode. There are documents which suggest that the current libgcrypt implementation is correct and some that favour my patch. My recommendation would be to either 1) drop the patch and make a big note in the documentation that the implemented cipher mode is not suitable for use as a stream cipher. 2) implement stream counter mode (e.g. my patch) as a separate mode. Sorry about the confusion. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org (+44) (0)7906 332512 PGP: 9113 256A CC0F 71A6 4C84 5087 CDA5 52DF 2CB6 3D60 From wk at gnupg.org Fri Jun 17 22:03:10 2005 From: wk at gnupg.org (Werner Koch) Date: Fri Jun 17 22:01:13 2005 Subject: CTR mode broken in libgcrypt 1.2.1 In-Reply-To: <396556a2050617115352384b9c@mail.gmail.com> (Adam Langley's message of "Fri, 17 Jun 2005 19:53:06 +0100") References: <396556a2050614095047c53910@mail.gmail.com> <8764wcg9lg.fsf@wheatstone.g10code.de> <396556a2050617115352384b9c@mail.gmail.com> Message-ID: <871x70g39d.fsf@wheatstone.g10code.de> On Fri, 17 Jun 2005 19:53:06 +0100, Adam Langley said: > I should point out that since submitting the patch it has been noted > that the NIST is contradictory on the subject of counter mode. There > are documents which suggest that the current libgcrypt implementation > is correct and some that favour my patch. Hmmm, I have no current use for CTR so I don't have a real opinion. Simon implemented it and thus he should decide. > 2) implement stream counter mode (e.g. my patch) as a separate mode. To keep backwards compatibility that is a better solution. Thanks, Werner From jas at extundo.com Fri Jun 17 21:39:40 2005 From: jas at extundo.com (Simon Josefsson) Date: Fri Jun 17 22:10:48 2005 Subject: CTR mode broken in libgcrypt 1.2.1 In-Reply-To: <396556a2050617115352384b9c@mail.gmail.com> (Adam Langley's message of "Fri, 17 Jun 2005 19:53:06 +0100") References: <396556a2050614095047c53910@mail.gmail.com> <8764wcg9lg.fsf@wheatstone.g10code.de> <396556a2050617115352384b9c@mail.gmail.com> Message-ID: Adam Langley writes: > I should point out that since submitting the patch it has been noted > that the NIST is contradictory on the subject of counter mode. There > are documents which suggest that the current libgcrypt implementation > is correct and some that favour my patch. The current libgcrypt implementation was done (by me) according to . There are even self tests against the test vectors in tests/simple.c. I'm not aware of any contradictory Counter mode description published by NIST. Can you give some more information? > [1] http://csrc.nist.gov/CryptoToolkit/modes/workshop1/papers/lipmaa-ctr.pdf That is one input paper, hardly authoritative. However, if your patch implement their idea of Counter mode, it may certainly be that it is useful too. Maybe you can ask them if they have come up with another name of their mode, given the conflict. > My recommendation would be to either > 1) drop the patch and make a big note in the documentation that the > implemented cipher mode is not suitable for use as a stream cipher. > 2) implement stream counter mode (e.g. my patch) as a separate mode. Both approaches sound better than changing the current implementation. Cheers, Simon From francesco.dolcini at students.cefriel.it Mon Jun 20 18:58:51 2005 From: francesco.dolcini at students.cefriel.it (Francesco Dolcini) Date: Mon Jun 20 19:29:48 2005 Subject: pkcs1 and ac interface Message-ID: <20050620165850.GA10657@localhost.localdomain> Hi, if I want to make gcrypt handle pkcs1 I have to use the s-expression interface? I have already written some code using the ac interface and now looking at the docs seems that I have to rewrite the code using s-exp or handle by hand the padding .... Thanks Francesco From mo at g10code.com Mon Jun 20 22:22:51 2005 From: mo at g10code.com (Moritz Schulte) Date: Mon Jun 20 22:18:29 2005 Subject: pkcs1 and ac interface In-Reply-To: <20050620165850.GA10657@localhost.localdomain> References: <20050620165850.GA10657@localhost.localdomain> Message-ID: <20050620202251.GA6176@sarkutty> On Mon, Jun 20, 2005 at 06:58:51PM +0200, Francesco Dolcini wrote: Hello, > Hi, if I want to make gcrypt handle pkcs1 I have to use the > s-expression interface? I have already written some code using the > ac interface and now looking at the docs seems that I have to > rewrite the code using s-exp or handle by hand the padding .... The CVS version of the developer branch of Libgcrypt contains an extended version of the ac interface, which comes with full pkcs1 support. I don't know yet, when we should release this code - will think about it and report back. Thanks, Moritz -- Moritz Schulte From ugabi at yahoo.com Tue Jun 28 12:17:22 2005 From: ugabi at yahoo.com (gabi uleia) Date: Tue Jun 28 13:13:30 2005 Subject: memory leak message at running "gcry_pk_genkey" function Message-ID: <20050628101722.86633.qmail@web32609.mail.mud.yahoo.com> I made a very simple example: gcry_sexp_t s_key; gcry_sexp_t s_keyparam; int rc; rc = FN_gcry_sexp_build(&s_keyparam, NULL, "(genkey(rsa(nbits %d)(rsa-use-e 3:257)))", HOSTKEY_LEN); rc = FN_gcry_pk_genkey(&s_key, s_keyparam); FN_gcry_pk_genkey is the gcry_pk_genkey function but readed dinamicaly from library (I cannot add at references of my project libgcrypt library). 1. The problem is that when FN_gcry_pk_genkey is reached program is stopped, I get the following message: Detected memory leaks! and my library is deployed. 2. Another question is if there are some sources which I can compile whitout minGW ? or a library for windows? __________________________________ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail