From dbaryshkov at gmail.com Sat Feb 1 18:06:17 2014 From: dbaryshkov at gmail.com (Dmitry Eremin-Solenikov) Date: Sat, 1 Feb 2014 21:06:17 +0400 Subject: "Fixing" private key/generating public key from incomplete private Message-ID: Hello, I'm looking for a way to 'fixup' the private key. For example. I load the DSA key from PKCS#8 keyfile. It contains (in terms of gcrypt s-exp) domain parameters (p, q, g), secret exponent (x) but no public exponent (y). I found gcrypt_pubkey_get_sexp, but it (currently) only works for ECC. It there a good way to solve my problem? I was thinking about adding an special mode to gcry_pk_genkey or about adding a special API resembling gcrypt_pubkey_get_sexp() but working with such (incomplete) private keys instead of contexts. What do you think? -- With best wishes Dmitry From dold at in.tum.de Tue Feb 4 02:36:59 2014 From: dold at in.tum.de (Florian Dold) Date: Tue, 04 Feb 2014 02:36:59 +0100 Subject: Non-termination in gcry_mpi_invm, behavior of gcry_mpi_powm Message-ID: <52F0443B.9060704@in.tum.de> Hi! There's a small problem with gcry_mpi_invm and negative numbers. The following code does not terminate, when it should just set x to (-1 mod 17) = 16. gcry_mpi_t x = gcry_mpi_new (0); gcry_mpi_t p = gcry_mpi_new (0); if ((NULL == x) || (NULL == p)) abort(); gcry_mpi_set_ui (x, 0); gcry_mpi_sub_ui (x, x, 1); gcry_mpi_set_ui (p, 17); gcry_mpi_invm (x, x, p); Furthermore, I've noticed that gcry_mpi_powm has no return value. What happens, in general, if the result does not exist, e.g. for "gcry_mpi_powm(x,2,-1,4)"? - Florian From dold at in.tum.de Tue Feb 4 01:36:58 2014 From: dold at in.tum.de (Florian Dold) Date: Tue, 04 Feb 2014 01:36:58 +0100 Subject: Florian Dold DCO Message-ID: <52F0362A.1060605@in.tum.de> Libgcrypt Developer's Certificate of Origin. Version 1.0 ========================================================= By making a contribution to the Libgcrypt project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the free software license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate free software license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same free software license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the free software license(s) involved. Signed-off-by: Florian Dold -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 555 bytes Desc: OpenPGP digital signature URL: From jussi.kivilinna at iki.fi Tue Feb 4 17:15:32 2014 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Tue, 04 Feb 2014 18:15:32 +0200 Subject: [PATCH 1/2] Fix ARMv6 detection when CFLAGS modify target CPU architecture Message-ID: <20140204161532.27991.9715.stgit@localhost6.localdomain6> * configure.ac (gcry_cv_cc_arm_arch_is_v6): Use compiler test instead of preprocessor test. -- Old test was using C preprocessor to check ARM version macros and missed fact that using different CFLAGS affect those macros (CFLAGS are not passed to preprocessor checks). Signed-off-by: Jussi Kivilinna --- configure.ac | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/configure.ac b/configure.ac index 6254453..a447859 100644 --- a/configure.ac +++ b/configure.ac @@ -1307,8 +1307,10 @@ AC_CACHE_CHECK([whether compiler is configured for ARMv6 or newer architecture], [if test "$mpi_cpu_arch" != "arm" ; then gcry_cv_cc_arm_arch_is_v6="n/a" else - AC_EGREP_CPP(yes, - [#if defined(__arm__) && \ + gcry_cv_cc_arm_arch_is_v6=no + AC_COMPILE_IFELSE([AC_LANG_SOURCE( + [[ + #if defined(__arm__) && \ ((defined(__ARM_ARCH) && __ARM_ARCH >= 6) \ || defined(__ARM_ARCH_6__) || defined(__ARM_ARCH_6J__) \ || defined(__ARM_ARCH_6Z__) || defined(__ARM_ARCH_6ZK__) \ @@ -1316,9 +1318,13 @@ AC_CACHE_CHECK([whether compiler is configured for ARMv6 or newer architecture], || defined(__ARM_ARCH_7__) || defined(__ARM_ARCH_7A__) \ || defined(__ARM_ARCH_7R__) || defined(__ARM_ARCH_7M__) \ || defined(__ARM_ARCH_7EM__)) - yes + /* empty */ + #else + /* fail compile if not ARMv6. */ + not_armv6 not_armv6 = (not_armv6)not_armv6; #endif - ], gcry_cv_cc_arm_arch_is_v6=yes, gcry_cv_cc_arm_arch_is_v6=no) + ]])], + [gcry_cv_cc_arm_arch_is_v6=yes]) fi]) if test "$gcry_cv_cc_arm_arch_is_v6" = "yes" ; then AC_DEFINE(HAVE_ARM_ARCH_V6,1, From jussi.kivilinna at iki.fi Tue Feb 4 17:15:37 2014 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Tue, 04 Feb 2014 18:15:37 +0200 Subject: [PATCH 2/2] Disable parallel test-suite In-Reply-To: <20140204161532.27991.9715.stgit@localhost6.localdomain6> References: <20140204161532.27991.9715.stgit@localhost6.localdomain6> Message-ID: <20140204161537.27991.39501.stgit@localhost6.localdomain6> * tests/Makefile.am: Set 'serial-tests' option. -- Currently parallel test-suite does not work (tested on Ubuntu 13.10): fatal: making test-suite.log: failed to create bench-slope.trs fatal: making test-suite.log: failed to create bench-slope.log fatal: making test-suite.log: failed to create hashtest-256g.trs fatal: making test-suite.log: failed to create hashtest-256g.log make[3]: *** [test-suite.log] Error 1 Patch changes libgcrypt use serial test-suite for now. Signed-off-by: Jussi Kivilinna --- tests/Makefile.am | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tests/Makefile.am b/tests/Makefile.am index 4cf7a44..1fc750c 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -16,6 +16,8 @@ # License along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA +AUTOMAKE_OPTIONS = serial-tests + ## Process this file with automake to produce Makefile.in tests_bin = \ From dbaryshkov at gmail.com Tue Feb 4 19:36:00 2014 From: dbaryshkov at gmail.com (Dmitry Eremin-Solenikov) Date: Tue, 4 Feb 2014 22:36:00 +0400 Subject: [PATCH 2/2] Disable parallel test-suite In-Reply-To: <20140204161537.27991.39501.stgit@localhost6.localdomain6> References: <20140204161532.27991.9715.stgit@localhost6.localdomain6> <20140204161537.27991.39501.stgit@localhost6.localdomain6> Message-ID: On Tue, Feb 4, 2014 at 8:15 PM, Jussi Kivilinna wrote: > * tests/Makefile.am: Set 'serial-tests' option. > -- > > Currently parallel test-suite does not work (tested on Ubuntu 13.10): I have the following patch in my queue: @@ -33,8 +33,8 @@ tests_sh_last = hashtest-256g TESTS = $(tests_bin) $(tests_sh) $(tests_bin_last) $(tests_sh_last) # Force sequential run of some tests. -bench-slope.log: benchmark.log -hashtest-256g.log: bench-slope.log +bench-slope.trs: benchmark.trs +hashtest-256g.trs: bench-slope.trs TESTS_ENVIRONMENT = GCRYPT_IN_REGRESSION_TEST=1 It might work for you. -- With best wishes Dmitry From wk at gnupg.org Tue Feb 4 20:52:07 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 04 Feb 2014 20:52:07 +0100 Subject: [PATCH 2/2] Disable parallel test-suite In-Reply-To: <20140204161537.27991.39501.stgit@localhost6.localdomain6> (Jussi Kivilinna's message of "Tue, 04 Feb 2014 18:15:37 +0200") References: <20140204161532.27991.9715.stgit@localhost6.localdomain6> <20140204161537.27991.39501.stgit@localhost6.localdomain6> Message-ID: <87ha8eveoo.fsf@vigenere.g10code.de> On Tue, 4 Feb 2014 17:15, jussi.kivilinna at iki.fi said: > * tests/Makefile.am: Set 'serial-tests' option. You can't do that because it breaks automake 1.11 which is what we use for various reasons. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From jussi.kivilinna at iki.fi Tue Feb 4 21:15:47 2014 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Tue, 04 Feb 2014 22:15:47 +0200 Subject: [PATCH 2/2] Disable parallel test-suite In-Reply-To: References: <20140204161532.27991.9715.stgit@localhost6.localdomain6> <20140204161537.27991.39501.stgit@localhost6.localdomain6> Message-ID: <52F14A73.8040307@iki.fi> On 04.02.2014 20:36, Dmitry Eremin-Solenikov wrote: > On Tue, Feb 4, 2014 at 8:15 PM, Jussi Kivilinna wrote: >> * tests/Makefile.am: Set 'serial-tests' option. >> -- >> >> Currently parallel test-suite does not work (tested on Ubuntu 13.10): > > I have the following patch in my queue: > > @@ -33,8 +33,8 @@ tests_sh_last = hashtest-256g > TESTS = $(tests_bin) $(tests_sh) $(tests_bin_last) $(tests_sh_last) > > # Force sequential run of some tests. > -bench-slope.log: benchmark.log > -hashtest-256g.log: bench-slope.log > +bench-slope.trs: benchmark.trs > +hashtest-256g.trs: bench-slope.trs > > > TESTS_ENVIRONMENT = GCRYPT_IN_REGRESSION_TEST=1 > > It might work for you. Yes, that fixes the problem. -Jussi > > > > From wk at gnupg.org Fri Feb 7 02:04:42 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 07 Feb 2014 01:04:42 -0000 Subject: [Announce] Libgcrypt 1.6.0 released Message-ID: <87haa8fzzm.fsf@vigenere.g10code.de> Hello! The GNU project is pleased to announce the availability of Libgcrypt version 1.6.0. This is the new stable version of Libgcrypt with the API being mostly compatible to previous versions. Due to the removal of certain long deprecated functions this version introduces an ABI change. 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. The main features of this version are performance improvements [3], better support for elliptic curves, new algorithms and modes, as well as API and internal cleanups. Better performance of public key algorithms, in particular for Curve25519, is planned for forthcoming releases. Note that the 1.5 series will enter end of life state on 2016-12-31. Noteworthy changes between version 1.5.0 and 1.6.0: =================================================== * Removed the long deprecated gcry_ac interface. Thus Libgcrypt is not anymore ABI compatible to previous versions if they used the ac interface. * Removed the module register subsystem. * The deprecated message digest debug macros have been removed. Use gcry_md_debug instead. * Removed deprecated control codes. * Improved performance of most cipher algorithms as well as for the SHA family of hash functions. * Added support for the IDEA cipher algorithm. * Added support for the Salsa20 and reduced Salsa20/12 stream ciphers. * Added limited support for the GOST 28147-89 cipher algorithm. * Added support for the GOST R 34.11-94 and R 34.11-2012 (Stribog) hash algorithms. * Added a random number generator to directly use the system's RNG. Also added an interface to prefer the use of a specified RNG. * Added support for the SCRYPT algorithm. * Mitigated the Yarom/Falkner flush+reload side-channel attack on RSA secret keys. See [CVE-2013-4242]. * Added support for Deterministic DSA as per RFC-6969. * Added support for curve Ed25519. * Added a scatter gather hash convenience function. * Added several MPI amd SEXP helper functions. * Added support for negative numbers to gcry_mpi_print, gcry_mpi_aprint and gcry_mpi_scan. * The algorithm ids GCRY_PK_ECDSA and GCRY_PK_ECDH are now deprecated. Use GCRY_PK_ECC if you need an algorithm id. * Changed gcry_pk_genkey for "ecc" to only include the curve name and not the parameters. The flag "param" may be used to revert this. * Added a feature to globally disable selected hardware features. * Added debug helper functions. For Interface changes relative to the 1.5.0 release see below [4]. Download ======== 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.6.0.tar.bz2 (2441k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.0.tar.bz2.sig This file is bzip2 compressed. A gzip compressed version is also available: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.0.tar.gz (2866k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.0.tar.gz.sig Due to the amount of changes we don't provide a patch file against 1.5.x. The SHA-1 checksums are: 43283c0b41c41e3d3bc13c2d8f937dfe2aaa1a77 libgcrypt-1.6.0.tar.bz2 03551121fe5b706532158667699f63b6e2606755 libgcrypt-1.6.0.tar.gz Copying ======= Libgcrypt is distributed under the terms of the GNU Lesser General Public License (LGPLv2.1+). The helper programs as well as the documentation are distributed under the terms of the GNU General Public License (GPLv2+). The file LICENSES has notices about contributions that require these additional notices are distributed. Support ======= For help on developing with Libgcrypt you should read the included manual and optional ask on the gcrypt-devel mailing list [1]. A listing with commercial support offers for Libgcrypt and related software is available at the GnuPG web site [2]. The driving force behind the development of Libgcrypt is my company g10 Code. Maintenance and improvement of Libgcrypt and related software takes up most of our resources. To allow us to continue our work on free software, we ask to either purchase a support contract, engage us for custom enhancements, or to donate money: http://g10code.com/gnupg-donation.html Thanks ====== Many thanks to all who contributed to Libgcrypt development, be it bug fixes, code, documentation, testing or helping users. Special thanks to Jussi Kivilinna who did most of the performance improvement work. Happy hacking, Werner [1] http://www.gnupg.org/documentation/mailing-lists.html [2] http://www.gnupg.org/service.html [3] http://blog.gnupg.org/20131215-gcrypt-bench.html [4] Interface changes relative to the 1.5.0 release: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ gcry_ac_* REMOVED. GCRY_AC_* REMOVED. gcry_module_t REMOVED. gcry_cipher_register REMOVED. gcry_cipher_unregister REMOVED. gcry_cipher_list REMOVED. gcry_pk_register REMOVED. gcry_pk_unregister REMOVED. gcry_pk_list REMOVED. gcry_md_register REMOVED. gcry_md_unregister REMOVED. gcry_md_list REMOVED. gcry_md_start_debug REMOVED (macro). gcry_md_stop_debug REMOVED (macro). GCRYCTL_SET_KEY REMOVED. GCRYCTL_SET_IV REMOVED. GCRYCTL_SET_CTR REMOVED. GCRYCTL_DISABLE_ALGO CHANGED: Not anymore thread-safe. gcry_pk_genkey CHANGED: ECC curve params not returned. gcry_md_hash_buffers NEW. gcry_buffer_t NEW. GCRYCTL_SET_ENFORCED_FIPS_FLAG NEW. GCRYCTL_SET_PREFERRED_RNG_TYPE NEW. GCRYCTL_GET_CURRENT_RNG_TYPE NEW. GCRYCTL_CLOSE_RANDOM_DEVICE NEW. GCRY_RNG_TYPE_STANDARD NEW. GCRY_RNG_TYPE_FIPS NEW. GCRY_RNG_TYPE_SYSTEM NEW. gcry_mpi_is_neg NEW. gcry_mpi_neg NEW. gcry_mpi_abs NEW. gcry_mpi_snatch NEW. gcry_mpi_set_opaque_copy NEW. gcry_mpi_point_t NEW. gcry_mpi_point_new NEW. gcry_mpi_point_release NEW. gcry_mpi_point_get NEW. gcry_mpi_point_snatch_get NEW. gcry_mpi_point_set NEW. gcry_mpi_point_snatch_set NEW. gcry_ctx_t NEW. gcry_ctx_release NEW. gcry_mpi_ec_new NEW. gcry_mpi_ec_get_mpi NEW. gcry_mpi_ec_get_point NEW. gcry_mpi_ec_set_mpi NEW. gcry_mpi_ec_set_point NEW. gcry_mpi_ec_get_affine NEW. gcry_mpi_ec_dup NEW. gcry_mpi_ec_add NEW. gcry_mpi_ec_mul NEW. gcry_mpi_ec_curve_point NEW. GCRYMPI_FLAG_IMMUTABLE NEW. GCRYMPI_FLAG_CONST NEW. GCRYMPI_FLAG_USER1 NEW. GCRYMPI_FLAG_USER2 NEW. GCRYMPI_FLAG_USER3 NEW. GCRYMPI_FLAG_USER4 NEW. GCRYMPI_CONST_ONE NEW. GCRYMPI_CONST_TWO NEW. GCRYMPI_CONST_THREE NEW. GCRYMPI_CONST_FOUR NEW. GCRYMPI_CONST_EIGHT NEW. GCRYMPI_FMT_OPAQUE NEW. GCRYPT_VERSION_NUMBER NEW. GCRY_KDF_SCRYPT NEW. gcry_pubkey_get_sexp NEW. GCRYCTL_DISABLE_LOCKED_SECMEM NEW. GCRYCTL_DISABLE_PRIV_DROP NEW. GCRY_CIPHER_SALSA20 NEW. gcry_sexp_nth_buffer NEW. gcry_sexp_extract_param NEW. GCRY_CIPHER_SALSA20R12 NEW. GCRY_CIPHER_GOST28147 NEW. GCRY_MD_GOSTR3411_94 NEW. GCRY_MD_STRIBOG256 NEW. GCRY_MD_STRIBOG512 NEW. GCRY_PK_ECC NEW. gcry_log_debug NEW. gcry_log_debughex NEW. gcry_log_debugmpi NEW. gcry_log_debugpnt NEW. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 204 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From cvs at cvs.gnupg.org Sun Feb 9 13:21:33 2014 From: cvs at cvs.gnupg.org (by Jussi Kivilinna) Date: Sun, 09 Feb 2014 13:21:33 +0100 Subject: [git] GCRYPT - branch, master, updated. libgcrypt-1.6.0-56-g6be3032 Message-ID: This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The GNU crypto library". The branch, master has been updated via 6be3032048ee2466511d2384fcf2d28b856219b2 (commit) from 6e83552dde83a8b4f639071551a20e33a9d46eb9 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 6be3032048ee2466511d2384fcf2d28b856219b2 Author: Jussi Kivilinna Date: Tue Feb 4 17:50:48 2014 +0200 Fix ARMv6 detection when CFLAGS modify target CPU architecture * configure.ac (gcry_cv_cc_arm_arch_is_v6): Use compiler test instead of preprocessor test. -- Old test was using C preprocessor to check ARM version macros and missed fact that using different CFLAGS affect those macros (CFLAGS are not passed to preprocessor checks). Signed-off-by: Jussi Kivilinna diff --git a/configure.ac b/configure.ac index 6254453..a447859 100644 --- a/configure.ac +++ b/configure.ac @@ -1307,8 +1307,10 @@ AC_CACHE_CHECK([whether compiler is configured for ARMv6 or newer architecture], [if test "$mpi_cpu_arch" != "arm" ; then gcry_cv_cc_arm_arch_is_v6="n/a" else - AC_EGREP_CPP(yes, - [#if defined(__arm__) && \ + gcry_cv_cc_arm_arch_is_v6=no + AC_COMPILE_IFELSE([AC_LANG_SOURCE( + [[ + #if defined(__arm__) && \ ((defined(__ARM_ARCH) && __ARM_ARCH >= 6) \ || defined(__ARM_ARCH_6__) || defined(__ARM_ARCH_6J__) \ || defined(__ARM_ARCH_6Z__) || defined(__ARM_ARCH_6ZK__) \ @@ -1316,9 +1318,13 @@ AC_CACHE_CHECK([whether compiler is configured for ARMv6 or newer architecture], || defined(__ARM_ARCH_7__) || defined(__ARM_ARCH_7A__) \ || defined(__ARM_ARCH_7R__) || defined(__ARM_ARCH_7M__) \ || defined(__ARM_ARCH_7EM__)) - yes + /* empty */ + #else + /* fail compile if not ARMv6. */ + not_armv6 not_armv6 = (not_armv6)not_armv6; #endif - ], gcry_cv_cc_arm_arch_is_v6=yes, gcry_cv_cc_arm_arch_is_v6=no) + ]])], + [gcry_cv_cc_arm_arch_is_v6=yes]) fi]) if test "$gcry_cv_cc_arm_arch_is_v6" = "yes" ; then AC_DEFINE(HAVE_ARM_ARCH_V6,1, ----------------------------------------------------------------------- Summary of changes: configure.ac | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) hooks/post-receive -- The GNU crypto library http://git.gnupg.org _______________________________________________ Gnupg-commits mailing list Gnupg-commits at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-commits From dbaryshkov at gmail.com Fri Feb 14 22:23:43 2014 From: dbaryshkov at gmail.com (Dmitry Eremin-Solenikov) Date: Sat, 15 Feb 2014 01:23:43 +0400 Subject: "Fixing" private key/generating public key from incomplete private In-Reply-To: References: Message-ID: Hello, On Sat, Feb 1, 2014 at 9:06 PM, Dmitry Eremin-Solenikov wrote: > > I'm looking for a way to 'fixup' the private key. For example. I load > the DSA key from PKCS#8 keyfile. It contains (in terms of gcrypt > s-exp) domain parameters (p, q, g), secret exponent (x) but no > public exponent (y). I found gcrypt_pubkey_get_sexp, but it > (currently) only works for ECC. > > It there a good way to solve my problem? I was thinking about > adding an special mode to gcry_pk_genkey or about adding a > special API resembling gcrypt_pubkey_get_sexp() but working > with such (incomplete) private keys instead of contexts. Werner, what is your opinion? I'd like to have a way to do 'key fixture' in a generic way from the API point of view, rather than applying fixes on an algo-by-algo cases in my application. -- With best wishes Dmitry From dbaryshkov at gmail.com Mon Feb 17 19:04:14 2014 From: dbaryshkov at gmail.com (Dmitry Eremin-Solenikov) Date: Mon, 17 Feb 2014 22:04:14 +0400 Subject: Scanning LSB MPI values Message-ID: Hello, On my way of Gost algorithms, I faced MPI values being written in LSB format. Would it be suitable to add LSB format support to libgcrypt, or I should convert the value and then scan it using already existing formats? -- With best wishes Dmitry From wk at gnupg.org Tue Feb 18 10:05:36 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 18 Feb 2014 10:05:36 +0100 Subject: Scanning LSB MPI values In-Reply-To: (Dmitry Eremin-Solenikov's message of "Mon, 17 Feb 2014 22:04:14 +0400") References: Message-ID: <8738jg94f3.fsf@vigenere.g10code.de> On Mon, 17 Feb 2014 19:04, dbaryshkov at gmail.com said: > On my way of Gost algorithms, I faced MPI values being written in LSB format. > Would it be suitable to add LSB format support to libgcrypt, or I Sure. BTW, I have some code in the works to replace the runtime scanning of the hex encoded values by storing them in binary format. That is for the curve parameters and some other constants. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From smueller at chronox.de Tue Feb 25 22:25:33 2014 From: smueller at chronox.de (Stephan Mueller) Date: Tue, 25 Feb 2014 22:25:33 +0100 Subject: [RFC][PATCH] SP800-90A DRBG Message-ID: <5627717.yc366OUNsI@myon.chronox.de> Hi, As defined in SP800-131A, the ANSI X9.31 DRNG is to be sunset by the end of this year for official uses, including FIPS 140-2 compliance. I created a clean-room implementation of the DRBGs defined in SP800-90A, specifically the Hash DRBG, HMAC DRBG and CTR DRBG. All three DRBGs are implemented with a derivation function and with the support of prediction resistance. The implementation is available at [1]. That implementation is functionally complete as it implements all aspects defined by SP800-90A. [1] is a self- contained implementation. The implementation can be integrated into libgcrypt with the patch libgcrypt-1.6.0-git.diff provided in the source code tree. In addition, a test application is provided that demonstrates the proper operation of all DRBGs. The provided code is ready for testing by simply compiling the test application by invoking make -f Makefile.gcry -- the resulting application shows how the DRBG works. The aforementioned diff integrates the DRBG into libgcrypt. A second application is provided in tests/libgcrypt and demonstrates how to use the DRBG with libgcrypt. The code [1] just needs some small refactoring to turn them into a patch for the request for inclusion into libgcrypt -- and asking for an official review :-) . For example, the GCRY_APP code needs to be removed. Also, the contents drbg-gcry.h needs to go into the drbg.c file. I am happy to perform the changes and offer ready-to-go patches. The current code, however, allows for easy development. But before making a full patch set, there are several issues that need to be clarified. All issues are marked with TODOs throughout the code. With the following list, all issues are extracted. May I ask for help to clarify the following questions: * libgcrypt does not offer a reseed API call. Wouldn't it make sense to add such a reseed API? * What does the full variable used with the initialization call mean for the DRBG? * The SP800-90A defines that a caller requesting the initialization of the DRBG may provide a so-called "personalization string" that is used as data concatenated with real seed. The DRBG code implements the proper handling of the personalization string. Though, the libgcrypt API initialization call does not allow the caller to provide such additional data. * Similar to for initialization, SP800-90A allows the requestor of random bits to provide "additional information" which are to be mixed into the DRBG before generating the random bits. The DRBG code implements the proper handling of the additional information string. Though, the libgcrypt RNG gathering call does not allow the caller to provide such additional data. * Into which header file should the DRBG specification flags that can be used with the gcry_control of GCRYCTRL_DRBG_FLAGS go? I would guess it needs to go into gcrypt.h. [1] http://www.chronox.de/drbg.html Ciao Stephan -- | Cui bono? | From smueller at chronox.de Wed Feb 26 13:53:03 2014 From: smueller at chronox.de (Stephan Mueller) Date: Wed, 26 Feb 2014 13:53:03 +0100 Subject: libgcrypt RNG locking Message-ID: <1648375.X9uGvL36Ez@myon.chronox.de> Hi, For my DRBG implementation, I use the locking approach found in random-fips.c. The following code implements locking: GPGRT_LOCK_DEFINE (drbg_gcry_lock); static inline void drbg_lock(drbg_lock_t *lock) { gpg_err_code_t rc; (void)lock; rc = gpgrt_lock_lock (&drbg_gcry_lock); if (rc) log_fatal ("failed to acquire the RNG lock: %s\n", gpg_strerror (rc)); } static inline void drbg_unlock(drbg_lock_t *lock) { gpg_err_code_t rc; (void)lock; rc = gpgrt_lock_unlock (&drbg_gcry_lock); if (rc) log_fatal ("failed to release the RNG lock: %s\n", gpg_strerror (rc)); } The problem I have with this code is that there seems to be no locking taking place at all. I found that I should have a deadlock in the published code which, however, does not materialize. If I try to trigger a simple deadlock by calling: drbg_lock(0); drbg_lock(0); there is no deadlock. What is wrong with the locking approach? Please note that the drbg_lock_t type resolves to an int and is present due the kernel support of the DRBG. Ciao Stephan -- | Cui bono? | From wk at gnupg.org Wed Feb 26 16:42:23 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 26 Feb 2014 16:42:23 +0100 Subject: libgcrypt RNG locking In-Reply-To: <1648375.X9uGvL36Ez@myon.chronox.de> (Stephan Mueller's message of "Wed, 26 Feb 2014 13:53:03 +0100") References: <1648375.X9uGvL36Ez@myon.chronox.de> Message-ID: <87ob1tvq1s.fsf@vigenere.g10code.de> On Wed, 26 Feb 2014 13:53, smueller at chronox.de said: > If I try to trigger a simple deadlock by calling: > > drbg_lock(0); > drbg_lock(0); > > there is no deadlock. There are two possible reasons: gpgrt could be using recursive mutexes and thus you won't be able to create a deadlock with just one thread. However, for common Linux systems this is not the case. The second and more likely reason is that you did not link with -lpthread and thus the process has not thread support which makes mutexes pointless. libgpg-error uses ELF weak symbols to implement that. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From smueller at chronox.de Wed Feb 26 17:08:41 2014 From: smueller at chronox.de (Stephan Mueller) Date: Wed, 26 Feb 2014 17:08:41 +0100 Subject: libgcrypt RNG locking In-Reply-To: <87ob1tvq1s.fsf@vigenere.g10code.de> References: <1648375.X9uGvL36Ez@myon.chronox.de> <87ob1tvq1s.fsf@vigenere.g10code.de> Message-ID: <2236675.YjWT4svJLt@myon.chronox.de> Am Mittwoch, 26. Februar 2014, 16:42:23 schrieb Werner Koch: Hi Werner, > On Wed, 26 Feb 2014 13:53, smueller at chronox.de said: > > If I try to trigger a simple deadlock by calling: > > > > drbg_lock(0); > > drbg_lock(0); > > > > there is no deadlock. > > There are two possible reasons: gpgrt could be using recursive mutexes > and thus you won't be able to create a deadlock with just one thread. > However, for common Linux systems this is not the case. The second and > more likely reason is that you did not link with -lpthread and thus the > process has not thread support which makes mutexes pointless. libgpg-error > uses ELF weak symbols to implement that. Thank you very much. This is indeed the solution for enforcing the locking. I will post a new version of the DRBG code without deadlocking shortly. > > > Salam-Shalom, > > Werner Ciao Stephan -- | Cui bono? | From lists at alejosanchez.com Thu Feb 27 21:37:49 2014 From: lists at alejosanchez.com (Alejo Sanchez) Date: Thu, 27 Feb 2014 17:37:49 -0300 Subject: Trivial patch for showing session keys of incomplete files Message-ID: Hello, For a simple backup system for very sensitive information we needed to avoid uploading private keys to the servers. The workaround I found was to get to a trusted computer the first 400 bytes of the files to decrypt, get the session keys out of those, and then do a decrypt on the server with those session keys. For some reason the current GnuPG version has the print statement for the file's session key below error check. Just moving the code block up does the trick. Posting here in case this is useful for the project or anybody else. Hope this is the right place. Thanks a lot for such a great project, Alejo --- gnupg-2.0.22/g10/mainproc.c 2013-10-04 10:00:22.000000000 -0300 +++ Sft/gnupg-2.0.22/g10/mainproc.c 2013-12-03 12:10:06.748530302 -0300 @@ -572,6 +572,18 @@ if( !result ) result = decrypt_data( c, pkt->pkt.encrypted, c->dek ); + /* XXX show session key, even for broken files */ + if(opt.show_session_key) + { + int i; + char *buf = xmalloc ( c->dek->keylen*2 + 20 ); + sprintf ( buf, "%d:", c->dek->algo ); + for(i=0; i < c->dek->keylen; i++ ) + sprintf(buf+strlen(buf), "%02X", c->dek->key[i] ); + log_info( "session key: `%s'\n", buf ); + write_status_text ( STATUS_SESSION_KEY, buf ); + } + if( result == -1 ) ; else if( !result || (gpg_err_code (result) == GPG_ERR_BAD_SIGNATURE @@ -583,16 +595,6 @@ write_status( STATUS_GOODMDC ); else if(!opt.no_mdc_warn) log_info (_("WARNING: message was not integrity protected\n")); - if(opt.show_session_key) - { - int i; - char *buf = xmalloc ( c->dek->keylen*2 + 20 ); - sprintf ( buf, "%d:", c->dek->algo ); - for(i=0; i < c->dek->keylen; i++ ) - sprintf(buf+strlen(buf), "%02X", c->dek->key[i] ); - log_info( "session key: `%s'\n", buf ); - write_status_text ( STATUS_SESSION_KEY, buf ); - } } else if( result == G10ERR_BAD_SIGN ) { log_error(_("WARNING: encrypted message has been manipulated!\n"));