From contato at tiago.eti.br Thu Aug 2 16:11:27 2012 From: contato at tiago.eti.br (Tiago Queiroz) Date: Thu, 02 Aug 2012 11:11:27 -0300 Subject: There is a maximum size of data to encrypt using RSA? Message-ID: <501A8A8F.8070900@tiago.eti.br> I am trying to encrypt a block of 1249 bytes with RSA, but when I use /gcry_sexp_build/ to build a s-expression to be encrypted the function return an empty s-expression. But when I use a smaller block of bytes (like 20 or 100) /gcry_sexp_build/ works well.... To build a s-expression I am using this: gcry_sexp_build(&raw_data, &errorff, "(data (flags pkcs1) (value %b))", data_size, d.data); where /d.data/ is a /unsigned char */ and /data_size/ is an integer with the number of bytes in /d.data/. Am I doing something wrong? Or Libgcrypt can not manipulate this amount of data. -- 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 -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Thu Aug 2 20:05:41 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 02 Aug 2012 20:05:41 +0200 Subject: There is a maximum size of data to encrypt using RSA? In-Reply-To: <501A8A8F.8070900@tiago.eti.br> (Tiago Queiroz's message of "Thu, 02 Aug 2012 11:11:27 -0300") References: <501A8A8F.8070900@tiago.eti.br> Message-ID: <87obmt185m.fsf@vigenere.g10code.de> On Thu, 2 Aug 2012 16:11, contato at tiago.eti.br said: > I am trying to encrypt a block of 1249 bytes with RSA, but when I use > /gcry_sexp_build/ to build a s-expression to be encrypted the function > return an empty s-expression. You can't do this unless you have a huge key (e.g. 16k bit). I suggest to read a text book on practical implementation of public key cryptography. For example @Book{Fer:03:PC, author = "Niels Ferguson and Bruce Schneier", title = "Practical Cryptography", language = "USenglish", edition = "first", publisher = pub-WIL, address = pub-WIL:adr, pages = "xx + 410", year = "2003", ISBN = "0-471-22357-3", URL = "http://www.macfergus.com/pc/" } there should also be similar courses available online. The old Schneier book @Book{Sch:96:AC, author = "Bruce Schneier", title = "Applied Cryptography", language = "USenglish", edition = "second", publisher = pub-WIL, address = pub-WIL:adr, pages = "xxiii + 758", year = "1996", ISBN = "0-471-11709-9", } gives a good overview and a still good reference is the online available HAC: @Book{Men:96:HAC, author = "Alfred J. Menezes and Paul van Oorschot and Scott Vanstone", title = "Handbook of Applied Cryptography", language = "USenglish", publisher = pub-CRC, address = pub-CRC:adr, pages = "xxvii + 780", year = "1996", ISBN = "0-8493-8523-7", keywords = "cryptograpy", } And while I am at it: Everyone in our business should have read this book: http://www.cl.cam.ac.uk/~rja14/book.html > Am I doing something wrong? Or Libgcrypt can not manipulate this amount > of data. It is one of the basic PKCS#1 checks it does. However, in general Libgcrypt does not protect you from doing entirely wrong stuff. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bradh at frogmouth.net Fri Aug 3 12:54:42 2012 From: bradh at frogmouth.net (Brad Hards) Date: Fri, 3 Aug 2012 20:54:42 +1000 Subject: There is a maximum size of data to encrypt using RSA? In-Reply-To: <501A8A8F.8070900@tiago.eti.br> References: <501A8A8F.8070900@tiago.eti.br> Message-ID: <201208032054.42612.bradh@frogmouth.net> On Friday 03 August 2012 00:11:27 Tiago Queiroz wrote: > I am trying to encrypt a block of 1249 bytes with RSA, but when I use > gcry_sexp_build to build a s-expression to be encrypted the function > return an empty s-expression. Please don't try to do very low level crypto (like this) without detailed understanding. Its very easy to make a mistake that completely destroys the security of the system and not know. A higher level implementation (e.g. PGP/GnuPG) would be a much better approach. Brad From xi.wang at gmail.com Wed Aug 15 00:54:40 2012 From: xi.wang at gmail.com (Xi Wang) Date: Tue, 14 Aug 2012 18:54:40 -0400 Subject: [PATCH v2] Replace deliberate division by zero with _gcry_divide_by_zero. In-Reply-To: <87vch9aaf5.fsf@vigenere.g10code.de> References: <9F7C44E6-F866-4804-9D25-D6F3815A2348@gmail.com> <5001E6FE.6080802@gmail.com> <87txwubv92.fsf@vigenere.g10code.de> <92AF518B-0484-4B7A-8681-084DEA95A25C@gmail.com> <87vch9aaf5.fsf@vigenere.g10code.de> Message-ID: <502AD730.1030707@gmail.com> * mpi/mpi-pow.c: Replace 1 / msize. * mpi/mpih-div.c: Replace 1 / dsize. * src/misc.c: Add _gcry_divide_by_zero. 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. This patch redirects these cases to _gcry_divide_by_zero. --- For simplicity, _gcry_divide_by_zero reuses _gcry_fatal_error to signal an error. If we really want to do an intentional division by zero, we might need to replicate most of _gcry_fatal_error in _gcry_divide_by_zero: int rc; const char *text = "divide by zero"; volatile int x = 1, y = 0, z; gpg_err_set_errno (EDOM); rc = gpg_err_code_from_errno (errno); if (fatal_error_handler && !fips_mode () ) fatal_error_handler (fatal_error_handler_value, rc, text); fips_signal_fatal_error (text); _gcry_secmem_term (); z = x / y; raise(SIGFPE); abort (); --- mpi/mpi-pow.c | 2 +- mpi/mpih-div.c | 5 ++--- src/g10lib.h | 2 ++ src/misc.c | 8 ++++++++ 4 files changed, 13 insertions(+), 4 deletions(-) diff --git a/mpi/mpi-pow.c b/mpi/mpi-pow.c index 33bbebe..891a7e6 100644 --- a/mpi/mpi-pow.c +++ b/mpi/mpi-pow.c @@ -76,7 +76,7 @@ gcry_mpi_powm (gcry_mpi_t res, ep = expo->d; if (!msize) - msize = 1 / msize; /* Provoke a signal. */ + _gcry_divide_by_zero(); if (!esize) { diff --git a/mpi/mpih-div.c b/mpi/mpih-div.c index 224b810..b33dcbf 100644 --- a/mpi/mpih-div.c +++ b/mpi/mpih-div.c @@ -212,9 +212,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; + _gcry_divide_by_zero(); + break; case 1: { diff --git a/src/g10lib.h b/src/g10lib.h index ec86c97..c580c08 100644 --- a/src/g10lib.h +++ b/src/g10lib.h @@ -101,6 +101,8 @@ void _gcry_bug (const char *file, int line); void _gcry_assert_failed (const char *expr, const char *file, int line); #endif +void _gcry_divide_by_zero (void) JNLIB_GCC_A_NR; + const char *_gcry_gettext (const char *key) GCC_ATTR_FORMAT_ARG(1); void _gcry_fatal_error(int rc, const char *text ) JNLIB_GCC_A_NR; void _gcry_log( int level, const char *fmt, ... ) JNLIB_GCC_A_PRINTF(2,3); diff --git a/src/misc.c b/src/misc.c index 17bd546..ed72ed6 100644 --- a/src/misc.c +++ b/src/misc.c @@ -19,6 +19,7 @@ */ #include +#include #include #include #include @@ -296,3 +297,10 @@ _gcry_burn_stack (int bytes) if (bytes > 0) _gcry_burn_stack (bytes); } + +void +_gcry_divide_by_zero (void) +{ + gpg_err_set_errno (EDOM); + _gcry_fatal_error (gpg_err_code_from_errno (errno), "divide by zero"); +} -- 1.7.9.5 From wk at gnupg.org Thu Aug 16 10:52:34 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 16 Aug 2012 10:52:34 +0200 Subject: [PATCH v2] Replace deliberate division by zero with _gcry_divide_by_zero. In-Reply-To: <502AD730.1030707@gmail.com> (Xi Wang's message of "Tue, 14 Aug 2012 18:54:40 -0400") References: <9F7C44E6-F866-4804-9D25-D6F3815A2348@gmail.com> <5001E6FE.6080802@gmail.com> <87txwubv92.fsf@vigenere.g10code.de> <92AF518B-0484-4B7A-8681-084DEA95A25C@gmail.com> <87vch9aaf5.fsf@vigenere.g10code.de> <502AD730.1030707@gmail.com> Message-ID: <87ipcji5gt.fsf@vigenere.g10code.de> Hi, that patch is okay. Commited as 2c54c4d to master. Do you think it it is important enough to "backport" it to 1.5 for a possible future maintenance release? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From xi.wang at gmail.com Thu Aug 16 14:36:01 2012 From: xi.wang at gmail.com (Xi Wang) Date: Thu, 16 Aug 2012 08:36:01 -0400 Subject: [PATCH v2] Replace deliberate division by zero with _gcry_divide_by_zero. In-Reply-To: <87ipcji5gt.fsf@vigenere.g10code.de> References: <9F7C44E6-F866-4804-9D25-D6F3815A2348@gmail.com> <5001E6FE.6080802@gmail.com> <87txwubv92.fsf@vigenere.g10code.de> <92AF518B-0484-4B7A-8681-084DEA95A25C@gmail.com> <87vch9aaf5.fsf@vigenere.g10code.de> <502AD730.1030707@gmail.com> <87ipcji5gt.fsf@vigenere.g10code.de> Message-ID: <3F1B01CD-DDE9-41D7-BF0F-CCCDDA0B5916@gmail.com> On Aug 16, 2012, at 4:52 AM, Werner Koch wrote: > that patch is okay. Commited as 2c54c4d to master. Do you think it it > is important enough to "backport" it to 1.5 for a possible future > maintenance release? Thanks. It would be nice to backport it since current version of clang "miscompiles" the code. BTW, the patch applies to the 1.5 branch cleanly. - xi From wk at gnupg.org Thu Aug 16 14:54:43 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 16 Aug 2012 14:54:43 +0200 Subject: [PATCH v2] Replace deliberate division by zero with _gcry_divide_by_zero. In-Reply-To: <3F1B01CD-DDE9-41D7-BF0F-CCCDDA0B5916@gmail.com> (Xi Wang's message of "Thu, 16 Aug 2012 08:36:01 -0400") References: <9F7C44E6-F866-4804-9D25-D6F3815A2348@gmail.com> <5001E6FE.6080802@gmail.com> <87txwubv92.fsf@vigenere.g10code.de> <92AF518B-0484-4B7A-8681-084DEA95A25C@gmail.com> <87vch9aaf5.fsf@vigenere.g10code.de> <502AD730.1030707@gmail.com> <87ipcji5gt.fsf@vigenere.g10code.de> <3F1B01CD-DDE9-41D7-BF0F-CCCDDA0B5916@gmail.com> Message-ID: <87txw3gfos.fsf@vigenere.g10code.de> On Thu, 16 Aug 2012 14:36, xi.wang at gmail.com said: > It would be nice to backport it since current version of clang > "miscompiles" the code. Given all the other clang bugs, I hesitate to do a release just for clang. If there is a real problem with PPC for example in Debian, I will do it, though. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rik at snel.it Sun Aug 19 12:55:37 2012 From: rik at snel.it (Rik Snel) Date: Sun, 19 Aug 2012 12:55:37 +0200 Subject: valgrind complains mpicoder.c:273 Message-ID: <20120819105537.GA18846@cube.dyndns.org> Hi list, I was analyzing a program I am writing with valgrind, and I found a small issue with libgcrypt. Line 273 of mpicoder.c says: for (p=buffer; !*p && *nbytes; p++, --*nbytes) In the case of getting a buffer with *nbytes == 0, *p will be uninitialized. I recommend switchting !*p and *nbytes, thus changing mpicoder.c:273 to for (p=byffer; *nbytes && !*p; p++, --*nbytes) Greetings, Rik. -- Nothing is ever a total loss; it can always serve as a bad example. From wk at gnupg.org Mon Aug 20 09:47:56 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 20 Aug 2012 09:47:56 +0200 Subject: valgrind complains mpicoder.c:273 In-Reply-To: <20120819105537.GA18846@cube.dyndns.org> (Rik Snel's message of "Sun, 19 Aug 2012 12:55:37 +0200") References: <20120819105537.GA18846@cube.dyndns.org> Message-ID: <87wr0uf1hv.fsf@vigenere.g10code.de> On Sun, 19 Aug 2012 12:55, rik at snel.it said: > for (p=buffer; !*p && *nbytes; p++, --*nbytes) > > In the case of getting a buffer with *nbytes == 0, *p will be > uninitialized. Sorry, I can't see that. At the top of the function we have: n = *nbytes? *nbytes:1; /* Allocate at least one byte. */ p = buffer = (force_secure || mpi_is_secure(a))? gcry_malloc_secure (n) : gcry_malloc (n); Thus there will always be a valid p[0]. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From cmouse at desteem.org Thu Aug 23 13:42:22 2012 From: cmouse at desteem.org (Aki Tuomi) Date: Thu, 23 Aug 2012 14:42:22 +0300 Subject: [PATCH v2] Replace deliberate division by zero with _gcry_divide_by_zero. Message-ID: <20120823114222.GB8664@pi.ip.fi> On Thu, Aug 16, 2012 at 02:54:43PM +0200, Werner Koch wrote: > On Thu, 16 Aug 2012 14:36, xi.wang at gmail.com said: > > > It would be nice to backport it since current version of clang > > "miscompiles" the code. > > Given all the other clang bugs, I hesitate to do a release just for > clang. If there is a real problem with PPC for example in Debian, I > will do it, though. > > > Shalom-Salam, > > Werner > Why is it so important that the division is attempted? Aki Tuomi -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From cmouse at youzen.ext.b2.fi Thu Aug 23 13:41:00 2012 From: cmouse at youzen.ext.b2.fi (Aki Tuomi) Date: Thu, 23 Aug 2012 14:41:00 +0300 Subject: [PATCH v2] Replace deliberate division by zero with _gcry_divide_by_zero. In-Reply-To: <87txw3gfos.fsf@vigenere.g10code.de> References: <9F7C44E6-F866-4804-9D25-D6F3815A2348@gmail.com> <5001E6FE.6080802@gmail.com> <87txwubv92.fsf@vigenere.g10code.de> <92AF518B-0484-4B7A-8681-084DEA95A25C@gmail.com> <87vch9aaf5.fsf@vigenere.g10code.de> <502AD730.1030707@gmail.com> <87ipcji5gt.fsf@vigenere.g10code.de> <3F1B01CD-DDE9-41D7-BF0F-CCCDDA0B5916@gmail.com> <87txw3gfos.fsf@vigenere.g10code.de> Message-ID: <20120823114100.GA8664@pi.ip.fi> On Thu, Aug 16, 2012 at 02:54:43PM +0200, Werner Koch wrote: > On Thu, 16 Aug 2012 14:36, xi.wang at gmail.com said: > > > It would be nice to backport it since current version of clang > > "miscompiles" the code. > > Given all the other clang bugs, I hesitate to do a release just for > clang. If there is a real problem with PPC for example in Debian, I > will do it, though. > > > Shalom-Salam, > > Werner > Why is it so important that the division is attempted? Aki Tuomi -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From wk at gnupg.org Thu Aug 23 21:45:43 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 23 Aug 2012 21:45:43 +0200 Subject: [PATCH v2] Replace deliberate division by zero with _gcry_divide_by_zero. In-Reply-To: <20120823114222.GB8664@pi.ip.fi> (Aki Tuomi's message of "Thu, 23 Aug 2012 14:42:22 +0300") References: <20120823114222.GB8664@pi.ip.fi> Message-ID: <877gsp8k9k.fsf@vigenere.g10code.de> On Thu, 23 Aug 2012 13:42, cmouse at desteem.org said: > Why is it so important that the division is attempted? Because I consider this the right thing to do. After all the MPIs are nothing more than a scaled up version of the CPUs ALU - and thus they should behave similar. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.