From xi.wang at gmail.com Sat Jul 14 23:39:10 2012 From: xi.wang at gmail.com (Xi Wang) Date: Sun, 15 Jul 2012 05:39:10 +0800 Subject: [PATCH] Replace deliberate division by zero with raise(SIGFPE). In-Reply-To: <9F7C44E6-F866-4804-9D25-D6F3815A2348@gmail.com> References: <9F7C44E6-F866-4804-9D25-D6F3815A2348@gmail.com> Message-ID: <5001E6FE.6080802@gmail.com> * mpi/mpi-pow.c (gcry_mpi_powm): Replace 1 / msize. * mpi/mpih-div.c (_gcry_mpih_divrem): Replace 1 / dsize. 1) Division by zero doesn't "provoke a signal" on architectures like PowerPC. 2) C compilers like clang will optimize away these divisions, even though the code tries "to make the compiler not remove" them. --- mpi/mpi-pow.c | 6 +++++- mpi/mpih-div.c | 6 +++--- 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/mpi/mpi-pow.c b/mpi/mpi-pow.c index 33bbebe..c1cd3ec 100644 --- a/mpi/mpi-pow.c +++ b/mpi/mpi-pow.c @@ -31,6 +31,7 @@ #include "mpi-internal.h" #include "longlong.h" +#include "g10lib.h" /**************** @@ -76,7 +77,10 @@ gcry_mpi_powm (gcry_mpi_t res, ep = expo->d; if (!msize) - msize = 1 / msize; /* Provoke a signal. */ + { + raise(SIGFPE); + goto leave; + } if (!esize) { diff --git a/mpi/mpih-div.c b/mpi/mpih-div.c index 224b810..dda53ad 100644 --- a/mpi/mpih-div.c +++ b/mpi/mpih-div.c @@ -30,6 +30,7 @@ #include #include "mpi-internal.h" #include "longlong.h" +#include "g10lib.h" #ifndef UMUL_TIME #define UMUL_TIME 1 @@ -212,9 +213,8 @@ _gcry_mpih_divrem( mpi_ptr_t qp, mpi_size_t qextra_limbs, switch(dsize) { case 0: - /* We are asked to divide by zero, so go ahead and do it! (To make - the compiler not remove this statement, return the value.) */ - return 1 / dsize; + raise(SIGFPE); + break; case 1: { -- 1.7.9.5 On 7/15/12 4:46 AM, Xi Wang wrote: > Hi, > > There are two occurrences of intentional division by zero in mpi. > Division by zero is undefined behavior in C, and it may not work > as intended. > > 1) Division by zero doesn't "provoke a signal" on architectures > like PowerPC. > > 2) C compilers like clang will optimize away these divisions, even > though the code tries "to make the compiler not remove" them. > > gcry_mpi_powm() at mpi/mpi-pow.c:78 > > if (!msize) > msize = 1 / msize; /* Provoke a signal. */ > > _gcry_mpih_divrem() at mpi/mpih-div.c:213 > > switch(dsize) { > case 0: > /* We are asked to divide by zero, so go ahead and do it! (To make > the compiler not remove this statement, return the value.) */ > return 1 / dsize; > > How about using something like signal(SIGFPE) instead? > > - xi > From xi.wang at gmail.com Sat Jul 14 22:46:21 2012 From: xi.wang at gmail.com (Xi Wang) Date: Sun, 15 Jul 2012 04:46:21 +0800 Subject: division by zero optimized away Message-ID: <9F7C44E6-F866-4804-9D25-D6F3815A2348@gmail.com> Hi, There are two occurrences of intentional division by zero in mpi. Division by zero is undefined behavior in C, and it may not work as intended. 1) Division by zero doesn't "provoke a signal" on architectures like PowerPC. 2) C compilers like clang will optimize away these divisions, even though the code tries "to make the compiler not remove" them. gcry_mpi_powm() at mpi/mpi-pow.c:78 if (!msize) msize = 1 / msize; /* Provoke a signal. */ _gcry_mpih_divrem() at mpi/mpih-div.c:213 switch(dsize) { case 0: /* We are asked to divide by zero, so go ahead and do it! (To make the compiler not remove this statement, return the value.) */ return 1 / dsize; How about using something like signal(SIGFPE) instead? - xi From contato at tiago.eti.br Fri Jul 20 01:59:39 2012 From: contato at tiago.eti.br (Tiago Queiroz) Date: Thu, 19 Jul 2012 20:59:39 -0300 Subject: Problem with padding and lost of data Message-ID: <50089F6B.3020703@tiago.eti.br> I am having two problems when I use libgcrypt: 1) When I use padding, it is not removed during the decryption. And I am adding the "(flags pkcs1)" to S-expression before decrypt. 2) If I do not use padding and I encrypt and decrypt a block of bytes which starts with the byte zero, I lose that first byte after decryption. I attached a program that I am using to test libgcrypt. Does anyone can help me? -- Tiago de Fran?a Queiroz Universidade Federal do ABC - UFABC Bacharelando em Ci?ncias e Tecnologia Bacharelando em Ci?ncias da Computa??o -------------- next part -------------- A non-text attachment was scrubbed... Name: post.c Type: text/x-csrc Size: 3901 bytes Desc: not available URL: From test at nit.gov.jo Sat Jul 21 04:13:31 2012 From: test at nit.gov.jo (Peter Thomson) Date: Sat, 21 Jul 2012 04:13:31 +0200 Subject: Message-ID: My name is Peter Thomson, Attorney at law. Sequel to your non response to my previous email, I am re-sending this to you again thus; A deceased client of mine, that shares the same last name as yours,who died as the result of a heart-related condition on January 28th 2009. I have contacted you to assist in distributing the money left behind by my client which is lodged in the bank. Regards, Peter Thomson From wrdntfctn10 at gmail.com Sat Jul 21 12:59:22 2012 From: wrdntfctn10 at gmail.com (Mr.Edward Dukaleni) Date: Sat, 21 Jul 2012 03:59:22 -0700 (PDT) Subject: PLEASE URGENT REPLY Message-ID: <1342868362.68634.YahooMailClassic@web5703.biz.mail.ne1.yahoo.com> Please Kindly open the attached file.Thanks,Mr.Edward Dukaleni -------------- next part -------------- A non-text attachment was scrubbed... Name: URGENT.doc Type: application/msword Size: 23552 bytes Desc: not available URL: From wk at gnupg.org Sun Jul 22 18:19:39 2012 From: wk at gnupg.org (Werner Koch) Date: Sun, 22 Jul 2012 18:19:39 +0200 Subject: Problem with padding and lost of data In-Reply-To: <50089F6B.3020703@tiago.eti.br> (Tiago Queiroz's message of "Thu, 19 Jul 2012 20:59:39 -0300") References: <50089F6B.3020703@tiago.eti.br> Message-ID: <87liibix9g.fsf@vigenere.g10code.de> On Fri, 20 Jul 2012 01:59, contato at tiago.eti.br said: > 1) When I use padding, it is not removed during the decryption. And I am > adding the "(flags pkcs1)" to S-expression before decrypt. IIRC, the decryption feature has only been available since 1.5.0. Do you use this version? Older version allow to pass the flag but dod not implement decryption. > 2) If I do not use padding and I encrypt and decrypt a block of bytes > which starts with the byte zero, I lose that first byte after decryption. Never ever use RSA without padding. Thus this is not relevant. The zero is missing because the raw data is treated as a number and leading zeroes are removed. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Jul 26 13:46:17 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 26 Jul 2012 13:46:17 +0200 Subject: [PATCH] Replace deliberate division by zero with raise(SIGFPE). In-Reply-To: <5001E6FE.6080802@gmail.com> (Xi Wang's message of "Sun, 15 Jul 2012 05:39:10 +0800") References: <9F7C44E6-F866-4804-9D25-D6F3815A2348@gmail.com> <5001E6FE.6080802@gmail.com> Message-ID: <87txwubv92.fsf@vigenere.g10code.de> On Sat, 14 Jul 2012 23:39, xi.wang at gmail.com said: > 1) Division by zero doesn't "provoke a signal" on architectures > like PowerPC. The code dates back to 1997. I checked what GMP tehse days does and this is what we should do in libgcrypt too: 1. Call a function to handle case. 2. Do a divide by zero in this function. 3. If we are still alive abort or rais a signal. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From xi.wang at gmail.com Fri Jul 27 01:13:47 2012 From: xi.wang at gmail.com (Xi Wang) Date: Fri, 27 Jul 2012 07:13:47 +0800 Subject: [PATCH] Replace deliberate division by zero with raise(SIGFPE). In-Reply-To: <87txwubv92.fsf@vigenere.g10code.de> References: <9F7C44E6-F866-4804-9D25-D6F3815A2348@gmail.com> <5001E6FE.6080802@gmail.com> <87txwubv92.fsf@vigenere.g10code.de> Message-ID: <92AF518B-0484-4B7A-8681-084DEA95A25C@gmail.com> On Jul 26, 2012, at 7:46 PM, Werner Koch wrote: > On Sat, 14 Jul 2012 23:39, xi.wang at gmail.com said: > >> 1) Division by zero doesn't "provoke a signal" on architectures >> like PowerPC. > > The code dates back to 1997. I checked what GMP tehse days does and > this is what we should do in libgcrypt too: > > 1. Call a function to handle case. > 2. Do a divide by zero in this function. > 3. If we are still alive abort or rais a signal. Yeah I can make a separate function to handle the case. JOOC, why still a division by zero in addition to raise? - xi From wk at gnupg.org Fri Jul 27 10:13:50 2012 From: wk at gnupg.org (Werner Koch) Date: Fri, 27 Jul 2012 10:13:50 +0200 Subject: [PATCH] Replace deliberate division by zero with raise(SIGFPE). In-Reply-To: <92AF518B-0484-4B7A-8681-084DEA95A25C@gmail.com> (Xi Wang's message of "Fri, 27 Jul 2012 07:13:47 +0800") References: <9F7C44E6-F866-4804-9D25-D6F3815A2348@gmail.com> <5001E6FE.6080802@gmail.com> <87txwubv92.fsf@vigenere.g10code.de> <92AF518B-0484-4B7A-8681-084DEA95A25C@gmail.com> Message-ID: <87vch9aaf5.fsf@vigenere.g10code.de> On Fri, 27 Jul 2012 01:13, xi.wang at gmail.com said: > Yeah I can make a separate function to handle the case. This needs also to be integrated with the FIPS code. > JOOC, why still a division by zero in addition to raise? Because that is what it is about. We are merely computing with a higher precision and thus we should behave similar to what operations on native data sizes do. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.