From etiquettesg at gmail.com Wed Jun 1 01:56:00 2011 From: etiquettesg at gmail.com (Foo Lum) Date: Wed, 1 Jun 2011 09:26:00 +0930 Subject: Using output from gpg --list-packets on a key to get the mpi values to generate s-expressions Message-ID: Hey guys, I am trying to use gpg generated public keys to do encryption using libgcrypt. I used the list packets command on the key to get me the contents of the key and parsed the mpi values into an s-expression. So when I try to encode my session key with my public key I get the error "Odd hexadecimal numbers in S-expression"? I think list packets is maybe giving me hex numbers without the leading zero? If so what do I need to do to get me mpi values that I can use in libgcrypt? Thanks in advance, Foo -------------- next part -------------- An HTML attachment was scrubbed... URL: From etiquettesg at gmail.com Wed Jun 1 07:41:41 2011 From: etiquettesg at gmail.com (Foo Lum) Date: Wed, 1 Jun 2011 15:11:41 +0930 Subject: Using output from gpg --list-packets on a key to get the mpi values to generate s-expressions In-Reply-To: References: Message-ID: I think I figured out why it wasn't working.. I think the output from gpg is chopping off all leading zeros of all mpi values, after checking for odd hexadecimal numbers and padding negative numbers with zero's it seemed to encrypt/decrypt/sign/verify fine. The secondary question I have is: What is the largest positive value that a mpi can be when represented in hex? is it 0x7F? Thanks in advance again, Foo On Wed, Jun 1, 2011 at 9:26 AM, Foo Lum wrote: > Hey guys, > I am trying to use gpg generated public keys to do encryption using > libgcrypt. I used the list packets command on the key to get me the contents > of the key and parsed the mpi values into an s-expression. So when I try to > encode my session key with my public key I get the error "Odd hexadecimal > numbers in S-expression"? I think list packets is maybe giving me hex > numbers without the leading zero? If so what do I need to do to get me mpi > values that I can use in libgcrypt? > > Thanks in advance, > Foo > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Wed Jun 1 10:17:43 2011 From: wk at gnupg.org (Werner Koch) Date: Wed, 01 Jun 2011 10:17:43 +0200 Subject: Using output from gpg --list-packets on a key to get the mpi values to generate s-expressions In-Reply-To: (Foo Lum's message of "Wed, 1 Jun 2011 09:26:00 +0930") References: Message-ID: <87pqmyynh4.fsf@vigenere.g10code.de> On Wed, 1 Jun 2011 01:56, etiquettesg at gmail.com said: > I am trying to use gpg generated public keys to do encryption using > libgcrypt. I used the list packets command on the key to get me the contents > of the key and parsed the mpi values into an s-expression. So when I try to That is not the right way. --list-packets is a debug command and subject to change at any time. A better way to get the public keys in raw format is to use gpg --list0-keys --with-key-data --with-colons KEYID This gives you something like uid:f::::1999-03-08::58201FB65551FF[...]81C124::Alice (demo key): sub:f:1024:16:6AE6D7EE46A871F8:1999-03-08::::::e: pkd:0:1024:9C8DD71F57F4BB237D7D99F0EF6C[...]EDB2337: pkd:1:3:7: pkd:2:1021:19E5E632B1A2E70303DEA90F6F36[...]8E1DA90F: The uid record gives you the algorithm (16 := Elgamal) and the following pkd records return the key parameters. Some gpg2 versions support an experimental export option gpg2 --export-options export-sexp-format --export KEYID which returns an S-expression with the key data. However it is experimental. > numbers in S-expression"? I think list packets is maybe giving me hex > numbers without the leading zero? If so what do I need to do to get me mpi Quite possible. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From etiquettesg at gmail.com Thu Jun 2 08:11:56 2011 From: etiquettesg at gmail.com (Foo Lum) Date: Thu, 2 Jun 2011 15:41:56 +0930 Subject: Using output from gpg --list-packets on a key to get the mpi values to generate s-expressions In-Reply-To: <87pqmyynh4.fsf@vigenere.g10code.de> References: <87pqmyynh4.fsf@vigenere.g10code.de> Message-ID: Thanks for the reply. Is there a way to list the mpi values for the secret key like the public keys? When I try to the --with-key-data argument on --list-secret-keys and I don't get the mpi values. Thanks On Wed, Jun 1, 2011 at 5:47 PM, Werner Koch wrote: > On Wed, 1 Jun 2011 01:56, etiquettesg at gmail.com said: > > > I am trying to use gpg generated public keys to do encryption using > > libgcrypt. I used the list packets command on the key to get me the > contents > > of the key and parsed the mpi values into an s-expression. So when I try > to > > That is not the right way. --list-packets is a debug command and > subject to change at any time. > > A better way to get the public keys in raw format is to use > > gpg --list0-keys --with-key-data --with-colons KEYID > > This gives you something like > > uid:f::::1999-03-08::58201FB65551FF[...]81C124::Alice (demo key): > sub:f:1024:16:6AE6D7EE46A871F8:1999-03-08::::::e: > pkd:0:1024:9C8DD71F57F4BB237D7D99F0EF6C[...]EDB2337: > pkd:1:3:7: > pkd:2:1021:19E5E632B1A2E70303DEA90F6F36[...]8E1DA90F: > > The uid record gives you the algorithm (16 := Elgamal) and the following > pkd records return the key parameters. > > Some gpg2 versions support an experimental export option > > gpg2 --export-options export-sexp-format --export KEYID > > which returns an S-expression with the key data. However it is > experimental. > > > numbers in S-expression"? I think list packets is maybe giving me hex > > numbers without the leading zero? If so what do I need to do to get me > mpi > > Quite possible. > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at ritter.vg Thu Jun 2 19:21:11 2011 From: tom at ritter.vg (Tom Ritter) Date: Thu, 2 Jun 2011 13:21:11 -0400 Subject: Timing Attack against RSA OAEP Code Message-ID: I'm not sure if libgcrypt has a policy of attempting to prevent timing attacks, but I noticed one in the new RSA OAEP code and developed a proof of concept. On the latest revision of pubkey.c[1] line 1180 is an if statement that will exit decoding early if the high byte is non-zero. This allows arbitrary decryption of plaintext[2] *depending on the application using the library*. I created a simple application doing RSA OAEP and was able to detect the timing difference locally to decrypt the ciphertext. The code is published on github [3] showing the attack with background [4], and how to demonstrate the timing difference. The full code to exploit the timing difference is not included - partly because I'm embarrassed by my statistical code, and partly because I'm not aware of any public timing attack libraries and have no desire to be the first. The patch for this would be to do something similar to OpenSSL [5] - where the entire decoding process is run through regardless of the high-byte error, but a flag is set and the error returned at the end of the function. Since this code is trunk and not a versioned release, I don't consider there any risk of releasing this information prior to informing the list - if you want to debate disclosure, please contact me personally. -tom [1] http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=blob;f=cipher/pubkey.c;h=0d8b082197d3b4e5f36bce4212211db3a4af1b85;hb=c228af82b3485ff9de2b76b66acb5305aa1a5019 [2] A Chosen Ciphertext Attack on RSA Optimal Asymmetric Encryption Padding (OAEP) as Standardized in PKCS #1 v2.0 http://portal.acm.org/citation.cfm?id=704143 [3] https://github.com/GDSSecurity/mangers-oracle [4] http://www.gdssecurity.com/l/b/2011/06/02/mangers-oracle/ [5] openssl-1.0.0d/crypto/rsa/rsa_oaep.c Search for 'Manger' From ueno at unixuser.org Fri Jun 3 03:36:34 2011 From: ueno at unixuser.org (Daiki Ueno) Date: Fri, 03 Jun 2011 10:36:34 +0900 Subject: Timing Attack against RSA OAEP Code In-Reply-To: (Tom Ritter's message of "Thu, 2 Jun 2011 13:21:11 -0400") References: Message-ID: Tom Ritter writes: > I'm not sure if libgcrypt has a policy of attempting to prevent timing > attacks, but I noticed one in the new RSA OAEP code and developed a > proof of concept. On the latest revision of pubkey.c[1] line 1180 is > an if statement that will exit decoding early if the high byte is > non-zero. Thanks for the analysis. I should have read RFC3447 more carefully. > The patch for this would be to do something similar to OpenSSL [5] - > where the entire decoding process is run through regardless of the > high-byte error, but a flag is set and the error returned at the end > of the function. I'm attaching a fix in this direction. Also, probably oaep_decode should never return "inspectable" error codes like GPG_ERR_TOO_SHORT on non-fatal errors. > Since this code is trunk and not a versioned release, I don't consider > there any risk of releasing this information prior to informing the > list - if you want to debate disclosure, please contact me personally. Thanks for noticing this before the release. Regards, -- Daiki Ueno -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Prevent-OAEP-timing-attack.patch Type: text/x-patch Size: 5046 bytes Desc: not available URL: From wk at gnupg.org Fri Jun 3 09:25:21 2011 From: wk at gnupg.org (Werner Koch) Date: Fri, 03 Jun 2011 09:25:21 +0200 Subject: Timing Attack against RSA OAEP Code In-Reply-To: (Daiki Ueno's message of "Fri, 03 Jun 2011 10:36:34 +0900") References: Message-ID: <8739jrz89q.fsf@vigenere.g10code.de> On Fri, 3 Jun 2011 03:36, ueno at unixuser.org said: > I'm attaching a fix in this direction. Also, probably oaep_decode > should never return "inspectable" error codes like GPG_ERR_TOO_SHORT on > non-fatal errors. FWIW, I did some restructuring of the oaep_encode stuff to better match the RFC. I planned for today to do the same for oaep_decode. Thus you may want to wait before applying the patch. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Jun 3 09:51:19 2011 From: wk at gnupg.org (Werner Koch) Date: Fri, 03 Jun 2011 09:51:19 +0200 Subject: Using output from gpg --list-packets on a key to get the mpi values to generate s-expressions In-Reply-To: (Foo Lum's message of "Thu, 2 Jun 2011 15:41:56 +0930") References: <87pqmyynh4.fsf@vigenere.g10code.de> Message-ID: <87fwnrxsi0.fsf@vigenere.g10code.de> On Thu, 2 Jun 2011 08:11, etiquettesg at gmail.com said: > Thanks for the reply. Is there a way to list the mpi values for the secret > key like the public keys? When I try to the --with-key-data argument on > --list-secret-keys and I don't get the mpi values. Sorry, no. You may however want to try out GnuPG 2.1 (git master). This version requires the migration of the secring.gpg to the gpg-agent. See the README for details. The gpg-agent now stores each key in a single file as an S-expression. When asked to enter the passphrase you should give an empty one of course. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Jun 9 09:23:33 2011 From: wk at gnupg.org (Werner Koch) Date: Thu, 09 Jun 2011 09:23:33 +0200 Subject: PSS code question Message-ID: <87d3inv56y.fsf@vigenere.g10code.de> Hi, I reworked the PSS code in the uene-pss branch and merged it with master. I did this similar to my changes for OAEP to help reading and comparing the code to the the specs. I see one problem with it. According to rfc-3447 we are doing this +-----------+ | M | +-----------+ | V Hash | V +--------+----------+----------+ M' = |Padding1| mHash | salt | +--------+----------+----------+ [....] Out input is the actual message; for example: { "(data\n (flags pss)\n" " (hash sha1 #11223344556677889900AABBCCDDEEFF10203040#))\n", However we don't consider #1122...# a hash value but the actual message to be signed. If we really want to do this it would be better to use a new construct than this "(hash ALGO DIGEST)" pattern. However I dount that it is a good idea. We have always used gcry_pk_sign in the way that the caller passed the hash of the message (here mHash) to it and not the entire message. Many applications have large messages and it should be possigble to stream them. Having said this, I'd propose to change the semantics and require that mHash is passed to gcry_pk_sign and gcry_pk_verify if PSS is used. rfc-3447 actually allows this: 3. Without compromising the security proof for RSASSA-PSS, one may perform steps 1 and 2 of EMSA-PSS-ENCODE and EMSA-PSS-VERIFY (the application of the hash function to the message) outside the module that computes the rest of the signature operation, so that mHash rather than the message M itself is input to the module. In [...] Shall I do these changes? I'd also like to see a way to test at least the verification of a PSS message against a known test vector. Are there any real world application of PSS or even test vectors? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From simon at josefsson.org Thu Jun 9 09:50:36 2011 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 09 Jun 2011 09:50:36 +0200 Subject: PSS code question In-Reply-To: <87d3inv56y.fsf@vigenere.g10code.de> (Werner Koch's message of "Thu, 09 Jun 2011 09:23:33 +0200") References: <87d3inv56y.fsf@vigenere.g10code.de> Message-ID: <8762of1m0j.fsf@latte.josefsson.org> Werner Koch writes: > I'd also like to see a way to test at least the verification of a PSS > message against a known test vector. Are there any real world > application of PSS or even test vectors? Test vectors: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1d2-vec.zip As for real world applications, I dunno. /Simon From ueno at unixuser.org Thu Jun 9 10:40:04 2011 From: ueno at unixuser.org (Daiki Ueno) Date: Thu, 09 Jun 2011 17:40:04 +0900 Subject: PSS code question In-Reply-To: <87d3inv56y.fsf@vigenere.g10code.de> (Werner Koch's message of "Thu, 09 Jun 2011 09:23:33 +0200") References: <87d3inv56y.fsf@vigenere.g10code.de> Message-ID: Werner Koch writes: > Having said this, I'd propose to change the semantics and require that > mHash is passed to gcry_pk_sign and gcry_pk_verify if PSS is used. > rfc-3447 actually allows this: > > 3. Without compromising the security proof for RSASSA-PSS, one may > perform steps 1 and 2 of EMSA-PSS-ENCODE and EMSA-PSS-VERIFY (the > application of the hash function to the message) outside the > module that computes the rest of the signature operation, so that > mHash rather than the message M itself is input to the module. In > [...] > > Shall I do these changes? Certainly - thanks for pointing out this. > I'd also like to see a way to test at least the verification of a PSS > message against a known test vector. Are there any real world > application of PSS or even test vectors? I used the test vectors Simon mentioned, manually comparing the step results with pss-int.txt. Maybe good to have selftests using the test vector, though I guess it is not that easy since both PSS and OAEP use random bits during the computation. Regards, -- Daiki Ueno From simon at josefsson.org Thu Jun 9 11:08:08 2011 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 09 Jun 2011 11:08:08 +0200 Subject: PSS code question In-Reply-To: (Daiki Ueno's message of "Thu, 09 Jun 2011 17:40:04 +0900") References: <87d3inv56y.fsf@vigenere.g10code.de> Message-ID: <87pqmnz81z.fsf@latte.josefsson.org> Daiki Ueno writes: >> I'd also like to see a way to test at least the verification of a PSS >> message against a known test vector. Are there any real world >> application of PSS or even test vectors? > > I used the test vectors Simon mentioned, manually comparing the step > results with pss-int.txt. Maybe good to have selftests using the test > vector, though I guess it is not that easy since both PSS and OAEP use > random bits during the computation. Would it be possible to specify the random bits to use to gcry_pk_sign in the sexp somehow? Is it a fixed size random buffer? It would be useful for self testing. /Simon From wk at gnupg.org Thu Jun 9 11:20:35 2011 From: wk at gnupg.org (Werner Koch) Date: Thu, 09 Jun 2011 11:20:35 +0200 Subject: PSS code question In-Reply-To: <87pqmnz81z.fsf@latte.josefsson.org> (Simon Josefsson's message of "Thu, 09 Jun 2011 11:08:08 +0200") References: <87d3inv56y.fsf@vigenere.g10code.de> <87pqmnz81z.fsf@latte.josefsson.org> Message-ID: <878vtbuzrw.fsf@vigenere.g10code.de> On Thu, 9 Jun 2011 11:08, simon at josefsson.org said: > Would it be possible to specify the random bits to use to gcry_pk_sign > in the sexp somehow? Is it a fixed size random buffer? It would be Yes. We did something similar for DSS, iirc. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Jun 9 15:01:02 2011 From: wk at gnupg.org (Werner Koch) Date: Thu, 09 Jun 2011 15:01:02 +0200 Subject: PSS code question In-Reply-To: (Daiki Ueno's message of "Thu, 09 Jun 2011 17:40:04 +0900") References: <87d3inv56y.fsf@vigenere.g10code.de> Message-ID: <87y61btb01.fsf@vigenere.g10code.de> Hi, Is there a reason why you use (ctx->nbits - 1) when passing the size of the key to the OAEP and PSS functions? The functions round them to full bytes anyway but there at least in PSS some leading bits are cleared depending on the number of bits (i.e. if not a multiple of 8). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ueno at unixuser.org Thu Jun 9 15:23:13 2011 From: ueno at unixuser.org (Daiki Ueno) Date: Thu, 09 Jun 2011 22:23:13 +0900 Subject: PSS code question In-Reply-To: <87y61btb01.fsf@vigenere.g10code.de> (Werner Koch's message of "Thu, 09 Jun 2011 15:01:02 +0200") References: <87d3inv56y.fsf@vigenere.g10code.de> <87y61btb01.fsf@vigenere.g10code.de> Message-ID: <874o3zcf5p.fsf-ueno@unixuser.org> Werner Koch writes: > Is there a reason why you use (ctx->nbits - 1) when passing the size of > the key to the OAEP and PSS functions? The functions round them to full > bytes anyway but there at least in PSS some leading bits are cleared > depending on the number of bits (i.e. if not a multiple of 8). For PSS, that is defined in RFC3447 8.1.1: EM = EMSA-PSS-ENCODE (M, modBits - 1). Note that the octet length of EM will be one less than k if modBits - 1 is divisible by 8 and equal to k otherwise. IIUC, this is necessary to make sure EM is smaller than RSA modulus n. Regards, -- Daiki Ueno From wk at gnupg.org Thu Jun 9 15:43:28 2011 From: wk at gnupg.org (Werner Koch) Date: Thu, 09 Jun 2011 15:43:28 +0200 Subject: PSS code question In-Reply-To: <874o3zcf5p.fsf-ueno@unixuser.org> (Daiki Ueno's message of "Thu, 09 Jun 2011 22:23:13 +0900") References: <87d3inv56y.fsf@vigenere.g10code.de> <87y61btb01.fsf@vigenere.g10code.de> <874o3zcf5p.fsf-ueno@unixuser.org> Message-ID: <87tybzt91b.fsf@vigenere.g10code.de> On Thu, 9 Jun 2011 15:23, ueno at unixuser.org said: > For PSS, that is defined in RFC3447 8.1.1: Oops, I missed that. I add a note. I am currently hacking the test vectors. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Jun 9 18:59:14 2011 From: wk at gnupg.org (Werner Koch) Date: Thu, 09 Jun 2011 18:59:14 +0200 Subject: PSS code question In-Reply-To: <87tybzt91b.fsf@vigenere.g10code.de> (Werner Koch's message of "Thu, 09 Jun 2011 15:43:28 +0200") References: <87d3inv56y.fsf@vigenere.g10code.de> <87y61btb01.fsf@vigenere.g10code.de> <874o3zcf5p.fsf-ueno@unixuser.org> <87tybzt91b.fsf@vigenere.g10code.de> Message-ID: <87pqmnszz1.fsf@vigenere.g10code.de> On Thu, 9 Jun 2011 15:43, wk at gnupg.org said: > I am currently hacking the test vectors. OAEP test vectors done. It was useful: A bug turned out. It is the usual thing with leading zero bytes. This is due to our use of integers for conveying some of the parameters. I need to see how they can be fixed. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From mailjohnmorris at gmail.com Thu Jun 9 23:24:31 2011 From: mailjohnmorris at gmail.com (John Morris) Date: Thu, 9 Jun 2011 16:24:31 -0500 Subject: MD5WithRSA digital signatures Message-ID: Hi, I'm trying to verify digital signatures generated in libgcrypt in a java app using "MD5WithRSA" type signatures. I think perhaps I am creating the signature incorrectly in libgcrypt, but I am not sure what to do to produce one that can be used by the java Signature class. Here is how I am verifying in java: Signature sig = Signature.getInstance("MD5WithRSA"); sig.initVerify(pubKey); sig.update(data); boolean result = sig.verify(signature); The above works for signatures I created with the java Signature class, but not those I created in my C app with libgcrypt. Here is my libgcrypt code for creating the signature: char md5[16]; gcry_md_hash_buffer(GCRY_MD_MD5, md5, data, dataLen); rc = gcry_sexp_build(&data_sexp, NULL, "(data(flags pkcs1)(hash md5 %b))", (size_t)16, md5); rc = gcry_pk_sign(&signature, data_sexp, privKey); I am able to verify the libgcrypt signatures with libgcrypt itself, so I am pretty sure I am just specifying some option wrong when creating the signature, or I am misunderstanding how to include the md5 using libgcrypt in a way that is compatible with the java Signature class. Does anyone know how I can create signatures that are compatible with the Signature class in the standard java libraries? Thanks, John -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Fri Jun 10 09:02:46 2011 From: wk at gnupg.org (Werner Koch) Date: Fri, 10 Jun 2011 09:02:46 +0200 Subject: MD5WithRSA digital signatures In-Reply-To: (John Morris's message of "Thu, 9 Jun 2011 16:24:31 -0500") References: Message-ID: <878vtatbhl.fsf@vigenere.g10code.de> On Thu, 9 Jun 2011 23:24, mailjohnmorris at gmail.com said: > Signature sig = Signature.getInstance("MD5WithRSA"); I don't know what scheme this is. Is it pkcs#1 (v1.5 or PSS)? > gcry_md_hash_buffer(GCRY_MD_MD5, md5, data, dataLen); > rc = gcry_sexp_build(&data_sexp, NULL, "(data(flags pkcs1)(hash md5 %b))", > (size_t)16, md5); *You need to cast to (int)!* On 32 bit system this usually doesn't matter but on most 64 bit systems you would corrupt your stack. Except for this it looks okay. BTW, using MD5 for any new code is a serious problem; even all old code should have been changed to to use at least SHA-1. MD5 is broken. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Jun 10 11:05:23 2011 From: wk at gnupg.org (Werner Koch) Date: Fri, 10 Jun 2011 11:05:23 +0200 Subject: PSS scheme now in master Message-ID: <874o3yt5t8.fsf@vigenere.g10code.de> Hi! I fixed the leading zero problems in the OAEP and PSS code and merged ueno-pss into master. All the pkcs#1v2 tests do run fine. If you want to see them run "./pkcs1v2 --verbose". Now with the latest changes, I also consider to fix pkcs#1 v1.5 padding: The current code may remove leading zeroes in some cases and all applications have the need to cope with that. There is a little risk that a change might break some applications but overall I think it is better to do the padding properly; i.e. make sure to return leading zeroes. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From mailjohnmorris at gmail.com Fri Jun 10 19:15:51 2011 From: mailjohnmorris at gmail.com (John Morris) Date: Fri, 10 Jun 2011 12:15:51 -0500 Subject: MD5WithRSA digital signatures In-Reply-To: <878vtatbhl.fsf@vigenere.g10code.de> References: <878vtatbhl.fsf@vigenere.g10code.de> Message-ID: On Fri, Jun 10, 2011 at 2:02 AM, Werner Koch wrote: > On Thu, 9 Jun 2011 23:24, mailjohnmorris at gmail.com said: > > > Signature sig = Signature.getInstance("MD5WithRSA"); > > I don't know what scheme this is. Is it pkcs#1 (v1.5 or PSS)? > It is using pkcs#1 v1.5. > > > gcry_md_hash_buffer(GCRY_MD_MD5, md5, data, dataLen); > > rc = gcry_sexp_build(&data_sexp, NULL, "(data(flags pkcs1)(hash md5 > %b))", > > (size_t)16, md5); > > *You need to cast to (int)!* On 32 bit system this usually doesn't > matter but on most 64 bit systems you would corrupt your stack. > Thanks for the tip. I was following an example I found that was doing this. I'll change it to int. > > Except for this it looks okay. > > BTW, using MD5 for any new code is a serious problem; even all old code > should have been changed to to use at least SHA-1. MD5 is broken. > > I know, and I am planning to switch soon, but we still have some legacy users that expect it in md5 > Shalom-Salam, > > Werner > > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > I actually found the problem. I was doing something stupid in my java code (verifying with wrong signature variable .. doh!). It seems to be working fine now. Thanks for your reply. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Mon Jun 13 14:12:14 2011 From: wk at gnupg.org (Werner Koch) Date: Mon, 13 Jun 2011 14:12:14 +0200 Subject: MD5WithRSA digital signatures In-Reply-To: (John Morris's message of "Fri, 10 Jun 2011 12:15:51 -0500") References: <878vtatbhl.fsf@vigenere.g10code.de> Message-ID: <87oc22rkv5.fsf@vigenere.g10code.de> On Fri, 10 Jun 2011 19:15, mailjohnmorris at gmail.com said: > It seems to be working fine now. Good to hear. Nevertheless I meanwhile implemented a full test suite for pkcs#1 v1.5 and fixed a few bugs in our code (the usual leading zero thing). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Jun 29 12:18:34 2011 From: wk at gnupg.org (Werner Koch) Date: Wed, 29 Jun 2011 12:18:34 +0200 Subject: Libgcrypt 1.5.0 released Message-ID: <874o39hret.fsf@vigenere.g10code.de> Hello! The GNU project is pleased to announce the availability of Libgcrypt version 1.5.0. This is the new stable version of Libgcrypt and upward compatible with the 1.4 series. The 1.4 series will enter end of life state on 2012-12-31. 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 between version 1.4.6 and 1.5.0: * New function gcry_kdf_derive implementing OpenPGP S2K algorithms and PBKDF2. * Support for WindowsCE. * Support for ECDH. * Support for OAEP and PSS methods as described by RFC-3447. * Fixed PKCS v1.5 code to always return the leading zero. * New format specifiers "%M" and "%u" for gcry_sexp_build. * Support opaque MPIs with "%m" and "%M" in gcry_sexp_build. * New functions gcry_pk_get_curve and gcry_pk_get_param to map ECC parameters to a curve name and to retrieve parameter values. * gcry_mpi_cmp applied to opaque values has a defined semantic now. * Uses the Intel AES-NI instructions if available. * The use of the deprecated Alternative Public Key Interface (gcry_ac_*) will now print compile time warnings. * *The module register subsystem has been deprecated.* This subsystem is not flexible enough and would always require ABI changes to extend the internal interfaces. It will eventually be removed. Please contact us on the gcrypt-devel mailing list to discuss whether you really need this feature or how it can be replaced by an internal plugin mechanism. * CTR mode may now be used with data chunks of arbitrary length. * Interface changes relative to the 1.4.6 release: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ GCRY_PK_ECDH NEW. gcry_pk_get_curve NEW. gcry_pk_get_param NEW. GCRYCTL_DISABLE_HWF NEW. gcry_kdf_derive NEW. gcry_pk_encrypt EXTENDED: Support OAEP. gcry_pk_decrypt EXTENDED: Support OAEP. gcry_pk_sign EXTENDED: Support PSS. gcry_pk_verify EXTENDED: Support PSS. gcry_sexp_build EXTENDED: Add format specifiers M and u. 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.5.0.tar.bz2 (1400k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.0.tar.bz2.sig This file is bzip2 compressed. A gzip compressed version is also available: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.0.tar.gz (1698k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.0.tar.gz.sig Due to a lot of changes regarding white spaces we don't provide a patch file against 1.4.6. The SHA-1 checksums are: e6508315b76eaf3d0df453f67371b106654bd4fe libgcrypt-1.5.0.tar.gz 3e776d44375dc1a710560b98ae8437d5da6e32cf libgcrypt-1.5.0.tar.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 . [2] Note that copyright assignments to the FSF are required. [3] For example see . [4] See the service directory at . -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 207 bytes Desc: not available URL: From wk at gnupg.org Wed Jun 29 15:36:02 2011 From: wk at gnupg.org (Werner Koch) Date: Wed, 29 Jun 2011 15:36:02 +0200 Subject: Error using GPG2 in FIPS mode In-Reply-To: <4E0B0281.5080006@gmail.com> (Arian Sameni's message of "Wed, 29 Jun 2011 12:46:25 +0200") References: <4E0B0281.5080006@gmail.com> Message-ID: <87r56chi9p.fsf@vigenere.g10code.de> Hi! I looked again at it and there is indeed a bug lingering in Libgcrypt. What a pitty that I released 1.5.0 a few hours ago. Please find attach a patch against libgcrypt which should fix it. Well, not really ... at least it bails out in GnuPG and not in Libgcrypt which is more or less fine. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fixed-a-bug-in-the-gcry_cipher_get_algo_keylen-and-g.patch Type: text/x-patch Size: 5961 bytes Desc: not available URL: From dclarke at blastwave.org Wed Jun 29 15:55:17 2011 From: dclarke at blastwave.org (Dennis Clarke) Date: Wed, 29 Jun 2011 09:55:17 -0400 (EDT) Subject: Error using GPG2 in FIPS mode Message-ID: <57044.10.0.66.17.1309355717.squirrel@interact.purplecow.org> > Hi! > > I looked again at it and there is indeed a bug lingering in Libgcrypt. > What a pitty that I released 1.5.0 a few hours ago. > > Please find attach a patch against libgcrypt which should fix it. Well, > not really ... at least it bails out in GnuPG and not in Libgcrypt which > is more or less fine. > > wow .. that was fast ! -- -- +-------------------------+---------------------------------+ | Dennis