From bradh at frogmouth.net Mon Oct 2 02:20:49 2006 From: bradh at frogmouth.net (Brad Hards) Date: Mon Oct 2 03:10:31 2006 Subject: RSA Key Gen: Fast in Test App, Slow in Real App. In-Reply-To: <6380989.post@talk.nabble.com> References: <6380989.post@talk.nabble.com> Message-ID: <200610021020.54067.bradh@frogmouth.net> On Tuesday 19 September 2006 12:35, jitspoe wrote: > I made a test app to test RSA key generation and whatnot using gcrypt > directly. Generating a 128bit key pair is almost instant in the test app. > It takes less than a second. When I try using it in my real application (a > game), however, it takes several seconds to generate the key. The > libraries and function calls are identical. Any idea what the causes for > the speed differences are? I'm using Visual Studio 7.0 on Windows XP. I'm > not using secure memory or multithreading. On the face of it, you are doing something different between your test application and the real application. Try cutting down a copy of your real application towards your test application. You really haven't provided enough information to say more. However generating RSA keys "instantly" sounds a bit suspicious - perhaps you should review your code again. 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/20061002/57fe5e2c/attachment.pgp From yoder1 at us.ibm.com Mon Oct 2 23:29:04 2006 From: yoder1 at us.ibm.com (Kent E Yoder) Date: Tue Oct 3 11:40:10 2006 Subject: OAEP padding parameter Message-ID: Hi, Does libgcrypt allow explicitly setting the OAEP padding parameter used in RSA encryption? Please cc me on replies. Thanks, Kent From wk at gnupg.org Wed Oct 4 17:54:23 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Oct 4 17:57:33 2006 Subject: OAEP padding parameter In-Reply-To: (Kent E. Yoder's message of "Mon, 2 Oct 2006 16:29:04 -0500") References: Message-ID: <87sli4gjps.fsf@wheatstone.g10code.de> On Mon, 2 Oct 2006 23:29, Kent E Yoder said: > Does libgcrypt allow explicitly setting the OAEP padding parameter used > in RSA encryption? Sorry, there is no OAEP support yet. However, we can add it on demand. Salam-Shalom, Werner From yoder1 at us.ibm.com Wed Oct 4 18:42:10 2006 From: yoder1 at us.ibm.com (Kent E Yoder) Date: Thu Oct 5 07:56:31 2006 Subject: OAEP padding parameter In-Reply-To: <87sli4gjps.fsf@wheatstone.g10code.de> Message-ID: Hi Werner, > > Does libgcrypt allow explicitly setting the OAEP padding parameter used > > in RSA encryption? > > Sorry, there is no OAEP support yet. However, we can add it on demand. It would be very useful. I believe its the only feature keeping me from being able to migrate off OpenSSL's libcrypto to libgcrypt. Thanks, Kent From spizamme at hotmail.com Thu Oct 5 04:52:51 2006 From: spizamme at hotmail.com (jitspoe) Date: Thu Oct 5 07:56:32 2006 Subject: RSA Key Gen: Fast in Test App, Slow in Real App. In-Reply-To: <200610021020.54067.bradh@frogmouth.net> References: <6380989.post@talk.nabble.com> <200610021020.54067.bradh@frogmouth.net> Message-ID: <6651937.post@talk.nabble.com> Brad Hards wrote: > > On the face of it, you are doing something different between your test > application and the real application. Try cutting down a copy of your real > application towards your test application. > > You really haven't provided enough information to say more. However > generating > RSA keys "instantly" sounds a bit suspicious - perhaps you should review > your > code again. > > Brad > Thanks for the reply. Sorry if I didn't elaborate enough. The test code and the application code are identical. The only difference is that one is standalone, just for testing the functions, and the other is embedded into my application. The same gcrypt functions are called and in the same order. All I'm doing is generating a 128bit RSA key pair. I can post the source code if you're interested. Once the first RSA key has been generated, generating another is almost instant, so I'm guessing it's initializing some kind of prime table. I haven't delved into the gcrypt code to find out. -- View this message in context: http://www.nabble.com/RSA-Key-Gen%3A-Fast-in-Test-App%2C-Slow-in-Real-App.-tf2296684.html#a6651937 Sent from the GnuPG - Libgcrypt - Dev mailing list archive at Nabble.com. From wk at gnupg.org Thu Oct 5 09:15:20 2006 From: wk at gnupg.org (Werner Koch) Date: Thu Oct 5 09:22:34 2006 Subject: OAEP padding parameter In-Reply-To: (Kent E. Yoder's message of "Wed, 4 Oct 2006 11:42:10 -0500") References: Message-ID: <87sli3fd2v.fsf@wheatstone.g10code.de> On Wed, 4 Oct 2006 18:42, Kent E Yoder said: > It would be very useful. I believe its the only feature keeping me from > being able to migrate off OpenSSL's libcrypto to libgcrypt. I'll put it on my todo list. If you want to get it faster, please contact me at my company address. Shalom-Salam, Werner -- Werner Koch The GnuPG Experts http://g10code.com Join the Fellowship and protect your Freedom! http://www.fsfe.org From wk at gnupg.org Thu Oct 5 11:11:51 2006 From: wk at gnupg.org (Werner Koch) Date: Thu Oct 5 11:17:33 2006 Subject: RSA Key Gen: Fast in Test App, Slow in Real App. In-Reply-To: <6651937.post@talk.nabble.com> (spizamme@hotmail.com's message of "Wed, 4 Oct 2006 19:52:51 -0700 (PDT)") References: <6380989.post@talk.nabble.com> <200610021020.54067.bradh@frogmouth.net> <6651937.post@talk.nabble.com> Message-ID: <8764ezf7oo.fsf@wheatstone.g10code.de> On Thu, 5 Oct 2006 04:52, jitspoe said: > All I'm doing is generating a 128bit RSA key pair. I can post the source > code if you're interested. Once the first RSA key has been generated, > generating another is almost instant, so I'm guessing it's initializing some > kind of prime table. I haven't delved into the gcrypt code to find out. That is because the entropy pool of the RNG has been filled and the second key utilizes the left over entropy. Make sure to properly setup the RNG. BTW, a 128 bit RSA key is pretty useless except for learning how to break it. Salam-Shalom, Werner From spizamme at hotmail.com Fri Oct 6 21:56:39 2006 From: spizamme at hotmail.com (jitspoe) Date: Sat Oct 7 11:44:57 2006 Subject: RSA Key Gen: Fast in Test App, Slow in Real App. In-Reply-To: <8764ezf7oo.fsf@wheatstone.g10code.de> References: <6380989.post@talk.nabble.com> <200610021020.54067.bradh@frogmouth.net> <6651937.post@talk.nabble.com> <8764ezf7oo.fsf@wheatstone.g10code.de> Message-ID: <6686275.post@talk.nabble.com> Werner Koch wrote: > > That is because the entropy pool of the RNG has been filled and the > second key utilizes the left over entropy. Make sure to properly > setup the RNG. > > BTW, a 128 bit RSA key is pretty useless except for learning how to > break it. > > > Salam-Shalom, > > Werner > Thanks for the reply. I'm aware that 128bit RSA isn't very powerful, but in the way I was planning to use it, it didn't need to be. I'm just sending a single random string for verification purposes. I actually realized that RSA wasn't even necessary and just went with some simple hashing instead, but I'm still curious about the key generation time. Is there any documentation on how to set up the RNG? What do I need to call? gcry_fast_random_poll()? I couldn't find anything else that looked like an initialization function. -- View this message in context: http://www.nabble.com/RSA-Key-Gen%3A-Fast-in-Test-App%2C-Slow-in-Real-App.-tf2296684.html#a6686275 Sent from the GnuPG - Libgcrypt - Dev mailing list archive at Nabble.com. From stephen.a.cochran.lists at cahir.net Wed Oct 11 04:56:06 2006 From: stephen.a.cochran.lists at cahir.net (Stephen A. Cochran Lists) Date: Wed Oct 11 06:21:32 2006 Subject: AES decrypted text mismatch Message-ID: I was following Tobias Bayer's example code to perform some AES encryption. Code available at: http://www.tobias-bayer.de/main/tutorials/libgcrypt.html I made a simple modification to allow command line input to demonstrate the problem, changing only the following lines: int main(int argc, char *argv[]) { const int BLOCKSIZE = 16; int TEXTLEN = strlen(argv[1]); unsigned char* plaintext = argv[1]; When I run the program (using libgcrypt 1.2.0, I realize it's out of date, trying to get the sysadmin to update it), some input strings are decrypted back with extra characters on the end. Note the different length after decryption as well: angus@dev:~/aes_test>./aes 12345678901 Key is: 92 75 26 AD C8 BC 36 C7 C 52 8 E3 BF 13 8C F9 Encrypting plaintext: 12345678901... plaintext len: 11 Resulting ciphertext (hex): BA C6 2A 23 DC 39 0 D5 7E 48 CB Decrypted text len: 11 Decrypted text: 12345678901 angus@dev:~/aes_test>./aes 123456789012 Key is: FF 5 76 50 41 9F 2B A0 1B 2F 3 D2 B0 9 A8 9D Encrypting plaintext: 123456789012... plaintext len: 12 Resulting ciphertext (hex): D6 FD 6E 93 53 4B 1F 1B 4F 6 41 99 Decrypted text len: 15 Decrypted text: 123456789012? Is this a known bug in 1.2.0? I didn't see anything in the archives or the change log, but didn't really find release notes. Thanks in advance, Steve Cochran From wk at gnupg.org Wed Oct 11 11:21:58 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Oct 11 11:27:52 2006 Subject: AES decrypted text mismatch In-Reply-To: (Stephen A. Cochran Lists's message of "Tue, 10 Oct 2006 22:56:06 -0400") References: Message-ID: <87u02b2ond.fsf@wheatstone.g10code.de> On Wed, 11 Oct 2006 04:56, Stephen A. Cochran Lists said: > const int BLOCKSIZE = 16; > int TEXTLEN = strlen(argv[1]); > unsigned char* plaintext = argv[1]; > > When I run the program (using libgcrypt 1.2.0, I realize it's out of > date, trying to get the sysadmin to update it), some input strings > are decrypted back with extra characters on the end. Note the > different length after decryption as well: With only the changes above you won't be able to get that output. Thus you changed more and introduced a bug. Shalom-Salam, Werner From marcus.brinkmann at ruhr-uni-bochum.de Tue Oct 10 20:06:58 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Wed Oct 11 12:21:17 2006 Subject: socklen_t usage in gcrypt.h In-Reply-To: <20050121231449.GB75725@mail1.thewrittenword.com> References: <20050121231449.GB75725@mail1.thewrittenword.com> Message-ID: <87ac44f3jx.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Fri, 21 Jan 2005 17:14:50 -0600, Albert Chin wrote: > > gcrypt assumes socklen_t exists on the system. This is not the case > for Solaris 2.6, HP-UX 10.20, and Tru64 UNIX 4.0D. Should I modify > gcrypt.h accordingly or should callers be expected to provide a > socklen_t equivalent? I have put a fix for this in SVN rev 1180. I would be happy to hear from you if this helps, or if more is needed. See also https://bugs.g10code.com/gnupg/issue698 for more details. Thanks, Marcus From stephen.a.cochran.lists at cahir.net Wed Oct 11 15:42:11 2006 From: stephen.a.cochran.lists at cahir.net (Stephen A. Cochran Lists) Date: Wed Oct 11 15:41:50 2006 Subject: AES decrypted text mismatch In-Reply-To: <87u02b2ond.fsf@wheatstone.g10code.de> References: <87u02b2ond.fsf@wheatstone.g10code.de> Message-ID: On Oct 11, 2006, at 5:21 AM, Werner Koch wrote: > With only the changes above you won't be able to get that output. > Thus you changed more and introduced a bug. I added two printf statements that highlighted the change: printf("plaintext len: %u\n", strlen(plaintext)); printf("Decrypted text len: %u\n", strlen(decryptedtext)); I highly doubt that they are the problem. But to rule out any other change I had made, I even tested the original code and only modified the plaintext and TEXTLEN lines: const int TEXTLEN = 12; unsigned char* plaintext = "123456789012"; Again, the same output: angus@dev:~/aes_test>./aes Initializing... Version: 1.2.0 Generating symmetric key (128 bit)... Key is: 25 86 9D 2F 2D F7 23 43 1A 8A 7B B2 E6 32 95 D9 Opening AES cipher... Setting the key... Setting the initialization vector 1234567812345678... Encrypting plaintext: 123456789012... Resulting ciphertext (hex): 28 B1 A8 BC D8 BF 4C 21 76 D3 37 A Resetting initialization vector... Decrypting... Decrypted text: 123456789012? Steve From wk at gnupg.org Wed Oct 11 17:15:38 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Oct 11 17:22:34 2006 Subject: AES decrypted text mismatch In-Reply-To: <88D2D562-B6EB-4EEE-9B55-25988C93CF57@cahir.net> (Stephen A. Cochran Lists's message of "Wed, 11 Oct 2006 08:22:21 -0400") References: <87u02b2ond.fsf@wheatstone.g10code.de> <88D2D562-B6EB-4EEE-9B55-25988C93CF57@cahir.net> Message-ID: <87r6xe289x.fsf@wheatstone.g10code.de> On Wed, 11 Oct 2006 14:22, Stephen A. Cochran Lists said: > printf("plaintext len: %u\n", strlen(plaintext)); > printf("Decrypted text len: %u\n", strlen(decryptedtext)); You are using strlen for the decypted text but you didn't encypted the trailing Nul. Thus your printf as well as the strlen accesses uninitialized memory and stops output only at the next Nul byte found. This is also a bug in the original program. Salam-Shalom, Werner From mingyur at inventati.org Fri Oct 13 16:06:23 2006 From: mingyur at inventati.org (kky) Date: Fri Oct 13 16:51:29 2006 Subject: gcry_mpi_scan( ) problem .... Message-ID: <452F9D5F.8050108@inventati.org> Hi all ! i'm using the libgcrypt and i've got an error i can't go through, i don't know if you can help me and if it is the right place. I'm using the same function in an other context without problems and if i pass the same parameter of the other context i get the same error : this is the output of the debug with gdb: [...] The salt buffer is : 3216252CB911C77A49E4F311F933C176ECC7BA4C0E05CB14960EB82C9645E0B1 The length of s + id + pwd is : 48 printing the buffer: 3216252CB911C77A49E4F311F933C176ECC7BA4C0E05CB14960EB82C9645E0B16D696E677975726B6F626C656E736B79 Printing the x_digest : DDC4425FB32D87AAD3236FC7C9EC6C60842F11EDDCFA5D7C6E172D6F0457C7AF Program received signal SIGSEGV, Segmentation fault. 0xb7d148d2 in _int_malloc () from /lib/tls/libc.so.6 (gdb) bt #0 0xb7d148d2 in _int_malloc () from /lib/tls/libc.so.6 #1 0xb7d138f3 in malloc () from /lib/tls/libc.so.6 #2 0xb7f0b849 in _gcry_private_malloc (n=3084695584) at stdmem.c:78 #3 0xb7f08ba3 in _gcry_malloc (n=134915000, flags=0, mem=0x15fe0421) at global.c:409 #4 0xb7f08bd9 in gcry_malloc (n=20) at global.c:429 #5 0xb7f08ed9 in gcry_xmalloc (n=20) at global.c:562 #6 0xb7f3e5ff in _gcry_mpi_alloc (nlimbs=1) at mpiutil.c:43 #7 0xb7f3cb32 in gcry_mpi_scan (ret_mpi=0xbff481d0, format=GCRYMPI_FMT_USG, buffer_arg=0x80aaf90, buflen=32, nscanned=0x21) at mpicoder.c:383 [...] the code: int build_x(gcry_mpi_t *x,uint8_t *id,uint8_t *password,uint8_t *s) { uint8_t *buffer, *x_digest,*next; gcry_mpi_t prova; int md_size,length,len_s,len_id,len_passwd,buffer_byte,grplen,i; size_t *scanned; gcry_error_t err; len_s = 32; len_id = strlen(id); len_passwd = strlen(password); length = len_s+len_id+len_passwd; printf("\nThe salt buffer is : "); for(i=0;i<32;i++) printf("%02X",s[i] & 0xFF); printf("\n"); buffer = (uint8_t *)gcry_calloc(length+100,1); if (buffer == NULL) { printf("buffer: out of memory"); return 0; } next = mempcpy (buffer, s, len_s); next = mempcpy (next, id, len_id); mempcpy (next, password, len_passwd); printf("\nThe length of s + id + pwd is : %d\n",length); printf("\nprinting the buffer: "); for(i=0;i All, just now I'm doing some enhancements to the MPI part of libgcrypt by adding assembler modules for x86_64 (amd64). What I basically do is the same as it was done previously: taking the modules from GNU gmp, edit them to fit into libgcrypt. What was done so far (I just started with that): - create a new sub-directory "amd64" into mpi - implement two assembler modules as a start: add_n and sub_n - modify the config.links in mpi to detect the x86_64 architecture - configure / make Thus I was able to make the new libgcrypt with these new assembler modules. Before I start to do my own test cases: are there test cases for MPI around that I can use to verify the implementation? Regards, Werner From ametzler at downhill.at.eu.org Sun Oct 22 13:16:32 2006 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sun Oct 22 14:54:05 2006 Subject: [ping] Trivial patches submitted 3 months ago Message-ID: Hello, I had submitted two trivial patches to the list in July: http://lists.gnupg.org/pipermail/gcrypt-devel/2006-July/000999.html http://lists.gnupg.org/pipermail/gcrypt-devel/2006-July/001000.html Both of these are trivial, no copyright assignment is required. However svn trunk is unchanged and I have received no reaction yet. thanks, cu andreas -- The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal vision of the emperor's, and its inclusion in this work does not constitute tacit approval by the author or the publisher for any such projects, howsoever undertaken. (c) Jasper Ffforde From wk at gnupg.org Mon Oct 23 10:32:31 2006 From: wk at gnupg.org (Werner Koch) Date: Mon Oct 23 10:37:58 2006 Subject: [patch] don't use 32bit asssembly on powerpc64 In-Reply-To: <20060708155258.GA26719@downhill.aus.cc> (Andreas Metzler's message of "Sat\, 8 Jul 2006 17\:52\:58 +0200") References: <20060708155258.GA26719@downhill.aus.cc> Message-ID: <87k62rbffk.fsf@wheatstone.g10code.de> On Sat, 8 Jul 2006 17:52, Andreas Metzler said: > because first match wins a 64bit linux powerpc will use the generic > (32bit) powerpc linux stuff. Moving the second entry further up fixes > this. I did it a bit different to no tbreak it for netbsd and openbsd. Salam-Shalom, Werner From wk at gnupg.org Mon Oct 23 10:42:29 2006 From: wk at gnupg.org (Werner Koch) Date: Mon Oct 23 10:47:50 2006 Subject: [ping] Trivial patches submitted 3 months ago In-Reply-To: (Andreas Metzler's message of "Sun\, 22 Oct 2006 13\:16\:32 +0200") References: Message-ID: <87fydfbeyy.fsf@wheatstone.g10code.de> Pong. On Sun, 22 Oct 2006 13:16, Andreas Metzler said: > http://lists.gnupg.org/pipermail/gcrypt-devel/2006-July/000999.html Done. > http://lists.gnupg.org/pipermail/gcrypt-devel/2006-July/001000.html Also done. However I still don't think that this is a good style. Libgcrypt is a C library and not a C++ one. These a different languages. However we already 'extern "C"' and thus you will probably have the better argument. Shalom-Salam, Werner From wk at gnupg.org Mon Oct 23 10:47:47 2006 From: wk at gnupg.org (Werner Koch) Date: Mon Oct 23 10:52:46 2006 Subject: Starting with Assembler code for AMD64 In-Reply-To: <453B2A2C.7000504@t-online.de> (Werner Dittmann's message of "Sun\, 22 Oct 2006 10\:22\:04 +0200") References: <453B2A2C.7000504@t-online.de> Message-ID: <87bqo3beq4.fsf@wheatstone.g10code.de> On Sun, 22 Oct 2006 10:22, Werner Dittmann said: > just now I'm doing some enhancements to the MPI part of libgcrypt > by adding assembler modules for x86_64 (amd64). What I basically > do is the same as it was done previously: taking the modules > from GNU gmp, edit them to fit into libgcrypt. GREAT. > Before I start to do my own test cases: are there test cases for > MPI around that I can use to verify the implementation? There are no specific test cases. However if full tests suite works you should be fine. Of course good regressions tests specific to all MPI functions are desirable. I have not looked at gmp for a long time, eventually we should take some from there. Salam-Shalom, Werner From ametzler at downhill.at.eu.org Mon Oct 23 18:49:56 2006 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Mon Oct 23 20:24:13 2006 Subject: [ping] Trivial patches submitted 3 months ago In-Reply-To: <87fydfbeyy.fsf@wheatstone.g10code.de> References: <87fydfbeyy.fsf@wheatstone.g10code.de> Message-ID: <20061023164956.GA3788@downhill.g.la> On 2006-10-23 Werner Koch wrote: [...] > Done. [...] > Also done. [...] Thank you. cu andreas From gaofeng0703 at 126.com Sat Oct 28 05:01:32 2006 From: gaofeng0703 at 126.com (=?gb2312?B?uN+35Q==?=) Date: Sat Oct 28 10:40:56 2006 Subject: RSA Encrypt problem Message-ID: <200610281101315803818@126.com> Hi all ! i'm using the libgcrypt and i want use secret key of rsa to encrypt data. But i found all the function don't support this. How would i do? Thank you !! gaofeng From wk at gnupg.org Mon Oct 30 10:53:04 2006 From: wk at gnupg.org (Werner Koch) Date: Mon Oct 30 10:56:52 2006 Subject: RSA Encrypt problem In-Reply-To: <200610281101315803818@126.com> (gaofeng0703@126.com's message of "Sat\, 28 Oct 2006 11\:01\:32 +0800") References: <200610281101315803818@126.com> Message-ID: <87psca9lkv.fsf@wheatstone.g10code.de> On Sat, 28 Oct 2006 05:01, =B8=DF=B7=E5 said: > i'm using the libgcrypt and i want use secret key of rsa to encrypt data. > But i found all the function don't support this. With opublic key cryptography, you use the secret key to *decrypt* data. The public key is used for encryption. You might want to read a basic text book on cryptography before using Libgcrypt. For example: @Book{Fer:03:PC, author =3D "Niels Ferguson and Bruce Schneier", title =3D "Practical Cryptography", language =3D "USenglish", edition =3D "first", publisher =3D pub-WIL, address =3D pub-WIL:adr, pages =3D "xx + 410", year =3D "2003", ISBN =3D "0-471-22357-3", URL =3D "http://www.macfergus.com/pc/" } Salam-Shalom, Werner