From cvs at cvs.gnupg.org Fri Apr 1 13:59:10 2016 From: cvs at cvs.gnupg.org (by Werner Koch) Date: Fri, 01 Apr 2016 13:59:10 +0200 Subject: [git] GCRYPT - branch, master, updated. libgcrypt-1.6.0-371-g862cf19 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 862cf19a119427dd7ee7959a36c72d905f5ea5ca (commit) from fcce0cb6e8af70b134c6ecc3f56afa07a7d31f27 (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 862cf19a119427dd7ee7959a36c72d905f5ea5ca Author: Werner Koch Date: Fri Apr 1 13:42:01 2016 +0200 mpi: Explicitly limit the allowed input length for gcry_mpi_scan. * mpi/mpicoder.c (MAX_EXTERN_SCAN_BYTES): New. (mpi_fromstr): Check against this limit. (_gcry_mpi_scan): Ditto. * tests/mpitests.c (test_maxsize): New. (main): Cal that test. -- A too large buffer length may lead to an unsigned integer overflow on systems where size_t > unsigned int (ie. 64 bit systems). The computation of the required number of nlimbs may also be affected by this. However this is not a real world case because any processing which has allocated such a long buffer from an external source would be prone to other DoS attacks: The required buffer length to exhibit this overflow is at least 2^32 - 8 bytes. Signed-off-by: Werner Koch diff --git a/doc/gcrypt.texi b/doc/gcrypt.texi index 437dddb..c710765 100644 --- a/doc/gcrypt.texi +++ b/doc/gcrypt.texi @@ -4526,7 +4526,8 @@ representation of an MPI and the internal one of Libgcrypt. Convert the external representation of an integer stored in @var{buffer} with a length of @var{buflen} into a newly created MPI returned which will be stored at the address of @var{r_mpi}. For certain formats the -length argument is not required and should be passed as @code{0}. After a +length argument is not required and should be passed as @code{0}. A + at var{buflen} larger than 16 MiByte will be rejected. After a successful operation the variable @var{nscanned} receives the number of bytes actually scanned unless @var{nscanned} was given as @code{NULL}. @var{format} describes the format of the MPI as stored in @@ -4540,6 +4541,7 @@ bytes actually scanned unless @var{nscanned} was given as @item GCRYMPI_FMT_PGP As used by OpenPGP (only defined as unsigned). This is basically @code{GCRYMPI_FMT_STD} with a 2 byte big endian length header. +A length header indicating a length of more than 16384 is not allowed. @item GCRYMPI_FMT_SSH As used in the Secure Shell protocol. This is @code{GCRYMPI_FMT_STD} diff --git a/mpi/mpicoder.c b/mpi/mpicoder.c index 896dda1..e315576 100644 --- a/mpi/mpicoder.c +++ b/mpi/mpicoder.c @@ -27,8 +27,21 @@ #include "mpi-internal.h" #include "g10lib.h" +/* The maximum length we support in the functions converting an + * external representation to an MPI. This limit is used to catch + * programming errors and to avoid DoS due to insane long allocations. + * The 16 MiB limit is actually ridiculous large but some of those PQC + * algorithms use quite large keys and they might end up using MPIs + * for that. */ +#define MAX_EXTERN_SCAN_BYTES (16*1024*1024) + +/* The maximum length (in bits) we support for OpenPGP MPIs. Note + * that OpenPGP's MPI format uses only two bytes and thus would be + * limited to 64k anyway. Note that this limit matches that used by + * GnuPG. */ #define MAX_EXTERN_MPI_BITS 16384 + /* Helper used to scan PGP style MPIs. Returns NULL on failure. */ static gcry_mpi_t mpi_read_from_buffer (const unsigned char *buffer, unsigned *ret_nread, @@ -104,7 +117,13 @@ mpi_fromstr (gcry_mpi_t val, const char *str) if ( *str == '0' && str[1] == 'x' ) str += 2; - nbits = 4 * strlen (str); + nbits = strlen (str); + if (nbits > MAX_EXTERN_SCAN_BYTES) + { + mpi_clear (val); + return 1; /* Error. */ + } + nbits *= 4; if ((nbits % 8)) prepend_zero = 1; @@ -438,9 +457,9 @@ twocompl (unsigned char *p, unsigned int n) /* Convert the external representation of an integer stored in BUFFER - with a length of BUFLEN into a newly create MPI returned in - RET_MPI. If NBYTES is not NULL, it will receive the number of - bytes actually scanned after a successful operation. */ + * with a length of BUFLEN into a newly create MPI returned in + * RET_MPI. If NSCANNED is not NULL, it will receive the number of + * bytes actually scanned after a successful operation. */ gcry_err_code_t _gcry_mpi_scan (struct gcry_mpi **ret_mpi, enum gcry_mpi_format format, const void *buffer_arg, size_t buflen, size_t *nscanned) @@ -450,6 +469,13 @@ _gcry_mpi_scan (struct gcry_mpi **ret_mpi, enum gcry_mpi_format format, unsigned int len; int secure = (buffer && _gcry_is_secure (buffer)); + if (buflen > MAX_EXTERN_SCAN_BYTES) + { + if (nscanned) + *nscanned = 0; + return GPG_ERR_INV_OBJ; + } + if (format == GCRYMPI_FMT_SSH) len = 0; else diff --git a/tests/mpitests.c b/tests/mpitests.c index e6f8525..b663029 100644 --- a/tests/mpitests.c +++ b/tests/mpitests.c @@ -237,6 +237,42 @@ test_opaque (void) static void +test_maxsize (void) +{ + gpg_error_t err; + gcry_mpi_t a; + char buffer[2+2048]; /* For PGP: 2 length bytes and 16384 bits. */ + + memset (buffer, 0x55, sizeof buffer); + + /* We use a short buffer but a give a too large length to simulate a + * programming error. In case this test fails (i.e. die() is + * called) the scan function may have access data outside of BUFFER + * which may result in a segv but we ignore that to avoid actually + * allocating such a long buffer. */ + err = gcry_mpi_scan (&a, GCRYMPI_FMT_USG, buffer, 16*1024*1024 +1, NULL); + if (gpg_err_code (err) != GPG_ERR_INV_OBJ) + die ("gcry_mpi_scan does not detect its generic input limit\n"); + + /* Now test the PGP limit. The scan code check the two length bytes + * from the buffer and thus it is sufficient to fake them. */ + buffer[0] = (16385 >> 8); + buffer[1] = (16385 & 0xff); + err = gcry_mpi_scan (&a, GCRYMPI_FMT_PGP, buffer, sizeof buffer, NULL); + if (gpg_err_code (err) != GPG_ERR_INV_OBJ) + die ("gcry_mpi_scan does not detect the PGP input limit\n"); + + buffer[0] = (16384 >> 8); + buffer[1] = (16384 & 0xff); + + err = gcry_mpi_scan (&a, GCRYMPI_FMT_PGP, buffer, sizeof buffer, NULL); + if (err) + die ("gcry_mpi_scan did not parse a large PGP: %s\n", gpg_strerror (err)); + gcry_mpi_release (a); +} + + +static void test_cmp (void) { gpg_error_t rc; @@ -569,6 +605,7 @@ main (int argc, char* argv[]) test_const_and_immutable (); test_opaque (); + test_maxsize (); test_cmp (); test_add (); test_sub (); ----------------------------------------------------------------------- Summary of changes: doc/gcrypt.texi | 4 +++- mpi/mpicoder.c | 34 ++++++++++++++++++++++++++++++---- tests/mpitests.c | 37 +++++++++++++++++++++++++++++++++++++ 3 files changed, 70 insertions(+), 5 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 wk at gnupg.org Mon Apr 4 11:05:24 2016 From: wk at gnupg.org (Werner Koch) Date: Mon, 04 Apr 2016 11:05:24 +0200 Subject: [PATCH 1/2] Update .gitignore In-Reply-To: <56E87519.40908@iki.fi> (Jussi Kivilinna's message of "Tue, 15 Mar 2016 22:48:25 +0200") References: <20160312174248.12371.90456.stgit@localhost6.localdomain6> <878u1lpbqc.fsf@wheatstone.g10code.de> <56E87519.40908@iki.fi> Message-ID: <877fgdbv6z.fsf@wheatstone.g10code.de> On Tue, 15 Mar 2016 21:48, jussi.kivilinna at iki.fi said: > I think commit 2cba0dbda462237f55438d4199eccd10c5e3f6ca (salsa20: fix > alignment of self-test context) should be cherry-picked to libgcrypt > 1.6 branch. It fixe Done. Thanks. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Tue Apr 5 04:46:59 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 05 Apr 2016 11:46:59 +0900 Subject: Positive value for ECC (was: ecc: effort so that we can enable barret reduction) In-Reply-To: <56679C01.8040300@fsij.org> References: <56679C01.8040300@fsij.org> Message-ID: <57032723.9080205@fsij.org> On 12/09/2015 12:12 PM, NIIBE Yutaka wrote: > Following patch is the one which allow a user to enable > GCRYPT_BARRETT. With this patch, it goes well for make check. > > IIUC, the implementation of Barrett reduction assumes positive MPI. > > It would be worth to consider applying this when someone claims it > doesn't work with GCRYPT_BARRETT. I think that it's worth to keep the value as positive for ECC computation (even if we don't enable GCRYPT_BARRETT). Here is a patch to keep the value positive in ECC computation. I'm going to commit this if no objection. diff --git a/cipher/ecc-curves.c b/cipher/ecc-curves.c index 91f29cc..3488ed3 100644 --- a/cipher/ecc-curves.c +++ b/cipher/ecc-curves.c @@ -560,9 +560,17 @@ _gcry_ecc_fill_in_curve (unsigned int nbits, const char *name, if (!curve->p) curve->p = scanval (domain_parms[idx].p); if (!curve->a) - curve->a = scanval (domain_parms[idx].a); + { + curve->a = scanval (domain_parms[idx].a); + if (curve->a->sign) + mpi_add (curve->a, curve->p, curve->a); + } if (!curve->b) - curve->b = scanval (domain_parms[idx].b); + { + curve->b = scanval (domain_parms[idx].b); + if (curve->b->sign) + mpi_add (curve->b, curve->p, curve->b); + } if (!curve->n) curve->n = scanval (domain_parms[idx].n); if (!curve->h) diff --git a/cipher/ecc-eddsa.c b/cipher/ecc-eddsa.c index 2a52b78..f91f848 100644 --- a/cipher/ecc-eddsa.c +++ b/cipher/ecc-eddsa.c @@ -251,7 +251,7 @@ _gcry_ecc_eddsa_recover_x (gcry_mpi_t x, gcry_mpi_t y, int sign, mpi_ec_t ec) mpi_mulm (t, x, x, ec->p); mpi_mulm (t, t, v, ec->p); /* -t == u ? x = x * sqrt(-1) */ - mpi_neg (t, t); + mpi_sub (t, ec->p, t); if (!mpi_cmp (t, u)) { static gcry_mpi_t m1; /* Fixme: this is not thread-safe. */ @@ -263,7 +263,7 @@ _gcry_ecc_eddsa_recover_x (gcry_mpi_t x, gcry_mpi_t y, int sign, mpi_ec_t ec) mpi_mulm (t, x, x, ec->p); mpi_mulm (t, t, v, ec->p); /* -t == u ? x = x * sqrt(-1) */ - mpi_neg (t, t); + mpi_sub (t, ec->p, t); if (!mpi_cmp (t, u)) rc = GPG_ERR_INV_OBJ; } @@ -835,7 +835,7 @@ _gcry_ecc_eddsa_verify (gcry_mpi_t input, ECC_public_key *pkey, _gcry_mpi_ec_mul_point (&Ia, s, &pkey->E.G, ctx); _gcry_mpi_ec_mul_point (&Ib, h, &Q, ctx); - _gcry_mpi_neg (Ib.x, Ib.x); + _gcry_mpi_sub (Ib.x, ctx->p, Ib.x); _gcry_mpi_ec_add_points (&Ia, &Ia, &Ib, ctx); rc = _gcry_ecc_eddsa_encodepoint (&Ia, ctx, s, h, 0, &tbuf, &tlen); if (rc) diff --git a/cipher/ecc.c b/cipher/ecc.c index 8dbf5bd..759ca42 100644 --- a/cipher/ecc.c +++ b/cipher/ecc.c @@ -783,10 +783,7 @@ ecc_check_secret_key (gcry_sexp_t keyparms) curvename = sexp_nth_string (l1, 1); if (curvename) { - rc = _gcry_ecc_update_curve_param (curvename, - &sk.E.model, &sk.E.dialect, - &sk.E.p, &sk.E.a, &sk.E.b, - &mpi_g, &sk.E.n, &sk.E.h); + rc = _gcry_ecc_fill_in_curve (0, curvename, &sk.E, NULL); if (rc) goto leave; } diff --git a/mpi/ec.c b/mpi/ec.c index f0b8374..26dd947 100644 --- a/mpi/ec.c +++ b/mpi/ec.c @@ -275,8 +275,9 @@ ec_addm (gcry_mpi_t w, gcry_mpi_t u, gcry_mpi_t v, mpi_ec_t ctx) static void ec_subm (gcry_mpi_t w, gcry_mpi_t u, gcry_mpi_t v, mpi_ec_t ec) { - (void)ec; mpi_sub (w, u, v); + while (w->sign) + mpi_add (w, w, ec->p); /*ec_mod (w, ec);*/ } @@ -811,10 +812,7 @@ dup_point_edwards (mpi_point_t result, mpi_point_t point, mpi_ec_t ctx) /* E = aC */ if (ctx->dialect == ECC_DIALECT_ED25519) - { - mpi_set (E, C); - _gcry_mpi_neg (E, E); - } + mpi_sub (E, ctx->p, C); else ec_mulm (E, ctx->a, C, ctx); @@ -1092,11 +1090,7 @@ add_points_edwards (mpi_point_t result, /* Y_3 = A ? G ? (D - aC) */ if (ctx->dialect == ECC_DIALECT_ED25519) { - /* Using ec_addm (Y3, D, C, ctx) is possible but a litte bit - slower because a subm does currently skip the mod step. */ - mpi_set (Y3, C); - _gcry_mpi_neg (Y3, Y3); - ec_subm (Y3, D, Y3, ctx); + ec_addm (Y3, D, C, ctx); } else { @@ -1218,7 +1212,7 @@ sub_points_edwards (mpi_point_t result, { mpi_point_t p2i = _gcry_mpi_point_new (0); point_set (p2i, p2); - _gcry_mpi_neg (p2i->x, p2i->x); + mpi_sub (p2i->x, ctx->p, p2i->x); add_points_edwards (result, p1, p2i, ctx); _gcry_mpi_point_release (p2i); } @@ -1538,10 +1532,7 @@ _gcry_mpi_ec_curve_point (gcry_mpi_point_t point, mpi_ec_t ctx) ec_pow2 (x, x, ctx); ec_pow2 (y, y, ctx); if (ctx->dialect == ECC_DIALECT_ED25519) - { - mpi_set (w, x); - _gcry_mpi_neg (w, w); - } + mpi_sub (w, ctx->p, x); else ec_mulm (w, ctx->a, x, ctx); ec_addm (w, w, y, ctx); diff --git a/tests/t-mpi-point.c b/tests/t-mpi-point.c index 55c6b66..84da7cc 100644 --- a/tests/t-mpi-point.c +++ b/tests/t-mpi-point.c @@ -130,8 +130,8 @@ static struct { "Ed25519", "0x7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFED", - "-0x01", - "-0x2DFC9311D490018C7338BF8688861767FF8FF5B2BEBE27548A14B235ECA6874A", + "0x7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEC", + "0x52036CEE2B6FFE738CC740797779E89800700A4D4141D8AB75EB4DCA135978A3", "0x1000000000000000000000000000000014DEF9DEA2F79CD65812631A5CF5D3ED", "0x216936D3CD6E53FEC0A4E231FDD6DC5C692CC7609525A7B2C9562D608F25D51A", "0x6666666666666666666666666666666666666666666666666666666666666658", -- From wk at gnupg.org Tue Apr 5 16:07:01 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 05 Apr 2016 16:07:01 +0200 Subject: Positive value for ECC In-Reply-To: <57032723.9080205@fsij.org> (NIIBE Yutaka's message of "Tue, 05 Apr 2016 11:46:59 +0900") References: <56679C01.8040300@fsij.org> <57032723.9080205@fsij.org> Message-ID: <8737r0175m.fsf@wheatstone.g10code.de> On Tue, 5 Apr 2016 04:46, gniibe at fsij.org said: > I think that it's worth to keep the value as positive for ECC > computation (even if we don't enable GCRYPT_BARRETT). Agreed. > Here is a patch to keep the value positive in ECC computation. > I'm going to commit this if no objection. Okay. Can you also run tests to check whether there is any noticeable performance gain? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Wed Apr 6 10:50:25 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 06 Apr 2016 17:50:25 +0900 Subject: Positive value for ECC In-Reply-To: <8737r0175m.fsf@wheatstone.g10code.de> References: <56679C01.8040300@fsij.org> <57032723.9080205@fsij.org> <8737r0175m.fsf@wheatstone.g10code.de> Message-ID: <5704CDD1.6020309@fsij.org> On 04/05/2016 11:07 PM, Werner Koch wrote: > On Tue, 5 Apr 2016 04:46, gniibe at fsij.org said: > >> I think that it's worth to keep the value as positive for ECC >> computation (even if we don't enable GCRYPT_BARRETT). > > Agreed. Note that I keep the values in domain_parms, so that computation of keygrip will not be changed. >> Here is a patch to keep the value positive in ECC computation. >> I'm going to commit this if no objection. > > Okay. Can you also run tests to check whether there is any noticeable > performance gain? Here are results. This is taken by the second run of "benchmark" program after the build. =========================== Plain vanilla $ ./benchmark ecc Algorithm generate 100*priv 100*public ------------------------------------------------ ECDSA 192 bit 80ms 1960ms 2230ms ECDSA 224 bit 110ms 2480ms 2810ms ECDSA 256 bit 120ms 3060ms 3350ms ECDSA 384 bit 250ms 6870ms 8020ms ECDSA 521 bit 600ms 18380ms 21910ms EdDSA Ed25519 40ms 4020ms 5980ms GOST 256 bit 120ms 2950ms 3670ms GOST 512 bit 570ms 17070ms 21290ms =========================== =========================== With the patch $ ./benchmark ecc Algorithm generate 100*priv 100*public ------------------------------------------------ ECDSA 192 bit 70ms 1960ms 2170ms ECDSA 224 bit 90ms 2480ms 2790ms ECDSA 256 bit 110ms 3020ms 3380ms ECDSA 384 bit 230ms 6900ms 7960ms ECDSA 521 bit 590ms 18450ms 21190ms EdDSA Ed25519 40ms 4220ms 5800ms GOST 256 bit 110ms 2920ms 3530ms GOST 512 bit 580ms 17210ms 20940ms =========================== No noticeable difference, so far. Given the condition that values are positive, it will be possible to improve smaller memory footprint for the computation (at least for MPI_EC_MONTGOMERY). -- From cvs at cvs.gnupg.org Wed Apr 6 11:18:06 2016 From: cvs at cvs.gnupg.org (by NIIBE Yutaka) Date: Wed, 06 Apr 2016 11:18:06 +0200 Subject: [git] GCRYPT - branch, master, updated. libgcrypt-1.6.0-372-g6f386ce 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 6f386ceae86a058e26294f744750f1ed2a95e604 (commit) from 862cf19a119427dd7ee7959a36c72d905f5ea5ca (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 6f386ceae86a058e26294f744750f1ed2a95e604 Author: NIIBE Yutaka Date: Wed Apr 6 18:05:38 2016 +0900 ecc: Positive values in computation. * cipher/ecc-curves.c (_gcry_ecc_fill_in_curve): Make sure coefficients A and B are positive. * cipher/ecc-eddsa.c (_gcry_ecc_eddsa_recover_x): For negation, do "P - T" instead of "-T", so that the result will be positive. (_gcry_ecc_eddsa_verify): Likewise. * cipher/ecc.c (ecc_check_secret_key): Use _gcry_ecc_fill_in_curve instead of _gcry_ecc_update_curve_param. * mpi/ec.c (ec_subm): Make sure the result will be positive. (dup_point_edwards, sub_points_edwards, _gcry_mpi_ec_curve_point): Use mpi_sub instead of mpi_neg. (add_points_edwards): Simply use ec_addm. * tests/t-mpi-point.c (test_curve): Define curves with positive coefficients. -- We keep the coefficients of domain_parms in ecc-curves.c, so that keygrip computations won't change. Signed-off-by: NIIBE Yutaka diff --git a/cipher/ecc-curves.c b/cipher/ecc-curves.c index 91f29cc..3488ed3 100644 --- a/cipher/ecc-curves.c +++ b/cipher/ecc-curves.c @@ -560,9 +560,17 @@ _gcry_ecc_fill_in_curve (unsigned int nbits, const char *name, if (!curve->p) curve->p = scanval (domain_parms[idx].p); if (!curve->a) - curve->a = scanval (domain_parms[idx].a); + { + curve->a = scanval (domain_parms[idx].a); + if (curve->a->sign) + mpi_add (curve->a, curve->p, curve->a); + } if (!curve->b) - curve->b = scanval (domain_parms[idx].b); + { + curve->b = scanval (domain_parms[idx].b); + if (curve->b->sign) + mpi_add (curve->b, curve->p, curve->b); + } if (!curve->n) curve->n = scanval (domain_parms[idx].n); if (!curve->h) diff --git a/cipher/ecc-eddsa.c b/cipher/ecc-eddsa.c index 2a52b78..f91f848 100644 --- a/cipher/ecc-eddsa.c +++ b/cipher/ecc-eddsa.c @@ -251,7 +251,7 @@ _gcry_ecc_eddsa_recover_x (gcry_mpi_t x, gcry_mpi_t y, int sign, mpi_ec_t ec) mpi_mulm (t, x, x, ec->p); mpi_mulm (t, t, v, ec->p); /* -t == u ? x = x * sqrt(-1) */ - mpi_neg (t, t); + mpi_sub (t, ec->p, t); if (!mpi_cmp (t, u)) { static gcry_mpi_t m1; /* Fixme: this is not thread-safe. */ @@ -263,7 +263,7 @@ _gcry_ecc_eddsa_recover_x (gcry_mpi_t x, gcry_mpi_t y, int sign, mpi_ec_t ec) mpi_mulm (t, x, x, ec->p); mpi_mulm (t, t, v, ec->p); /* -t == u ? x = x * sqrt(-1) */ - mpi_neg (t, t); + mpi_sub (t, ec->p, t); if (!mpi_cmp (t, u)) rc = GPG_ERR_INV_OBJ; } @@ -835,7 +835,7 @@ _gcry_ecc_eddsa_verify (gcry_mpi_t input, ECC_public_key *pkey, _gcry_mpi_ec_mul_point (&Ia, s, &pkey->E.G, ctx); _gcry_mpi_ec_mul_point (&Ib, h, &Q, ctx); - _gcry_mpi_neg (Ib.x, Ib.x); + _gcry_mpi_sub (Ib.x, ctx->p, Ib.x); _gcry_mpi_ec_add_points (&Ia, &Ia, &Ib, ctx); rc = _gcry_ecc_eddsa_encodepoint (&Ia, ctx, s, h, 0, &tbuf, &tlen); if (rc) diff --git a/cipher/ecc.c b/cipher/ecc.c index 8dbf5bd..759ca42 100644 --- a/cipher/ecc.c +++ b/cipher/ecc.c @@ -783,10 +783,7 @@ ecc_check_secret_key (gcry_sexp_t keyparms) curvename = sexp_nth_string (l1, 1); if (curvename) { - rc = _gcry_ecc_update_curve_param (curvename, - &sk.E.model, &sk.E.dialect, - &sk.E.p, &sk.E.a, &sk.E.b, - &mpi_g, &sk.E.n, &sk.E.h); + rc = _gcry_ecc_fill_in_curve (0, curvename, &sk.E, NULL); if (rc) goto leave; } diff --git a/mpi/ec.c b/mpi/ec.c index f0b8374..26dd947 100644 --- a/mpi/ec.c +++ b/mpi/ec.c @@ -275,8 +275,9 @@ ec_addm (gcry_mpi_t w, gcry_mpi_t u, gcry_mpi_t v, mpi_ec_t ctx) static void ec_subm (gcry_mpi_t w, gcry_mpi_t u, gcry_mpi_t v, mpi_ec_t ec) { - (void)ec; mpi_sub (w, u, v); + while (w->sign) + mpi_add (w, w, ec->p); /*ec_mod (w, ec);*/ } @@ -811,10 +812,7 @@ dup_point_edwards (mpi_point_t result, mpi_point_t point, mpi_ec_t ctx) /* E = aC */ if (ctx->dialect == ECC_DIALECT_ED25519) - { - mpi_set (E, C); - _gcry_mpi_neg (E, E); - } + mpi_sub (E, ctx->p, C); else ec_mulm (E, ctx->a, C, ctx); @@ -1092,11 +1090,7 @@ add_points_edwards (mpi_point_t result, /* Y_3 = A ? G ? (D - aC) */ if (ctx->dialect == ECC_DIALECT_ED25519) { - /* Using ec_addm (Y3, D, C, ctx) is possible but a litte bit - slower because a subm does currently skip the mod step. */ - mpi_set (Y3, C); - _gcry_mpi_neg (Y3, Y3); - ec_subm (Y3, D, Y3, ctx); + ec_addm (Y3, D, C, ctx); } else { @@ -1218,7 +1212,7 @@ sub_points_edwards (mpi_point_t result, { mpi_point_t p2i = _gcry_mpi_point_new (0); point_set (p2i, p2); - _gcry_mpi_neg (p2i->x, p2i->x); + mpi_sub (p2i->x, ctx->p, p2i->x); add_points_edwards (result, p1, p2i, ctx); _gcry_mpi_point_release (p2i); } @@ -1538,10 +1532,7 @@ _gcry_mpi_ec_curve_point (gcry_mpi_point_t point, mpi_ec_t ctx) ec_pow2 (x, x, ctx); ec_pow2 (y, y, ctx); if (ctx->dialect == ECC_DIALECT_ED25519) - { - mpi_set (w, x); - _gcry_mpi_neg (w, w); - } + mpi_sub (w, ctx->p, x); else ec_mulm (w, ctx->a, x, ctx); ec_addm (w, w, y, ctx); diff --git a/tests/t-mpi-point.c b/tests/t-mpi-point.c index 55c6b66..84da7cc 100644 --- a/tests/t-mpi-point.c +++ b/tests/t-mpi-point.c @@ -130,8 +130,8 @@ static struct { "Ed25519", "0x7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFED", - "-0x01", - "-0x2DFC9311D490018C7338BF8688861767FF8FF5B2BEBE27548A14B235ECA6874A", + "0x7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEC", + "0x52036CEE2B6FFE738CC740797779E89800700A4D4141D8AB75EB4DCA135978A3", "0x1000000000000000000000000000000014DEF9DEA2F79CD65812631A5CF5D3ED", "0x216936D3CD6E53FEC0A4E231FDD6DC5C692CC7609525A7B2C9562D608F25D51A", "0x6666666666666666666666666666666666666666666666666666666666666658", ----------------------------------------------------------------------- Summary of changes: cipher/ecc-curves.c | 12 ++++++++++-- cipher/ecc-eddsa.c | 6 +++--- cipher/ecc.c | 5 +---- mpi/ec.c | 21 ++++++--------------- tests/t-mpi-point.c | 4 ++-- 5 files changed, 22 insertions(+), 26 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 wk at gnupg.org Wed Apr 6 15:37:26 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 06 Apr 2016 15:37:26 +0200 Subject: Positive value for ECC In-Reply-To: <5704CDD1.6020309@fsij.org> (NIIBE Yutaka's message of "Wed, 06 Apr 2016 17:50:25 +0900") References: <56679C01.8040300@fsij.org> <57032723.9080205@fsij.org> <8737r0175m.fsf@wheatstone.g10code.de> <5704CDD1.6020309@fsij.org> Message-ID: <874mbeyi21.fsf@wheatstone.g10code.de> On Wed, 6 Apr 2016 10:50, gniibe at fsij.org said: > Note that I keep the values in domain_parms, so that computation of > keygrip will not be changed. Good - tests/keygrip should have detected it otherwise. > No noticeable difference, so far. Okay. I would then suggest to comment out the getenv ("GCRYPT_BARETT"; iirc. I added it only for testing. The chnages is anyway good. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Apr 6 15:59:39 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 06 Apr 2016 15:59:39 +0200 Subject: dladdr() in fips.c and --enable-hmac-binary-check and --enable-static In-Reply-To: <201603180109.u2I19Pxt017884@d03av05.boulder.ibm.com> (Burt Silverman's message of "Thu, 17 Mar 2016 20:09:39 -0500") References: <201603180109.u2I19Pxt017884@d03av05.boulder.ibm.com> Message-ID: <87zit6x2gk.fsf@wheatstone.g10code.de> On Fri, 18 Mar 2016 02:09, burts at us.ibm.com said: > One of our team members decided that he needed to create a program binary > using static libraries, and he also decided to use the > --enable-hmac-binary-check option. This combination of configure options > will not work, because it exposes the dladdr() function call, and the That option works only with glibc and shared objects - it was required by a FIPS validated systems. It is not portable. I will add a source comment to configure.ac to explain this. > Can you eliminate the use of dladdr(), or come up with something that is > less likely to trip up a novice? Perhaps it is ridiculous for him to be Do not use features which are not described in README or in the manual ;-) Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From burts at us.ibm.com Wed Apr 6 16:33:02 2016 From: burts at us.ibm.com (Burt Silverman) Date: Wed, 6 Apr 2016 10:33:02 -0400 Subject: dladdr() in fips.c and --enable-hmac-binary-check and --enable-static In-Reply-To: <87zit6x2gk.fsf@wheatstone.g10code.de> References: <201603180109.u2I19Pxt017884@d03av05.boulder.ibm.com> <87zit6x2gk.fsf@wheatstone.g10code.de> Message-ID: <201604061433.u36EX6Eu007826@d03av05.boulder.ibm.com> Thank you very much, Werner. As an aside, I noticed afterwards that even with shared objects, one cannot do a complete build of the entire package with --enable-hmac-binary-check as src/Makefile.am does not mention variable DL_LIBS (in variables xxx_LDADD); needed for mpicalc.c, and presumably also needed for any other binaries built with libgcrypt. From: Werner Koch To: Burt Silverman/Raleigh/Contr/IBM at IBMUS Cc: gcrypt-devel at gnupg.org Date: 04/06/2016 10:00 AM Subject: Re: dladdr() in fips.c and --enable-hmac-binary-check and --enable-static On Fri, 18 Mar 2016 02:09, burts at us.ibm.com said: > One of our team members decided that he needed to create a program binary > using static libraries, and he also decided to use the > --enable-hmac-binary-check option. This combination of configure options > will not work, because it exposes the dladdr() function call, and the That option works only with glibc and shared objects - it was required by a FIPS validated systems. It is not portable. I will add a source comment to configure.ac to explain this. > Can you eliminate the use of dladdr(), or come up with something that is > less likely to trip up a novice? Perhaps it is ridiculous for him to be Do not use features which are not described in README or in the manual ;-) Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From wk at gnupg.org Wed Apr 6 17:06:49 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 06 Apr 2016 17:06:49 +0200 Subject: dladdr() in fips.c and --enable-hmac-binary-check and --enable-static In-Reply-To: <201604061433.u36EX6Eu007826@d03av05.boulder.ibm.com> (Burt Silverman's message of "Wed, 6 Apr 2016 10:33:02 -0400") References: <201603180109.u2I19Pxt017884@d03av05.boulder.ibm.com> <87zit6x2gk.fsf@wheatstone.g10code.de> <201604061433.u36EX6Eu007826@d03av05.boulder.ibm.com> Message-ID: <87shyywzcm.fsf@wheatstone.g10code.de> On Wed, 6 Apr 2016 16:33, burts at us.ibm.com said: > with --enable-hmac-binary-check as src/Makefile.am does not mention > variable DL_LIBS (in variables xxx_LDADD); needed for mpicalc.c, and > presumably also needed for any other binaries built with libgcrypt. With glibc on Linux/i386 this should not be needed. At least back then when I implemented it. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Apr 6 17:45:32 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 06 Apr 2016 17:45:32 +0200 Subject: Are we ready for 1.7 ? Message-ID: <87inzuwxk3.fsf@wheatstone.g10code.de> Hi! I see no more important bugs in the tracker and thus I would like to go forward and release 1.7. Okay? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From drew at drewb.ug Wed Apr 6 17:59:07 2016 From: drew at drewb.ug (Drew Carey Buglione) Date: Wed, 06 Apr 2016 08:59:07 -0700 Subject: Are we ready for 1.7 ? In-Reply-To: <87inzuwxk3.fsf@wheatstone.g10code.de> References: <87inzuwxk3.fsf@wheatstone.g10code.de> Message-ID: Will 1.7 include support for secp256k1 keys by default? On 2016-04-06 08:45, Werner Koch wrote: > Hi! > > I see no more important bugs in the tracker and thus I would like to go > forward and release 1.7. Okay? > > Salam-Shalom, > > Werner -------------- next part -------------- An HTML attachment was scrubbed... URL: From ametzler at bebt.de Wed Apr 6 19:26:09 2016 From: ametzler at bebt.de (Andreas Metzler) Date: Wed, 6 Apr 2016 19:26:09 +0200 Subject: git server down? Message-ID: Hello, Pulling from git currently fails for me: ametzler at moszumanska:/tmp$ git clone git://git.gnupg.org/libgcrypt.git Klone nach 'libgcrypt'... fatal: read error: Connection reset by peer Is the server down? cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From cvs at cvs.gnupg.org Wed Apr 6 20:19:15 2016 From: cvs at cvs.gnupg.org (by Werner Koch) Date: Wed, 06 Apr 2016 20:19:15 +0200 Subject: [git] GCRYPT - branch, master, updated. libgcrypt-1.6.0-373-g65c6314 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 65c63144b66392f40b991684789b8b793248e3ba (commit) from 6f386ceae86a058e26294f744750f1ed2a95e604 (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 65c63144b66392f40b991684789b8b793248e3ba Author: Werner Koch Date: Wed Apr 6 20:16:19 2016 +0200 Allow building with configure option --enable-hmac-binary-check. * src/Makefile.am (mpicalc_LDADD): Add DL_LIBS. * src/fips.c (check_binary_integrity): Allow use of hmac256 output. * src/hmac256.c (main): Add option --stdkey -- Note that when using that configure option "make check" won't work in one go. Instead use make cd src/.libs ../hmac256 --stdkey '' libgcrypt.so.20 >.libgcrypt.so.20.hmac cd ../.. make check Reported-by: Burt Silverman Signed-off-by: Werner Koch diff --git a/src/Makefile.am b/src/Makefile.am index aee2828..3cc4a55 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -131,7 +131,7 @@ dumpsexp_LDADD = $(arch_gpg_error_libs) mpicalc_SOURCES = mpicalc.c mpicalc_CFLAGS = $(GPG_ERROR_CFLAGS) -mpicalc_LDADD = libgcrypt.la $(GPG_ERROR_LIBS) +mpicalc_LDADD = libgcrypt.la $(DL_LIBS) $(GPG_ERROR_LIBS) hmac256_SOURCES = hmac256.c hmac256_CFLAGS = -DSTANDALONE $(arch_gpg_error_cflags) diff --git a/src/fips.c b/src/fips.c index 3311ba2..af3fe2c 100644 --- a/src/fips.c +++ b/src/fips.c @@ -637,11 +637,15 @@ check_binary_integrity (void) int n; /* The HMAC files consists of lowercase hex digits - only with an optional trailing linefeed. Fail if - there is any garbage. */ + with an optional trailing linefeed or optional + with two trailing spaces. The latter format + allows the use of the usual sha1sum format. Fail + if there is any garbage. */ err = gpg_error (GPG_ERR_SELFTEST_FAILED); n = fread (buffer, 1, sizeof buffer, fp); - if (n == 64 || (n == 65 && buffer[64] == '\n')) + if (n == 64 + || (n == 65 && buffer[64] == '\n') + || (n == 66 && buffer[64] == ' ' && buffer[65] == ' ')) { buffer[64] = 0; for (n=0, s= buffer; diff --git a/src/hmac256.c b/src/hmac256.c index 6b62ed3..ca1eb75 100644 --- a/src/hmac256.c +++ b/src/hmac256.c @@ -646,6 +646,7 @@ main (int argc, char **argv) size_t n, dlen, idx; int use_stdin = 0; int use_binary = 0; + int use_stdkey = 0; assert (sizeof (u32) == 4); #ifdef __WIN32 @@ -689,11 +690,16 @@ main (int argc, char **argv) argc--; argv++; use_binary = 1; } + else if (!strcmp (*argv, "--stdkey")) + { + argc--; argv++; + use_stdkey = 1; + } } if (argc < 1) { - fprintf (stderr, "usage: %s [--binary] key [filename]\n", pgm); + fprintf (stderr, "usage: %s [--binary] [--stdkey] key [filename]\n", pgm); exit (1); } @@ -702,7 +708,7 @@ main (int argc, char **argv) setmode (fileno (stdout), O_BINARY); #endif - key = *argv; + key = use_stdkey? "What am I, a doctor or a moonshuttle conductor?" : *argv; argc--, argv++; keylen = strlen (key); use_stdin = !argc; ----------------------------------------------------------------------- Summary of changes: src/Makefile.am | 2 +- src/fips.c | 10 +++++++--- src/hmac256.c | 10 ++++++++-- 3 files changed, 16 insertions(+), 6 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 wk at gnupg.org Wed Apr 6 20:22:54 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 06 Apr 2016 20:22:54 +0200 Subject: dladdr() in fips.c and --enable-hmac-binary-check and --enable-static In-Reply-To: <201604061433.u36EX5Q1017644@d03av03.boulder.ibm.com> (Burt Silverman's message of "Wed, 6 Apr 2016 10:33:02 -0400") References: <201603180109.u2I19Pxt017884@d03av05.boulder.ibm.com> <87zit6x2gk.fsf@wheatstone.g10code.de> <201604061433.u36EX5Q1017644@d03av03.boulder.ibm.com> Message-ID: <87lh4qvbpd.fsf@wheatstone.g10code.de> On Wed, 6 Apr 2016 16:33, burts at us.ibm.com said: > variable DL_LIBS (in variables xxx_LDADD); needed for mpicalc.c, and > presumably also needed for any other binaries built with libgcrypt. I just pushed this Patch: commit 65c63144b66392f40b991684789b8b793248e3ba Author: Werner Koch Date: Wed Apr 6 20:16:19 2016 +0200 Allow building with configure option --enable-hmac-binary-check. * src/Makefile.am (mpicalc_LDADD): Add DL_LIBS. * src/fips.c (check_binary_integrity): Allow use of hmac256 output. * src/hmac256.c (main): Add option --stdkey -- Note that when using that configure option "make check" won't work in one go. Instead use make cd src/.libs ../hmac256 --stdkey '' libgcrypt.so.20 >.libgcrypt.so.20.hmac cd ../.. make check Reported-by: Burt Silverman Signed-off-by: Werner Koch That should fix this problem and a bit more. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From jussi.kivilinna at iki.fi Wed Apr 6 22:05:29 2016 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Wed, 6 Apr 2016 23:05:29 +0300 Subject: Are we ready for 1.7 ? In-Reply-To: <87inzuwxk3.fsf@wheatstone.g10code.de> References: <87inzuwxk3.fsf@wheatstone.g10code.de> Message-ID: <57056C09.4090601@iki.fi> On 06.04.2016 18:45, Werner Koch wrote: > Hi! > > I see no more important bugs in the tracker and thus I would like to go > forward and release 1.7. Okay? > Ok for me. -Jussi > > Salam-Shalom, > > Werner > From wk at gnupg.org Thu Apr 7 08:50:38 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 07 Apr 2016 08:50:38 +0200 Subject: git server down? In-Reply-To: (Andreas Metzler's message of "Wed, 6 Apr 2016 19:26:09 +0200") References: Message-ID: <87a8l5vrnl.fsf@wheatstone.g10code.de> On Wed, 6 Apr 2016 19:26, ametzler at bebt.de said: > Is the server down? No, but was under DoS from a Chinese IP. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Apr 7 08:52:48 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 07 Apr 2016 08:52:48 +0200 Subject: Are we ready for 1.7 ? In-Reply-To: (Drew Carey Buglione's message of "Wed, 06 Apr 2016 08:59:07 -0700") References: <87inzuwxk3.fsf@wheatstone.g10code.de> Message-ID: <8760vtvrjz.fsf@wheatstone.g10code.de> On Wed, 6 Apr 2016 17:59, drew at drewb.ug said: > Will 1.7 include support for secp256k1 keys by default? Yep: $ tests/curves --verbose Ed25519 - 256 bits Curve25519 - 256 bits NIST P-192 - 192 bits NIST P-224 - 224 bits NIST P-256 - 256 bits NIST P-384 - 384 bits NIST P-521 - 521 bits brainpoolP160r1 - 160 bits brainpoolP192r1 - 192 bits brainpoolP224r1 - 224 bits brainpoolP256r1 - 256 bits brainpoolP320r1 - 320 bits brainpoolP384r1 - 384 bits brainpoolP512r1 - 512 bits GOST2001-test - 256 bits GOST2001-CryptoPro-A - 256 bits GOST2001-CryptoPro-B - 256 bits GOST2001-CryptoPro-C - 256 bits GOST2012-test - 511 bits GOST2012-tc26-A - 512 bits GOST2012-tc26-B - 512 bits secp256k1 - 256 bits Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Thu Apr 7 09:50:32 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 07 Apr 2016 16:50:32 +0900 Subject: Are we ready for 1.7 ? In-Reply-To: <87inzuwxk3.fsf@wheatstone.g10code.de> References: <87inzuwxk3.fsf@wheatstone.g10code.de> Message-ID: <57061148.5040700@fsij.org> On 04/07/2016 12:45 AM, Werner Koch wrote: > I see no more important bugs in the tracker and thus I would like to go > forward and release 1.7. Okay? I have an issue of Curve25519: https://lists.gnupg.org/pipermail/gcrypt-devel/2016-March/003734.html Let me consider this (today and tomorrow), I'll check other implementations. -- From normalperson at yhbt.net Thu Apr 7 10:10:49 2016 From: normalperson at yhbt.net (Eric Wong) Date: Thu, 7 Apr 2016 08:10:49 +0000 Subject: git server down? In-Reply-To: <87a8l5vrnl.fsf@wheatstone.g10code.de> References: <87a8l5vrnl.fsf@wheatstone.g10code.de> Message-ID: <20160407081049.GA3697@dcvr.yhbt.net> Werner Koch wrote: > On Wed, 6 Apr 2016 19:26, ametzler at bebt.de said: > > > Is the server down? > > No, but was under DoS from a Chinese IP. Any details of the DoS or how it was mitigated? (just blocking the IP?) Anyways, I've setup some mirrors of git.gcrypt.org repos which may be interesting to me[1] to fetch twice an hour: git://80x24.org/mirrors/gnupg/adns.git git://80x24.org/mirrors/gnupg/gnupg.git git://80x24.org/mirrors/gnupg/libassuan.git git://80x24.org/mirrors/gnupg/libgpg-error.git git://80x24.org/mirrors/gnupg/npth.git git://80x24.org/mirrors/gnupg/gnupg-doc.git git://80x24.org/mirrors/gnupg/gpgme.git git://80x24.org/mirrors/gnupg/libgcrypt.git git://80x24.org/mirrors/gnupg/libksba.git git://80x24.org/mirrors/gnupg/ntbtls.git Cloning over the dumb git protocol over http:// and https:// also works, and I hope to enable the smart git protocol soon (and also having an HTML git repository viewer which is friendly to terminal browsers :) I had a few minor ideas to mitigate resource consumption problems with git-daemon a while back based on my experience working on HTTP servers, but haven't gotten around to it: http://mid.gmane.org/20160129014106.GA8940 at dcvr.yhbt.net Obviously not an end-all-be-all. But I've been spending more time on git-related things this year and trying to improve the state of self-hosting. [1] honestly I've never looked at the code to these, I subscribed here a while back hoping to work on something using gcrypt, but I forget what :x From wk at gnupg.org Thu Apr 7 16:21:42 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 07 Apr 2016 16:21:42 +0200 Subject: git server down? In-Reply-To: <20160407081049.GA3697@dcvr.yhbt.net> (Eric Wong's message of "Thu, 7 Apr 2016 08:10:49 +0000") References: <87a8l5vrnl.fsf@wheatstone.g10code.de> <20160407081049.GA3697@dcvr.yhbt.net> Message-ID: <87h9fdsdmx.fsf@wheatstone.g10code.de> On Thu, 7 Apr 2016 10:10, normalperson at yhbt.net said: > Any details of the DoS or how it was mitigated? The machine got a bit small for the current high load. I doubt that this was intentional and instead assume it was some mirror which got stuck. Let's see whether stricter timeout values will help. > I had a few minor ideas to mitigate resource consumption > problems with git-daemon a while back based on my experience > working on HTTP servers, but haven't gotten around to it: > > http://mid.gmane.org/20160129014106.GA8940 at dcvr.yhbt.net I'll look at it. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From cvs at cvs.gnupg.org Thu Apr 7 17:24:33 2016 From: cvs at cvs.gnupg.org (by Werner Koch) Date: Thu, 07 Apr 2016 17:24:33 +0200 Subject: [git] GCRYPT - branch, master, updated. libgcrypt-1.6.0-374-g5e5d3b9 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 5e5d3b90e22a3caa6b48af3b5582d800a9fb73ad (commit) from 65c63144b66392f40b991684789b8b793248e3ba (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 5e5d3b90e22a3caa6b48af3b5582d800a9fb73ad Author: Werner Koch Date: Thu Apr 7 09:21:44 2016 +0200 Silence warning about missing HMAC-SHA3 selftests. -- We do not have a reliable source for test vectors. diff --git a/cipher/hmac-tests.c b/cipher/hmac-tests.c index 46e1b22..8c04708 100644 --- a/cipher/hmac-tests.c +++ b/cipher/hmac-tests.c @@ -707,8 +707,8 @@ run_selftests (int algo, int extended, selftest_report_func_t report) case GCRY_MD_SHA3_384: case GCRY_MD_SHA3_512: ec = 0; /* FIXME: Add selftests. */ -#ifdef __GNUC__ -# warning Please add the self text functions +#if defined(__GNUC__) && defined(IS_DEVELOPMENT_VERSION) +# warning Please add self test functions for HMAC-SHA3 #endif break; ----------------------------------------------------------------------- Summary of changes: cipher/hmac-tests.c | 4 ++-- 1 file changed, 2 insertions(+), 2 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 gniibe at fsij.org Fri Apr 8 04:34:00 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 08 Apr 2016 11:34:00 +0900 Subject: Are we ready for 1.7 ? In-Reply-To: <57061148.5040700@fsij.org> References: <87inzuwxk3.fsf@wheatstone.g10code.de> <57061148.5040700@fsij.org> Message-ID: <57071898.9070200@fsij.org> On 04/07/2016 04:50 PM, NIIBE Yutaka wrote: > I have an issue of Curve25519: > > https://lists.gnupg.org/pipermail/gcrypt-devel/2016-March/003734.html There are actually two issues: (1) API of libgcrypt If it validates input for X25519 or not (if gcry_mpi_ec_mul_point computes X25519 or not). (2) How we should handle the possible attack? Or is it considered to be an attack? For (1), I think that libgcrypt API should be modified. I'm going to describe this below. For (2), I think that it is GnuPG (the user of libgcrypt) which should check/validate the input. I'll post to gnupg-devel. > Let me consider this (today and tomorrow), I'll check other > implementations. I looked through libssh and nettle. IIUC, those use the API defined by NaCl, crypto_scalarmult and crypto_scalarmult_base. It is described in the page: http://nacl.cr.yp.to/scalarmult.html It computes "X25519" function defined in RFC 7748. That is, the tweak of scalar value is included in the computation. In RFC 7748, it is described as (in Python?): def decodeScalar25519(k): k_list = [ord(b) for b in k] k_list[0] &= 248 k_list[31] &= 127 k_list[31] |= 64 return decodeLittleEndian(k_list, 255) Currently, in libgcrypt, this tweak is done in key generation. This tweak of scalar value is not included in the computation of gcry_mpi_ec_mul_point itself. (I did implemented so, following the Ed25519 implementation in libgcrypt, which was done before X25519 implementation.) Even if our key generation does the tweak, I think that it is good to also include the tweak of scalar value in gcry_mpi_ec_mul_point, so that the routine will be compatible to crypto_scalarmult, for the sake of least surprise by programmers. Shall I proceed this way to modify gcry_mpi_ec_mul_point for Curve25519? -- From wk at gnupg.org Fri Apr 8 08:53:15 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 08 Apr 2016 08:53:15 +0200 Subject: Are we ready for 1.7 ? In-Reply-To: <57071898.9070200@fsij.org> (NIIBE Yutaka's message of "Fri, 08 Apr 2016 11:34:00 +0900") References: <87inzuwxk3.fsf@wheatstone.g10code.de> <57061148.5040700@fsij.org> <57071898.9070200@fsij.org> Message-ID: <87d1q0r3qc.fsf@wheatstone.g10code.de> On Fri, 8 Apr 2016 04:34, gniibe at fsij.org said: > For (2), I think that it is GnuPG (the user of libgcrypt) which should > check/validate the input. I'll post to gnupg-devel. Okay. > def decodeScalar25519(k): > k_list = [ord(b) for b in k] > k_list[0] &= 248 > k_list[31] &= 127 > k_list[31] |= 64 > return decodeLittleEndian(k_list, 255) > > Currently, in libgcrypt, this tweak is done in key generation. This > tweak of scalar value is not included in the computation of > gcry_mpi_ec_mul_point itself. (I did implemented so, following the I don't fully understand. gcry_mpi_ec_mul_point does not do any decoding at all. This should be done by _gcry_ecc_mont_decodepoint for Curve25519. > Even if our key generation does the tweak, I think that it is good to > also include the tweak of scalar value in gcry_mpi_ec_mul_point, so > that the routine will be compatible to crypto_scalarmult, for the sake > of least surprise by programmers. Our processing model is a but different so that a 1-1 relationship with other code is not necessary needed. But I may have not understand the issue. A patch may help me to understand it better. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Fri Apr 8 10:31:20 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 08 Apr 2016 17:31:20 +0900 Subject: Are we ready for 1.7 ? In-Reply-To: <87d1q0r3qc.fsf@wheatstone.g10code.de> References: <87inzuwxk3.fsf@wheatstone.g10code.de> <57061148.5040700@fsij.org> <57071898.9070200@fsij.org> <87d1q0r3qc.fsf@wheatstone.g10code.de> Message-ID: <57076C58.3080203@fsij.org> On 04/08/2016 03:53 PM, Werner Koch wrote: > I don't fully understand. gcry_mpi_ec_mul_point does not do any > decoding at all. This should be done by _gcry_ecc_mont_decodepoint for > Curve25519. Actually, I don't fully understand how to describe this correctly. In the previous mail, I refered the function decodeScalar25519 in RFC 7748. Note that this is for the scalar value. In RFC 7748, the tweak of bits is done when decoding octets to integer. Our _gcry_ecc_mont_decodepoint does computation which is described as decodeUCoordinate in RFC 7748. > Our processing model is a but different so that a 1-1 relationship with > other code is not necessary needed. But I may have not understand the > issue. A patch may help me to understand it better. Yes. Our processing model is a bit different. Currently, the caller of gcry_mpi_ec_mul needs handling of tweak. I encountered this issue when I wrote tests/t-cv25519.c. If we keep current API, the user would be confused. That's my concern. Here is a patch to show the possible change. It's not mature yet. diff --git a/cipher/ecc.c b/cipher/ecc.c index 759ca42..7ab7244 100644 --- a/cipher/ecc.c +++ b/cipher/ecc.c @@ -356,7 +356,7 @@ test_ecdh_only_keys (ECC_secret_key *sk, unsigned int nbits, int flags) _gcry_mpi_randomize (test, nbits, GCRY_WEAK_RANDOM); } - ec = _gcry_mpi_ec_p_internal_new (pk.E.model, pk.E.dialect, 0, + ec = _gcry_mpi_ec_p_internal_new (pk.E.model, pk.E.dialect, flags, pk.E.p, pk.E.a, pk.E.b); x0 = mpi_new (0); x1 = mpi_new (0); @@ -592,7 +592,7 @@ ecc_generate (const gcry_sexp_t genparms, gcry_sexp_t *r_skey) log_printpnt ("ecgen curve G", &E.G, NULL); } - ctx = _gcry_mpi_ec_p_internal_new (E.model, E.dialect, 0, E.p, E.a, E.b); + ctx = _gcry_mpi_ec_p_internal_new (E.model, E.dialect, flags, E.p, E.a, E.b); if (E.model == MPI_EC_MONTGOMERY) rc = nist_generate_key (&sk, &E, ctx, flags, nbits, &Qx, NULL); @@ -830,7 +830,7 @@ ecc_check_secret_key (gcry_sexp_t keyparms) goto leave; } - ec = _gcry_mpi_ec_p_internal_new (sk.E.model, sk.E.dialect, 0, + ec = _gcry_mpi_ec_p_internal_new (sk.E.model, sk.E.dialect, flags, sk.E.p, sk.E.a, sk.E.b); if (mpi_q) @@ -1349,7 +1349,7 @@ ecc_encrypt_raw (gcry_sexp_t *r_ciph, gcry_sexp_t s_data, gcry_sexp_t keyparms) } /* Compute the encrypted value. */ - ec = _gcry_mpi_ec_p_internal_new (pk.E.model, pk.E.dialect, 0, + ec = _gcry_mpi_ec_p_internal_new (pk.E.model, pk.E.dialect, flags, pk.E.p, pk.E.a, pk.E.b); /* Convert the public key. */ @@ -1570,7 +1570,7 @@ ecc_decrypt_raw (gcry_sexp_t *r_plain, gcry_sexp_t s_data, gcry_sexp_t keyparms) } - ec = _gcry_mpi_ec_p_internal_new (sk.E.model, sk.E.dialect, 0, + ec = _gcry_mpi_ec_p_internal_new (sk.E.model, sk.E.dialect, flags, sk.E.p, sk.E.a, sk.E.b); /* diff --git a/mpi/ec.c b/mpi/ec.c index 26dd947..b253f72 100644 --- a/mpi/ec.c +++ b/mpi/ec.c @@ -29,6 +29,7 @@ #include "context.h" #include "ec-context.h" #include "ec-internal.h" +#include "cipher.h" #define point_init(a) _gcry_mpi_point_init ((a)) @@ -1313,7 +1314,18 @@ _gcry_mpi_ec_mul_point (mpi_point_t result, Note that we don't use Y-coordinate in the points at all. RESULT->Y will be filled by zero. */ - nbits = mpi_get_nbits (scalar); + k = mpi_copy (scalar); + if ((ctx->flags & PUBKEY_FLAG_DJB_TWEAK)) + { + nbits = mpi_get_nbits (ctx->p); + mpi_set_bit (k, nbits - 1); + mpi_clear_bit (k, 2); + mpi_clear_bit (k, 1); + mpi_clear_bit (k, 0); + } + else + nbits = mpi_get_nbits (scalar); + point_init (&p1); point_init (&p2); point_init (&p1_); @@ -1337,7 +1349,7 @@ _gcry_mpi_ec_mul_point (mpi_point_t result, { mpi_point_t t; - sw = mpi_test_bit (scalar, j); + sw = mpi_test_bit (k, j); point_swap_cond (q1, q2, sw, ctx); montgomery_ladder (prd, sum, q1, q2, point->x, ctx); point_swap_cond (prd, sum, sw, ctx); @@ -1367,6 +1379,7 @@ _gcry_mpi_ec_mul_point (mpi_point_t result, point_free (&p2); point_free (&p1_); point_free (&p2_); + mpi_free (k); return; } diff --git a/tests/t-cv25519.c b/tests/t-cv25519.c index 69aa005..ee4b910 100644 --- a/tests/t-cv25519.c +++ b/tests/t-cv25519.c @@ -192,7 +192,6 @@ test_cv (int testno, const char *k_str, const char *u_str, gpg_error_t err; void *buffer = NULL; size_t buflen; - unsigned char *p; gcry_sexp_t s_sk = NULL; gcry_sexp_t s_data = NULL; gcry_sexp_t s_result = NULL; @@ -210,13 +209,6 @@ test_cv (int testno, const char *k_str, const char *u_str, goto leave; } - /* - * Do what decodeScalar25519 does. - */ - p = (unsigned char *)buffer; - p[0] &= 248; - p[31] &= 127; - p[31] |= 64; reverse_buffer (buffer, buflen); if ((err = gcry_sexp_build (&s_sk, NULL, @@ -319,14 +311,21 @@ test_it (int testno, const char *k_str, int iter, const char *result_str) gcry_mpi_t mpi_k = NULL; gcry_mpi_t mpi_x = NULL; gcry_mpi_point_t P = NULL; - gcry_mpi_point_t Q; + gcry_mpi_point_t Q = NULL; int i; - gcry_mpi_t mpi_kk = NULL; + gcry_sexp_t s_flags = NULL; if (verbose > 1) show ("Running test %d: iteration=%d\n", testno, iter); - gcry_mpi_ec_new (&ctx, NULL, "Curve25519"); + if ((err = gcry_sexp_build (&s_flags, NULL, "(flags djb-tweak)"))) + { + fail ("error building s-exp for test %d, %s: %s", + testno, "flags", gpg_strerror (err)); + goto leave; + } + + gcry_mpi_ec_new (&ctx, s_flags, "Curve25519"); Q = gcry_mpi_point_new (0); if (!(buffer = hex2buffer (k_str, &buflen)) || buflen != 32) @@ -357,14 +356,7 @@ test_it (int testno, const char *k_str, int iter, const char *result_str) /* * Another variant of decodeScalar25519 thing. */ - mpi_kk = gcry_mpi_set (mpi_kk, mpi_k); - gcry_mpi_set_bit (mpi_kk, 254); - gcry_mpi_clear_bit (mpi_kk, 255); - gcry_mpi_clear_bit (mpi_kk, 0); - gcry_mpi_clear_bit (mpi_kk, 1); - gcry_mpi_clear_bit (mpi_kk, 2); - - gcry_mpi_ec_mul (Q, mpi_kk, P, ctx); + gcry_mpi_ec_mul (Q, mpi_k, P, ctx); P = gcry_mpi_point_set (P, mpi_k, NULL, GCRYMPI_CONST_ONE); gcry_mpi_ec_get_affine (mpi_k, NULL, Q, ctx); @@ -401,7 +393,7 @@ test_it (int testno, const char *k_str, int iter, const char *result_str) } leave: - gcry_mpi_release (mpi_kk); + gcry_sexp_release (s_flags); gcry_mpi_release (mpi_k); gcry_mpi_point_release (P); gcry_mpi_release (mpi_x); -- From ian at cypherpunks.ca Fri Apr 8 14:28:37 2016 From: ian at cypherpunks.ca (Ian Goldberg) Date: Fri, 8 Apr 2016 08:28:37 -0400 Subject: Are we ready for 1.7 ? In-Reply-To: <57076C58.3080203@fsij.org> References: <87inzuwxk3.fsf@wheatstone.g10code.de> <57061148.5040700@fsij.org> <57071898.9070200@fsij.org> <87d1q0r3qc.fsf@wheatstone.g10code.de> <57076C58.3080203@fsij.org> Message-ID: <20160408122837.GX22016@yoink.cs.uwaterloo.ca> On Fri, Apr 08, 2016 at 05:31:20PM +0900, NIIBE Yutaka wrote: > @@ -1313,7 +1314,18 @@ _gcry_mpi_ec_mul_point (mpi_point_t result, > Note that we don't use Y-coordinate in the points at all. > RESULT->Y will be filled by zero. */ > > - nbits = mpi_get_nbits (scalar); > + k = mpi_copy (scalar); > + if ((ctx->flags & PUBKEY_FLAG_DJB_TWEAK)) > + { > + nbits = mpi_get_nbits (ctx->p); > + mpi_set_bit (k, nbits - 1); > + mpi_clear_bit (k, 2); > + mpi_clear_bit (k, 1); > + mpi_clear_bit (k, 0); > + } > + else > + nbits = mpi_get_nbits (scalar); > + > point_init (&p1); > point_init (&p2); > point_init (&p1_); Those bits you're setting and clearing are specific to the single curve Curve25519, but you appear to be performing those operations in a general function, so long as the flag PUBKEY_FLAG_DJB_TWEAK is set. You're positive no one will ever set that flag while using a different curve? Even past that, I disagree that "gcry_mpi_ec_mul_point" should be messing with the scalar that's passed in. If I say "multiply this point by 3", I don't want it to multiply by 2^254 instead. The setting and clearing should be done in key generation, not in the multiplication routine. - Ian From wk at gnupg.org Fri Apr 8 15:22:33 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 08 Apr 2016 15:22:33 +0200 Subject: Are we ready for 1.7 ? In-Reply-To: <57076C58.3080203@fsij.org> (NIIBE Yutaka's message of "Fri, 08 Apr 2016 17:31:20 +0900") References: <87inzuwxk3.fsf@wheatstone.g10code.de> <57061148.5040700@fsij.org> <57071898.9070200@fsij.org> <87d1q0r3qc.fsf@wheatstone.g10code.de> <57076C58.3080203@fsij.org> Message-ID: <878u0ome06.fsf@wheatstone.g10code.de> On Fri, 8 Apr 2016 10:31, gniibe at fsij.org said: > I encountered this issue when I wrote tests/t-cv25519.c. If we keep > current API, the user would be confused. That's my concern. Depends on what the user wants to do. > diff --git a/mpi/ec.c b/mpi/ec.c > index 26dd947..b253f72 100644 > --- a/mpi/ec.c > +++ b/mpi/ec.c > @@ -29,6 +29,7 @@ > #include "context.h" > #include "ec-context.h" > #include "ec-internal.h" > +#include "cipher.h" Including cipher.h is not good because it mixes the MPI computations with the cipher operations. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Mon Apr 11 11:35:05 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 11 Apr 2016 18:35:05 +0900 Subject: Are we ready for 1.7 ? In-Reply-To: <878u0ome06.fsf@wheatstone.g10code.de> References: <87inzuwxk3.fsf@wheatstone.g10code.de> <57061148.5040700@fsij.org> <57071898.9070200@fsij.org> <87d1q0r3qc.fsf@wheatstone.g10code.de> <57076C58.3080203@fsij.org> <878u0ome06.fsf@wheatstone.g10code.de> Message-ID: <570B6FC9.4020600@fsij.org> On 04/08/2016 10:22 PM, Werner Koch wrote: > On Fri, 8 Apr 2016 10:31, gniibe at fsij.org said: > >> I encountered this issue when I wrote tests/t-cv25519.c. If we keep >> current API, the user would be confused. That's my concern. > > Depends on what the user wants to do. Yes. I was confused because it was not clear where it does the tweak of bits. It had bugs and I wrote tests/t-cv25519.c without fixing bugs. > Including cipher.h is not good because it mixes the MPI computations > with the cipher operations. I see. It is because PUBKEY_FLAG_DJB_TWEAK is defined in cipher.h. Well, I should try different approach. Let me show the fix at first. Then, I'll modify tests/t-cv25519.c. Here is the possible fix. It is not a final version as it assumes PUBKEY_FLAG_DJB_TWEAK is only used for Curve25519; I will modify it with co-factor to be generic. * When calling gcry_mpi_ec_p_internal_new, flags should not be forgotten. * ecc_encrypt_raw should do the tweak of bits. * ecc_decrypt_raw should allow the result of O for Montgomery Curve with the flag PUBKEY_FLAG_DJB_TWEAK diff --git a/cipher/ecc.c b/cipher/ecc.c index 759ca42..8de75b6 100644 --- a/cipher/ecc.c +++ b/cipher/ecc.c @@ -356,7 +356,7 @@ test_ecdh_only_keys (ECC_secret_key *sk, unsigned int nbits, int flags) _gcry_mpi_randomize (test, nbits, GCRY_WEAK_RANDOM); } - ec = _gcry_mpi_ec_p_internal_new (pk.E.model, pk.E.dialect, 0, + ec = _gcry_mpi_ec_p_internal_new (pk.E.model, pk.E.dialect, flags, pk.E.p, pk.E.a, pk.E.b); x0 = mpi_new (0); x1 = mpi_new (0); @@ -592,7 +592,7 @@ ecc_generate (const gcry_sexp_t genparms, gcry_sexp_t *r_skey) log_printpnt ("ecgen curve G", &E.G, NULL); } - ctx = _gcry_mpi_ec_p_internal_new (E.model, E.dialect, 0, E.p, E.a, E.b); + ctx = _gcry_mpi_ec_p_internal_new (E.model, E.dialect, flags, E.p, E.a, E.b); if (E.model == MPI_EC_MONTGOMERY) rc = nist_generate_key (&sk, &E, ctx, flags, nbits, &Qx, NULL); @@ -830,7 +830,7 @@ ecc_check_secret_key (gcry_sexp_t keyparms) goto leave; } - ec = _gcry_mpi_ec_p_internal_new (sk.E.model, sk.E.dialect, 0, + ec = _gcry_mpi_ec_p_internal_new (sk.E.model, sk.E.dialect, flags, sk.E.p, sk.E.a, sk.E.b); if (mpi_q) @@ -1289,7 +1289,13 @@ ecc_encrypt_raw (gcry_sexp_t *r_ciph, gcry_sexp_t s_data, gcry_sexp_t keyparms) rc = GPG_ERR_INV_DATA; goto leave; } - + if ((flags & PUBKEY_FLAG_DJB_TWEAK)) + { + mpi_set_highbit (data, 254); + mpi_clear_bit (data, 0); + mpi_clear_bit (data, 1); + mpi_clear_bit (data, 2); + } /* * Extract the key. @@ -1349,7 +1355,7 @@ ecc_encrypt_raw (gcry_sexp_t *r_ciph, gcry_sexp_t s_data, gcry_sexp_t keyparms) } /* Compute the encrypted value. */ - ec = _gcry_mpi_ec_p_internal_new (pk.E.model, pk.E.dialect, 0, + ec = _gcry_mpi_ec_p_internal_new (pk.E.model, pk.E.dialect, flags, pk.E.p, pk.E.a, pk.E.b); /* Convert the public key. */ @@ -1570,7 +1576,7 @@ ecc_decrypt_raw (gcry_sexp_t *r_plain, gcry_sexp_t s_data, gcry_sexp_t keyparms) } - ec = _gcry_mpi_ec_p_internal_new (sk.E.model, sk.E.dialect, 0, + ec = _gcry_mpi_ec_p_internal_new (sk.E.model, sk.E.dialect, flags, sk.E.p, sk.E.a, sk.E.b); /* @@ -1607,7 +1613,8 @@ ecc_decrypt_raw (gcry_sexp_t *r_plain, gcry_sexp_t s_data, gcry_sexp_t keyparms) else y = mpi_new (0); - if (_gcry_mpi_ec_get_affine (x, y, &R, ec)) + if (_gcry_mpi_ec_get_affine (x, y, &R, ec) + && !(flags & PUBKEY_FLAG_DJB_TWEAK)) log_fatal ("ecdh: Failed to get affine coordinates\n"); if (y) -- From gniibe at fsij.org Mon Apr 11 11:40:04 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 11 Apr 2016 18:40:04 +0900 Subject: Are we ready for 1.7 ? In-Reply-To: <20160408122837.GX22016@yoink.cs.uwaterloo.ca> References: <87inzuwxk3.fsf@wheatstone.g10code.de> <57061148.5040700@fsij.org> <57071898.9070200@fsij.org> <87d1q0r3qc.fsf@wheatstone.g10code.de> <57076C58.3080203@fsij.org> <20160408122837.GX22016@yoink.cs.uwaterloo.ca> Message-ID: <570B70F4.20003@fsij.org> On 04/08/2016 09:28 PM, Ian Goldberg wrote: > On Fri, Apr 08, 2016 at 05:31:20PM +0900, NIIBE Yutaka wrote: >> @@ -1313,7 +1314,18 @@ _gcry_mpi_ec_mul_point (mpi_point_t result, >> Note that we don't use Y-coordinate in the points at all. >> RESULT->Y will be filled by zero. */ >> >> - nbits = mpi_get_nbits (scalar); >> + k = mpi_copy (scalar); >> + if ((ctx->flags & PUBKEY_FLAG_DJB_TWEAK)) >> + { >> + nbits = mpi_get_nbits (ctx->p); >> + mpi_set_bit (k, nbits - 1); >> + mpi_clear_bit (k, 2); >> + mpi_clear_bit (k, 1); >> + mpi_clear_bit (k, 0); >> + } >> + else >> + nbits = mpi_get_nbits (scalar); >> + >> point_init (&p1); >> point_init (&p2); >> point_init (&p1_); > > Those bits you're setting and clearing are specific to the single curve > Curve25519, but you appear to be performing those operations in a > general function, so long as the flag PUBKEY_FLAG_DJB_TWEAK is set. > You're positive no one will ever set that flag while using a different > curve? Thank you for review. Yes, I think the flag will be used for a different curve. I'll fix this in next version using co-factor. > Even past that, I disagree that "gcry_mpi_ec_mul_point" should be > messing with the scalar that's passed in. If I say "multiply this point > by 3", I don't want it to multiply by 2^254 instead. The setting and > clearing should be done in key generation, not in the multiplication > routine. Thank you again. This was my bad consideration for libgcrypt. Now, I think that it's bad idea to change gcry_mpi_ec_mul_point. Tweak of bits should be in key generation (including ephemeral key generation in ecc_encrypt_raw). -- From wk at gnupg.org Mon Apr 11 11:49:34 2016 From: wk at gnupg.org (Werner Koch) Date: Mon, 11 Apr 2016 11:49:34 +0200 Subject: Are we ready for 1.7 ? In-Reply-To: <570B6FC9.4020600@fsij.org> (NIIBE Yutaka's message of "Mon, 11 Apr 2016 18:35:05 +0900") References: <87inzuwxk3.fsf@wheatstone.g10code.de> <57061148.5040700@fsij.org> <57071898.9070200@fsij.org> <87d1q0r3qc.fsf@wheatstone.g10code.de> <57076C58.3080203@fsij.org> <878u0ome06.fsf@wheatstone.g10code.de> <570B6FC9.4020600@fsij.org> Message-ID: <87lh4kiifl.fsf@wheatstone.g10code.de> On Mon, 11 Apr 2016 11:35, gniibe at fsij.org said: > * When calling gcry_mpi_ec_p_internal_new, flags should not be forgotten. > * ecc_encrypt_raw should do the tweak of bits. > * ecc_decrypt_raw should allow the result of O for Montgomery Curve with > the flag PUBKEY_FLAG_DJB_TWEAK Fine with me. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From cvs at cvs.gnupg.org Tue Apr 12 03:12:08 2016 From: cvs at cvs.gnupg.org (by NIIBE Yutaka) Date: Tue, 12 Apr 2016 03:12:08 +0200 Subject: [git] GCRYPT - branch, master, updated. libgcrypt-1.6.0-376-gee7e1a0 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 ee7e1a0e835f8ffcfbcba2a44abab8632db8fed5 (commit) via 7fbdb99b8c56360adfd1fb4e7f4c95e0f8aa34de (commit) from 5e5d3b90e22a3caa6b48af3b5582d800a9fb73ad (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 ee7e1a0e835f8ffcfbcba2a44abab8632db8fed5 Author: NIIBE Yutaka Date: Tue Apr 12 09:58:12 2016 +0900 ecc: Fix X25519 computation on Curve25519. * cipher/ecc.c (ecc_encrypt_raw): Tweak of bits when PUBKEY_FLAG_DJB_TWEAK is enabled. (ecc_decrypt_raw): Return 0 when PUBKEY_FLAG_DJB_TWEAK is enabled. * tests/t-cv25519.c (test_cv): Update by using gcry_pk_encrypt. -- X25519 function is not a plain scalar multiplication, but does two things; the scalar bits are tweaked before applying scalar multiplication and X0 function is applied to the result of scalar multiplication. In libgcrypt, _gcry_mpi_ec_mul_point is a plain scalar multiplication and those two things are done in functions for ECDH with X25519. Signed-off-by: NIIBE Yutaka diff --git a/cipher/ecc.c b/cipher/ecc.c index 7ab7244..f6b2b69 100644 --- a/cipher/ecc.c +++ b/cipher/ecc.c @@ -1282,15 +1282,12 @@ ecc_encrypt_raw (gcry_sexp_t *r_ciph, gcry_sexp_t s_data, gcry_sexp_t keyparms) rc = _gcry_pk_util_data_to_mpi (s_data, &data, &ctx); if (rc) goto leave; - if (DBG_CIPHER) - log_mpidump ("ecc_encrypt data", data); if (mpi_is_opaque (data)) { rc = GPG_ERR_INV_DATA; goto leave; } - /* * Extract the key. */ @@ -1327,6 +1324,21 @@ ecc_encrypt_raw (gcry_sexp_t *r_ciph, gcry_sexp_t s_data, gcry_sexp_t keyparms) pk.E.dialect = ECC_DIALECT_STANDARD; } + /* + * Tweak the scalar bits by cofactor and number of bits of the field. + * It assumes the cofactor is a power of 2. + */ + if ((flags & PUBKEY_FLAG_DJB_TWEAK)) + { + int i; + + for (i = 0; i < mpi_get_nbits (pk.E.h) - 1; i++) + mpi_clear_bit (data, i); + mpi_set_highbit (data, mpi_get_nbits (pk.E.p) - 1); + } + if (DBG_CIPHER) + log_mpidump ("ecc_encrypt data", data); + if (DBG_CIPHER) { log_debug ("ecc_encrypt info: %s/%s\n", @@ -1607,7 +1619,13 @@ ecc_decrypt_raw (gcry_sexp_t *r_plain, gcry_sexp_t s_data, gcry_sexp_t keyparms) else y = mpi_new (0); - if (_gcry_mpi_ec_get_affine (x, y, &R, ec)) + /* + * Here, x is 0. In the X25519 computation on Curve25519, X0 + * function maps infinity to zero. So, when PUBKEY_FLAG_DJB_TWEAK + * is enabled, we can just skip the check to get the result of 0. + */ + if (_gcry_mpi_ec_get_affine (x, y, &R, ec) + && !(flags & PUBKEY_FLAG_DJB_TWEAK)) log_fatal ("ecdh: Failed to get affine coordinates\n"); if (y) diff --git a/tests/t-cv25519.c b/tests/t-cv25519.c index 69aa005..7e551c2 100644 --- a/tests/t-cv25519.c +++ b/tests/t-cv25519.c @@ -192,8 +192,8 @@ test_cv (int testno, const char *k_str, const char *u_str, gpg_error_t err; void *buffer = NULL; size_t buflen; - unsigned char *p; - gcry_sexp_t s_sk = NULL; + gcry_sexp_t s_pk = NULL; + gcry_mpi_t mpi_k = NULL; gcry_sexp_t s_data = NULL; gcry_sexp_t s_result = NULL; gcry_sexp_t s_tmp = NULL; @@ -210,29 +210,22 @@ test_cv (int testno, const char *k_str, const char *u_str, goto leave; } - /* - * Do what decodeScalar25519 does. - */ - p = (unsigned char *)buffer; - p[0] &= 248; - p[31] &= 127; - p[31] |= 64; reverse_buffer (buffer, buflen); + if ((err = gcry_mpi_scan (&mpi_k, GCRYMPI_FMT_USG, buffer, buflen, NULL))) + { + fail ("error converting MPI for test %d: %s", testno, gpg_strerror (err)); + goto leave; + } - if ((err = gcry_sexp_build (&s_sk, NULL, - "(private-key" - " (ecc" - " (curve \"Curve25519\")" - " (flags djb-tweak)" - " (d %b)))", (int)buflen, buffer))) + if ((err = gcry_sexp_build (&s_data, NULL, "%m", mpi_k))) { fail ("error building s-exp for test %d, %s: %s", - testno, "sk", gpg_strerror (err)); + testno, "data", gpg_strerror (err)); goto leave; } xfree (buffer); - if (!(buffer = hex2buffer (u_str, &buflen))) + if (!(buffer = hex2buffer (u_str, &buflen)) || buflen != 32) { fail ("error building s-exp for test %d, %s: %s", testno, "u", "invalid hex string"); @@ -247,26 +240,28 @@ test_cv (int testno, const char *k_str, const char *u_str, * We could add the prefix 0x40, but libgcrypt also supports * format with no prefix. So, it is OK not to put the prefix. */ - if ((err = gcry_sexp_build (&s_data, NULL, - "(enc-val" - " (ecdh" - " (e %b)))", (int)buflen, buffer))) + if ((err = gcry_sexp_build (&s_pk, NULL, + "(public-key" + " (ecc" + " (curve \"Curve25519\")" + " (flags djb-tweak)" + " (q%b)))", (int)buflen, buffer))) { fail ("error building s-exp for test %d, %s: %s", - testno, "data", gpg_strerror (err)); + testno, "pk", gpg_strerror (err)); goto leave; } xfree (buffer); buffer = NULL; - if ((err = gcry_pk_decrypt (&s_result, s_data, s_sk))) - fail ("gcry_pk_decrypt failed for test %d: %s", testno, + if ((err = gcry_pk_encrypt (&s_result, s_data, s_pk))) + fail ("gcry_pk_encrypt failed for test %d: %s", testno, gpg_strerror (err)); - s_tmp = gcry_sexp_find_token (s_result, "value", 0); + s_tmp = gcry_sexp_find_token (s_result, "s", 0); if (!s_tmp || !(res = gcry_sexp_nth_buffer (s_tmp, 1, &res_len))) - fail ("gcry_pk_decrypt failed for test %d: %s", testno, "missing value"); + fail ("gcry_pk_encrypt failed for test %d: %s", testno, "missing value"); else { char *r, *r0; @@ -275,16 +270,16 @@ test_cv (int testno, const char *k_str, const char *u_str, /* To skip the prefix 0x40, for-loop start with i=1 */ r0 = r = xmalloc (2*(res_len)+1); if (!r0) - { - fail ("memory allocation", testno); - goto leave; - } + { + fail ("memory allocation", testno); + goto leave; + } for (i=1; i < res_len; i++, r += 2) snprintf (r, 3, "%02x", res[i]); if (strcmp (result_str, r0)) { - fail ("gcry_pk_decrypt failed for test %d: %s", + fail ("gcry_pk_encrypt failed for test %d: %s", testno, "wrong value returned"); show (" expected: '%s'", result_str); show (" got: '%s'", r0); @@ -294,10 +289,11 @@ test_cv (int testno, const char *k_str, const char *u_str, leave: xfree (res); + gcry_mpi_release (mpi_k); gcry_sexp_release (s_tmp); gcry_sexp_release (s_result); gcry_sexp_release (s_data); - gcry_sexp_release (s_sk); + gcry_sexp_release (s_pk); xfree (buffer); } @@ -370,7 +366,7 @@ test_it (int testno, const char *k_str, int iter, const char *result_str) gcry_mpi_ec_get_affine (mpi_k, NULL, Q, ctx); if (debug) - print_mpi ("k", mpi_k); + print_mpi ("k", mpi_k); } { @@ -383,8 +379,8 @@ test_it (int testno, const char *k_str, int iter, const char *result_str) r0 = r = xmalloc (65); if (!r0) { - fail ("memory allocation", testno); - goto leave; + fail ("memory allocation", testno); + goto leave; } for (i=0; i < 32; i++, r += 2) @@ -395,7 +391,7 @@ test_it (int testno, const char *k_str, int iter, const char *result_str) fail ("curv25519 failed for test %d: %s", testno, "wrong value returned"); show (" expected: '%s'", result_str); - show (" got: '%s'", r0); + show (" got: '%s'", r0); } xfree (r0); } commit 7fbdb99b8c56360adfd1fb4e7f4c95e0f8aa34de Author: NIIBE Yutaka Date: Tue Apr 12 09:19:32 2016 +0900 ecc: Fix initialization of EC context. * cipher/ecc.c (test_ecdh_only_keys, ecc_generate) (ecc_check_secret_key, ecc_encrypt_raw, ecc_decrypt_raw): Initialize by _gcry_mpi_ec_p_internal_new should carry FLAGS. -- Signed-off-by: NIIBE Yutaka diff --git a/cipher/ecc.c b/cipher/ecc.c index 759ca42..7ab7244 100644 --- a/cipher/ecc.c +++ b/cipher/ecc.c @@ -356,7 +356,7 @@ test_ecdh_only_keys (ECC_secret_key *sk, unsigned int nbits, int flags) _gcry_mpi_randomize (test, nbits, GCRY_WEAK_RANDOM); } - ec = _gcry_mpi_ec_p_internal_new (pk.E.model, pk.E.dialect, 0, + ec = _gcry_mpi_ec_p_internal_new (pk.E.model, pk.E.dialect, flags, pk.E.p, pk.E.a, pk.E.b); x0 = mpi_new (0); x1 = mpi_new (0); @@ -592,7 +592,7 @@ ecc_generate (const gcry_sexp_t genparms, gcry_sexp_t *r_skey) log_printpnt ("ecgen curve G", &E.G, NULL); } - ctx = _gcry_mpi_ec_p_internal_new (E.model, E.dialect, 0, E.p, E.a, E.b); + ctx = _gcry_mpi_ec_p_internal_new (E.model, E.dialect, flags, E.p, E.a, E.b); if (E.model == MPI_EC_MONTGOMERY) rc = nist_generate_key (&sk, &E, ctx, flags, nbits, &Qx, NULL); @@ -830,7 +830,7 @@ ecc_check_secret_key (gcry_sexp_t keyparms) goto leave; } - ec = _gcry_mpi_ec_p_internal_new (sk.E.model, sk.E.dialect, 0, + ec = _gcry_mpi_ec_p_internal_new (sk.E.model, sk.E.dialect, flags, sk.E.p, sk.E.a, sk.E.b); if (mpi_q) @@ -1349,7 +1349,7 @@ ecc_encrypt_raw (gcry_sexp_t *r_ciph, gcry_sexp_t s_data, gcry_sexp_t keyparms) } /* Compute the encrypted value. */ - ec = _gcry_mpi_ec_p_internal_new (pk.E.model, pk.E.dialect, 0, + ec = _gcry_mpi_ec_p_internal_new (pk.E.model, pk.E.dialect, flags, pk.E.p, pk.E.a, pk.E.b); /* Convert the public key. */ @@ -1570,7 +1570,7 @@ ecc_decrypt_raw (gcry_sexp_t *r_plain, gcry_sexp_t s_data, gcry_sexp_t keyparms) } - ec = _gcry_mpi_ec_p_internal_new (sk.E.model, sk.E.dialect, 0, + ec = _gcry_mpi_ec_p_internal_new (sk.E.model, sk.E.dialect, flags, sk.E.p, sk.E.a, sk.E.b); /* ----------------------------------------------------------------------- Summary of changes: cipher/ecc.c | 36 +++++++++++++++++++++-------- tests/t-cv25519.c | 68 ++++++++++++++++++++++++++----------------------------- 2 files changed, 59 insertions(+), 45 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 gniibe at fsij.org Tue Apr 12 09:05:47 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 12 Apr 2016 16:05:47 +0900 Subject: more change on Curve25519 ECDH (was: [git] GCRYPT - branch, master, updated. libgcrypt-1.6.0-376-gee7e1a0) In-Reply-To: References: Message-ID: <570C9E4B.1060906@fsij.org> On 04/12/2016 10:12 AM, by NIIBE Yutaka wrote: > ecc: Fix X25519 computation on Curve25519. > > * cipher/ecc.c (ecc_encrypt_raw): Tweak of bits when > PUBKEY_FLAG_DJB_TWEAK is enabled. > (ecc_decrypt_raw): Return 0 when PUBKEY_FLAG_DJB_TWEAK is enabled. > * tests/t-cv25519.c (test_cv): Update by using gcry_pk_encrypt. > > -- > > X25519 function is not a plain scalar multiplication, but does > two things; the scalar bits are tweaked before applying scalar > multiplication and X0 function is applied to the result of > scalar multiplication. > > In libgcrypt, _gcry_mpi_ec_mul_point is a plain scalar multiplication > and those two things are done in functions for ECDH with X25519. I thought this was the final change of mine, but trying to fix GnuPG, I think that another patch is needed for libgcrypt. Here is the change. (1) For ecc_encrypt_raw, it won't abort but properly use X0 function to map infinity to 0 (2) In ecc_decrypt_raw, avoiding validation (to be X25519 compatible) is based on the flag not the name of the curve. (3) In ecc_decrypt_raw, since our major use case is GnuPG, we handle the case of infinity differently. While X25519 returns 0, libgcrypt returns an error. For (3), I don't implement this as input validation but as result handling. If we do input validation, the values are: 0x0000000000000000000000000000000000000000000000000000000000000000 0x0000000000000000000000000000000000000000000000000000000000000001 0x00b8495f16056286fdb1329ceb8d09da6ac49ff1fae35616aeb8413b7c7aebe0 0x57119fd0dd4e22d8868e1c58c45c44045bef839c55b1d0b1248c50a3bc959c5f 0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffec 0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffed 0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffee Those other values (which is listed in https://cr.yp.to/ecdh.html ) 0x80b8495f16056286fdb1329ceb8d09da6ac49ff1fae35616aeb8413b7c7aebcd 0xd7119fd0dd4e22d8868e1c58c45c44045bef839c55b1d0b1248c50a3bc959c4c 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffd9 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffda 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffdb are not possible by the definition of X25519 where the MSB is cleared. diff --git a/cipher/ecc.c b/cipher/ecc.c index f6b2b69..663f4a8 100644 --- a/cipher/ecc.c +++ b/cipher/ecc.c @@ -1394,7 +1394,13 @@ ecc_encrypt_raw (gcry_sexp_t *r_ciph, gcry_sexp_t s_data, gcry_sexp_t keyparms) /* R = kQ <=> R = kdG */ _gcry_mpi_ec_mul_point (&R, data, &pk.Q, ec); - if (_gcry_mpi_ec_get_affine (x, y, &R, ec)) + /* + * Here, X is 0. In the X25519 computation on Curve25519, X0 + * function maps infinity to zero. So, when PUBKEY_FLAG_DJB_TWEAK + * is enabled, skip the check to get the result of 0. + */ + if (_gcry_mpi_ec_get_affine (x, y, &R, ec) + && !(flags & PUBKEY_FLAG_DJB_TWEAK)) log_fatal ("ecdh: Failed to get affine coordinates for kdG\n"); if (y) mpi_s = _gcry_ecc_ec2os (x, y, pk.E.p); @@ -1598,8 +1604,8 @@ ecc_decrypt_raw (gcry_sexp_t *r_plain, gcry_sexp_t s_data, gcry_sexp_t keyparms) if (DBG_CIPHER) log_printpnt ("ecc_decrypt kG", &kG, NULL); - if (!(curvename && !strcmp (curvename, "Curve25519")) - /* For Curve25519, by its definition, validation should not be done. */ + if (!(flags & PUBKEY_FLAG_DJB_TWEAK) + /* For X25519, by its definition, validation should not be done. */ && !_gcry_mpi_ec_curve_point (&kG, ec)) { rc = GPG_ERR_INV_DATA; @@ -1619,14 +1625,35 @@ ecc_decrypt_raw (gcry_sexp_t *r_plain, gcry_sexp_t s_data, gcry_sexp_t keyparms) else y = mpi_new (0); - /* - * Here, x is 0. In the X25519 computation on Curve25519, X0 - * function maps infinity to zero. So, when PUBKEY_FLAG_DJB_TWEAK - * is enabled, we can just skip the check to get the result of 0. - */ - if (_gcry_mpi_ec_get_affine (x, y, &R, ec) - && !(flags & PUBKEY_FLAG_DJB_TWEAK)) - log_fatal ("ecdh: Failed to get affine coordinates\n"); + if (_gcry_mpi_ec_get_affine (x, y, &R, ec)) + { + if (!(flags & PUBKEY_FLAG_DJB_TWEAK)) + log_fatal ("ecdh: Failed to get affine coordinates\n"); + else + { + /* + * By the definition of X25519, this is the case where it + * returns 0, mapping infinity to zero. However, we + * deliberately let it return an error. + * + * Comming here means that it might be decrypted by anyone + * with the shared secret of 0 (the result of this + * function could be always 0 by other scalar values, + * other than the private key of SK.D). + * + * So, it looks like an encrypted message but it can be + * decrypted by anyone, or at least something wrong + * happens. Recipient should not proceed as if it were + * properly encrypted message. + * + * This handling is needed for our major usage of GnuPG, + * where it does the One-Pass Diffie-Hellman method, + * C(1, 1, ECC CDH), with an ephemeral key. + */ + rc = GPG_ERR_INV_DATA; + goto leave; + } + } if (y) r = _gcry_ecc_ec2os (x, y, sk.E.p); -- From cvs at cvs.gnupg.org Tue Apr 12 11:15:56 2016 From: cvs at cvs.gnupg.org (by Werner Koch) Date: Tue, 12 Apr 2016 11:15:56 +0200 Subject: [git] GCRYPT - branch, master, updated. libgcrypt-1.6.0-377-gb6d2a25 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 b6d2a25a275a35ec4dbd53ecaa9ea0ed7aa99c7b (commit) from ee7e1a0e835f8ffcfbcba2a44abab8632db8fed5 (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 b6d2a25a275a35ec4dbd53ecaa9ea0ed7aa99c7b Author: Werner Koch Date: Tue Apr 12 11:11:35 2016 +0200 cipher: Buffer data from gcry_cipher_authenticate in OCB mode. * cipher/cipher-internal.h (gcry_cipher_handle): Add fields aad_leftover and aad_nleftover to u_mode.ocb. * cipher/cipher-ocb.c (_gcry_cipher_ocb_set_nonce): Clear aad_nleftover. (_gcry_cipher_ocb_authenticate): Add buffering and facor some code out to ... (ocb_aad_finalize): new. (compute_tag_if_needed): Call new function. * tests/basic.c (check_ocb_cipher_splitaad): New. (check_ocb_cipher): Call new function. (main): Also call check_cipher_modes with --ciper-modes. -- It is more convenient to not require full blocks for gcry_cipher_authenticate. Other modes than OCB do this as well. Note that the size of the context structure is not increased because other modes require more context data. Signed-off-by: Werner Koch diff --git a/cipher/cipher-internal.h b/cipher/cipher-internal.h index 80e7c09..9fd1d91 100644 --- a/cipher/cipher-internal.h +++ b/cipher/cipher-internal.h @@ -274,10 +274,16 @@ struct gcry_cipher_handle checksum of the data. */ unsigned char aad_sum[OCB_BLOCK_LEN]; + /* A buffer to store AAD data not yet processed. */ + unsigned char aad_leftover[OCB_BLOCK_LEN]; + /* Number of data/aad blocks processed so far. */ u64 data_nblocks; u64 aad_nblocks; + /* Number of valid bytes in AAD_LEFTOVER. */ + unsigned char aad_nleftover; + /* Length of the tag. Fixed for now but may eventually be specified using a set of gcry_cipher_flags. */ unsigned char taglen; diff --git a/cipher/cipher-ocb.c b/cipher/cipher-ocb.c index 6db1db3..92260d2 100644 --- a/cipher/cipher-ocb.c +++ b/cipher/cipher-ocb.c @@ -1,5 +1,5 @@ /* cipher-ocb.c - OCB cipher mode - * Copyright (C) 2015 g10 Code GmbH + * Copyright (C) 2015, 2016 g10 Code GmbH * * This file is part of Libgcrypt. * @@ -211,6 +211,7 @@ _gcry_cipher_ocb_set_nonce (gcry_cipher_hd_t c, const unsigned char *nonce, c->marks.finalize = 0; c->u_mode.ocb.data_nblocks = 0; c->u_mode.ocb.aad_nblocks = 0; + c->u_mode.ocb.aad_nleftover = 0; c->u_mode.ocb.data_finalized = 0; c->u_mode.ocb.aad_finalized = 0; @@ -235,10 +236,7 @@ _gcry_cipher_ocb_set_nonce (gcry_cipher_hd_t c, const unsigned char *nonce, /* Process additional authentication data. This implementation allows to add additional authentication data at any time before the final - gcry_cipher_gettag. The size of the data provided in - (ABUF,ABUFLEN) must be a multiple of the blocksize. If a - non-multiple of the blocksize is used no further data may be passed - to this function. */ + gcry_cipher_gettag. */ gcry_err_code_t _gcry_cipher_ocb_authenticate (gcry_cipher_hd_t c, const unsigned char *abuf, size_t abuflen) @@ -254,6 +252,32 @@ _gcry_cipher_ocb_authenticate (gcry_cipher_hd_t c, const unsigned char *abuf, /* Check correct usage and arguments. */ if (c->spec->blocksize != OCB_BLOCK_LEN) return GPG_ERR_CIPHER_ALGO; + + /* Process remaining data from the last call first. */ + if (c->u_mode.ocb.aad_nleftover) + { + for (; abuflen && c->u_mode.ocb.aad_nleftover < OCB_BLOCK_LEN; + abuf++, abuflen--) + c->u_mode.ocb.aad_leftover[c->u_mode.ocb.aad_nleftover++] = *abuf; + + if (c->u_mode.ocb.aad_nleftover == OCB_BLOCK_LEN) + { + c->u_mode.ocb.aad_nblocks++; + + /* Offset_i = Offset_{i-1} xor L_{ntz(i)} */ + buf_xor_1 (c->u_mode.ocb.aad_offset, + ocb_get_l (c, l_tmp, c->u_mode.ocb.aad_nblocks), + OCB_BLOCK_LEN); + /* Sum_i = Sum_{i-1} xor ENCIPHER(K, A_i xor Offset_i) */ + buf_xor (l_tmp, c->u_mode.ocb.aad_offset, + c->u_mode.ocb.aad_leftover, OCB_BLOCK_LEN); + c->spec->encrypt (&c->context.c, l_tmp, l_tmp); + buf_xor_1 (c->u_mode.ocb.aad_sum, l_tmp, OCB_BLOCK_LEN); + + c->u_mode.ocb.aad_nleftover = 0; + } + } + if (!abuflen) return 0; @@ -291,31 +315,56 @@ _gcry_cipher_ocb_authenticate (gcry_cipher_hd_t c, const unsigned char *abuf, abuflen -= OCB_BLOCK_LEN; } - /* Hash final partial block. Note that we expect ABUFLEN to be - shorter than OCB_BLOCK_LEN. */ - if (abuflen) + /* Store away the remaining data. */ + for (; abuflen && c->u_mode.ocb.aad_nleftover < OCB_BLOCK_LEN; + abuf++, abuflen--) + c->u_mode.ocb.aad_leftover[c->u_mode.ocb.aad_nleftover++] = *abuf; + gcry_assert (!abuflen); + + return 0; +} + + +/* Hash final partial AAD block. */ +static void +ocb_aad_finalize (gcry_cipher_hd_t c) +{ + unsigned char l_tmp[OCB_BLOCK_LEN]; + + /* Check that a nonce and thus a key has been set and that we have + not yet computed the tag. We also skip this if the aad has been + finalized. */ + if (!c->marks.iv || c->marks.tag || c->u_mode.ocb.aad_finalized) + return; + if (c->spec->blocksize != OCB_BLOCK_LEN) + return; /* Ooops. */ + + /* Hash final partial block if any. */ + if (c->u_mode.ocb.aad_nleftover) { /* Offset_* = Offset_m xor L_* */ buf_xor_1 (c->u_mode.ocb.aad_offset, c->u_mode.ocb.L_star, OCB_BLOCK_LEN); /* CipherInput = (A_* || 1 || zeros(127-bitlen(A_*))) xor Offset_* */ - buf_cpy (l_tmp, abuf, abuflen); - memset (l_tmp + abuflen, 0, OCB_BLOCK_LEN - abuflen); - l_tmp[abuflen] = 0x80; + buf_cpy (l_tmp, c->u_mode.ocb.aad_leftover, c->u_mode.ocb.aad_nleftover); + memset (l_tmp + c->u_mode.ocb.aad_nleftover, 0, + OCB_BLOCK_LEN - c->u_mode.ocb.aad_nleftover); + l_tmp[c->u_mode.ocb.aad_nleftover] = 0x80; buf_xor_1 (l_tmp, c->u_mode.ocb.aad_offset, OCB_BLOCK_LEN); /* Sum = Sum_m xor ENCIPHER(K, CipherInput) */ c->spec->encrypt (&c->context.c, l_tmp, l_tmp); buf_xor_1 (c->u_mode.ocb.aad_sum, l_tmp, OCB_BLOCK_LEN); - /* Mark AAD as finalized to avoid accidentally calling this - function again after a non-full block has been processed. */ - c->u_mode.ocb.aad_finalized = 1; + c->u_mode.ocb.aad_nleftover = 0; } - return 0; + /* Mark AAD as finalized so that gcry_cipher_ocb_authenticate can + * return an erro when called again. */ + c->u_mode.ocb.aad_finalized = 1; } + /* Checksumming for encrypt and decrypt. */ static void ocb_checksum (unsigned char *chksum, const unsigned char *plainbuf, @@ -507,6 +556,7 @@ compute_tag_if_needed (gcry_cipher_hd_t c) { if (!c->marks.tag) { + ocb_aad_finalize (c); buf_xor_1 (c->u_mode.ocb.tag, c->u_mode.ocb.aad_sum, OCB_BLOCK_LEN); c->marks.tag = 1; } diff --git a/doc/gcrypt.texi b/doc/gcrypt.texi index c710765..a78c5fd 100644 --- a/doc/gcrypt.texi +++ b/doc/gcrypt.texi @@ -1883,7 +1883,7 @@ the end of the input data. This is done with: Set a flag in the context to tell the encrypt and decrypt functions that their next call will provide the last chunk of data. Only the first call to this function has an effect and only for modes which -support it. Checking the error in in general not necessary. This is +support it. Checking the error is in general not necessary. This is implemented as a macro. @end deftypefun diff --git a/src/gcrypt.h.in b/src/gcrypt.h.in index c269621..bd25d1b 100644 --- a/src/gcrypt.h.in +++ b/src/gcrypt.h.in @@ -1065,7 +1065,7 @@ gcry_error_t gcry_cipher_checktag (gcry_cipher_hd_t hd, const void *intag, (oid), 0); /* Indicate to the encrypt and decrypt functions that the next call - provides the final data. Only used with some modes. e */ + provides the final data. Only used with some modes. */ #define gcry_cipher_final(a) \ gcry_cipher_ctl ((a), GCRYCTL_FINALIZE, NULL, 0) diff --git a/tests/basic.c b/tests/basic.c index 1a7d3cb..4940f6a 100644 --- a/tests/basic.c +++ b/tests/basic.c @@ -3596,6 +3596,236 @@ check_ocb_cipher_largebuf (int algo, int keylen, const char *tagexpect) static void +check_ocb_cipher_splitaad (void) +{ + const char t_nonce[] = ("BBAA9988776655443322110D"); + const char t_plain[] = ("000102030405060708090A0B0C0D0E0F1011121314151617" + "18191A1B1C1D1E1F2021222324252627"); + const char t_ciph[] = ("D5CA91748410C1751FF8A2F618255B68A0A12E093FF45460" + "6E59F9C1D0DDC54B65E8628E568BAD7AED07BA06A4A69483" + "A7035490C5769E60"); + struct { + const char *aad0; + const char *aad1; + const char *aad2; + const char *aad3; + } tv[] = { + { + "000102030405060708090A0B0C0D0E0F" + "101112131415161718191A1B1C1D1E1F2021222324252627" + }, + { + "000102030405060708090A0B0C0D0E0F", + "101112131415161718191A1B1C1D1E1F", + "2021222324252627" + }, + { + "000102030405060708090A0B0C0D0E0F", + "1011121314151617", + "18191A1B1C1D1E1F", + "2021222324252627" + }, + { + "000102030405060708090A0B0C0D0E0F", + "101112131415161718191A1B1C1D1E1F", + "20", + "21222324252627" + }, + { + "000102030405060708090A0B0C0D0E0F", + "101112131415161718191A1B1C1D1E1F", + "2021", + "222324252627" + }, + { + "000102030405060708090A0B0C0D0E0F", + "101112131415161718191A1B1C1D1E1F", + "202122", + "2324252627" + }, + { + "000102030405060708090A0B0C0D0E0F", + "101112131415161718191A1B1C1D1E1F", + "20212223", + "24252627" + }, + { + "000102030405060708090A0B0C0D0E0F", + "101112131415161718191A1B1C1D1E1F", + "2021222324", + "252627" + }, + { + "000102030405060708090A0B0C0D0E0F", + "101112131415161718191A1B1C1D1E1F", + "202122232425", + "2627" + }, + { + "000102030405060708090A0B0C0D0E0F", + "101112131415161718191A1B1C1D1E1F", + "20212223242526" + "27" + }, + { + "000102030405060708090A0B0C0D0E0F", + "1011121314151617", + "18191A1B1C1D1E1F2021222324252627" + }, + { + "00", + "0102030405060708090A0B0C0D0E0F", + "1011121314151617", + "18191A1B1C1D1E1F2021222324252627" + }, + { + "0001", + "02030405060708090A0B0C0D0E0F", + "1011121314151617", + "18191A1B1C1D1E1F2021222324252627" + }, + { + "000102030405060708090A0B0C0D", + "0E0F", + "1011121314151617", + "18191A1B1C1D1E1F2021222324252627" + }, + { + "000102030405060708090A0B0C0D0E", + "0F", + "1011121314151617", + "18191A1B1C1D1E1F2021222324252627" + }, + { + "000102030405060708090A0B0C0D0E", + "0F101112131415161718191A1B1C1D1E1F20212223242526", + "27" + } + }; + + gpg_error_t err = 0; + gcry_cipher_hd_t hde; + unsigned char out[MAX_DATA_LEN]; + unsigned char tag[16]; + int tidx; + char *key, *nonce, *ciph, *plain; + size_t keylen, noncelen, ciphlen, plainlen; + int i; + + /* Convert to hex strings to binary. */ + key = hex2buffer ("000102030405060708090A0B0C0D0E0F", &keylen); + nonce = hex2buffer (t_nonce, &noncelen); + plain = hex2buffer (t_plain, &plainlen); + ciph = hex2buffer (t_ciph, &ciphlen); + + /* Check that our test vectors are sane. */ + assert (plainlen <= sizeof out); + assert (16 <= ciphlen); + assert (16 <= sizeof tag); + + for (tidx = 0; tidx < DIM (tv); tidx++) + { + char *aad[4]; + size_t aadlen[4]; + + if (verbose) + fprintf (stderr, " checking OCB aad split (tv %d)\n", tidx); + + aad[0] = tv[tidx].aad0? hex2buffer (tv[tidx].aad0, aadlen+0) : NULL; + aad[1] = tv[tidx].aad1? hex2buffer (tv[tidx].aad1, aadlen+1) : NULL; + aad[2] = tv[tidx].aad2? hex2buffer (tv[tidx].aad2, aadlen+2) : NULL; + aad[3] = tv[tidx].aad3? hex2buffer (tv[tidx].aad3, aadlen+3) : NULL; + + err = gcry_cipher_open (&hde, GCRY_CIPHER_AES, GCRY_CIPHER_MODE_OCB, 0); + if (err) + { + fail ("cipher-ocb-splitadd, gcry_cipher_open failed: %s\n", + gpg_strerror (err)); + return; + } + + err = gcry_cipher_setkey (hde, key, keylen); + if (err) + { + fail ("cipher-ocb-splitaad, gcry_cipher_setkey failed: %s\n", + gpg_strerror (err)); + gcry_cipher_close (hde); + return; + } + + err = gcry_cipher_setiv (hde, nonce, noncelen); + if (err) + { + fail ("cipher-ocb-splitaad, gcry_cipher_setiv failed: %s\n", + gpg_strerror (err)); + gcry_cipher_close (hde); + return; + } + + for (i=0; i < DIM (aad); i++) + { + if (!aad[i]) + continue; + err = gcry_cipher_authenticate (hde, aad[i], aadlen[i]); + if (err) + { + fail ("cipher-ocb-splitaad," + " gcry_cipher_authenticate failed (tv=%d,i=%d): %s\n", + tidx, i, gpg_strerror (err)); + gcry_cipher_close (hde); + return; + } + } + + err = gcry_cipher_final (hde); + if (!err) + err = gcry_cipher_encrypt (hde, out, MAX_DATA_LEN, plain, plainlen); + if (err) + { + fail ("cipher-ocb-splitaad, gcry_cipher_encrypt failed: %s\n", + gpg_strerror (err)); + gcry_cipher_close (hde); + return; + } + + /* Check that the encrypt output matches the expected cipher + text without the tag (i.e. at the length of plaintext). */ + if (memcmp (ciph, out, plainlen)) + { + mismatch (ciph, plainlen, out, plainlen); + fail ("cipher-ocb-splitaad, encrypt data mismatch\n"); + } + + /* Check that the tag matches TAGLEN bytes from the end of the + expected ciphertext. */ + err = gcry_cipher_gettag (hde, tag, 16); + if (err) + { + fail ("cipher-ocb-splitaad, gcry_cipher_gettag failed: %s\n", + gpg_strerror (err)); + } + if (memcmp (ciph + ciphlen - 16, tag, 16)) + { + mismatch (ciph + ciphlen - 16, 16, tag, 16); + fail ("cipher-ocb-splitaad, encrypt tag mismatch\n"); + } + + + gcry_cipher_close (hde); + xfree (aad[0]); + xfree (aad[1]); + xfree (aad[2]); + xfree (aad[3]); + } + + xfree (nonce); + xfree (ciph); + xfree (plain); + xfree (key); +} + + +static void check_ocb_cipher (void) { /* Check OCB cipher with separate destination and source buffers for @@ -3636,6 +3866,9 @@ check_ocb_cipher (void) check_ocb_cipher_largebuf(GCRY_CIPHER_SERPENT256, 32, "\xe7\x8b\xe6\xd4\x2f\x7a\x36\x4c" "\xba\xee\x20\xe2\x68\xf4\xcb\xcc"); + + /* Check that the AAD data is correctly buffered. */ + check_ocb_cipher_splitaad (); } @@ -9128,7 +9361,10 @@ main (int argc, char **argv) if (pubkey_only) check_pubkey (); else if (cipher_modes_only) - check_ciphers (); + { + check_ciphers (); + check_cipher_modes (); + } else if (!selftest_only) { check_ciphers (); ----------------------------------------------------------------------- Summary of changes: cipher/cipher-internal.h | 6 ++ cipher/cipher-ocb.c | 80 +++++++++++++--- doc/gcrypt.texi | 2 +- src/gcrypt.h.in | 2 +- tests/basic.c | 238 ++++++++++++++++++++++++++++++++++++++++++++++- 5 files changed, 310 insertions(+), 18 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 wk at gnupg.org Tue Apr 12 18:26:25 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 12 Apr 2016 18:26:25 +0200 Subject: more change on Curve25519 ECDH In-Reply-To: <570C9E4B.1060906@fsij.org> (NIIBE Yutaka's message of "Tue, 12 Apr 2016 16:05:47 +0900") References: <570C9E4B.1060906@fsij.org> Message-ID: <878u0ihjym.fsf@wheatstone.g10code.de> On Tue, 12 Apr 2016 09:05, gniibe at fsij.org said: > (1) For ecc_encrypt_raw, it won't abort but properly use X0 function > to map infinity to 0 > > (2) In ecc_decrypt_raw, avoiding validation (to be X25519 compatible) is > based on the flag not the name of the curve. > > (3) In ecc_decrypt_raw, since our major use case is GnuPG, we handle > the case of infinity differently. While X25519 returns 0, > libgcrypt returns an error. Okay. > @@ -1394,7 +1394,13 @@ ecc_encrypt_raw (gcry_sexp_t *r_ciph, gcry_sexp_t > + if (_gcry_mpi_ec_get_affine (x, y, &R, ec) > + && !(flags & PUBKEY_FLAG_DJB_TWEAK)) > log_fatal ("ecdh: Failed to get affine coordinates for kdG\n"); Instead of calling log_fatal, which terminates the process, we would better return an error. > @@ -1598,8 +1604,8 @@ ecc_decrypt_raw (gcry_sexp_t *r_plain, gcry_sexp_t > + if (_gcry_mpi_ec_get_affine (x, y, &R, ec)) > + { > + if (!(flags & PUBKEY_FLAG_DJB_TWEAK)) > + log_fatal ("ecdh: Failed to get affine coordinates\n"); Ditto. What do you think of such a change? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Wed Apr 13 02:46:17 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 13 Apr 2016 09:46:17 +0900 Subject: more change on Curve25519 ECDH In-Reply-To: <878u0ihjym.fsf@wheatstone.g10code.de> References: <570C9E4B.1060906@fsij.org> <878u0ihjym.fsf@wheatstone.g10code.de> Message-ID: <570D96D9.1090707@fsij.org> Hello, Thanks a lot for your reply. My brain was almost overheated by considering the corner cases. I realize that E-mail interactions cool downs my brain effectively, because... perhaps, English is the second language (or it's not math or programming language, either) for me. I understand that NaCl API is clever. While its name is "crypto_scalarmult" and I had an impression as if it were scalar multiplication for a point on the curve, actually, it allows inputs not on the curve and it does applying X0 function and tweaking bits under the hood. In our case of libgcrypt, we keep the function _gcry_mpi_ec_mul_point as scalar multiplication for a point. We extend ECDH to allow input not on the curve for X25519. In libgcrypt, the flag of PUBKEY_FLAG_DJB_TWEAK is explicit to ask applying X0 function and tweaking bits. And we check the result of ECDH function of ecc_decrypt_raw. Those are small differences, but that's important. Well, it is important for me to learn these things. :-) On 04/13/2016 01:26 AM, Werner Koch wrote: >> @@ -1394,7 +1394,13 @@ ecc_encrypt_raw (gcry_sexp_t *r_ciph, gcry_sexp_t > >> + if (_gcry_mpi_ec_get_affine (x, y, &R, ec) >> + && !(flags & PUBKEY_FLAG_DJB_TWEAK)) >> log_fatal ("ecdh: Failed to get affine coordinates for kdG\n"); > > Instead of calling log_fatal, which terminates the process, we would > better return an error. [...] > Ditto. > > What do you think of such a change? Yes, I think that it's better to return an error. Because libgcrypt is a library and there is a possibility it happens with invalid input, it's good to return an error. I'll change ECDH functions return an error for invalid input. -- From cvs at cvs.gnupg.org Wed Apr 13 03:33:39 2016 From: cvs at cvs.gnupg.org (by NIIBE Yutaka) Date: Wed, 13 Apr 2016 03:33:39 +0200 Subject: [git] GCRYPT - branch, master, updated. libgcrypt-1.6.0-378-g8472b71 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 8472b71812e71c69d66e2fcc02a6e21b66755f8b (commit) from b6d2a25a275a35ec4dbd53ecaa9ea0ed7aa99c7b (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 8472b71812e71c69d66e2fcc02a6e21b66755f8b Author: NIIBE Yutaka Date: Wed Apr 13 10:10:53 2016 +0900 ecc: Fix corner cases for X25519. * cipher/ecc.c (ecc_encrypt_raw): For invalid input, returns GPG_ERR_INV_DATA instead of aborting with log_fatal. For X25519, it's not an error, thus, let it return 0. (ecc_decrypt_raw): Use the flag PUBKEY_FLAG_DJB_TWEAK to distinguish X25519, not by the name of the curve. (ecc_decrypt_raw): For invalid input, returns GPG_ERR_INV_DATA instead of aborting with log_fatal. For X25519, it's not an error by its definition, but we deliberately let it return the error to detect looks-like-encrypted-message. * tests/t-cv25519.c: Add points to record the issue. -- For X25519 ECDH, this change introduces incompatibility to crypto_scalarmult with the input which makes shared secret to be 0. For crypto_scalarmult, the result is 0. In libgcrypt, it's an error of GPG_ERR_INV_DATA (we consider the input is invalid). Signed-off-by: NIIBE Yutaka diff --git a/cipher/ecc.c b/cipher/ecc.c index f6b2b69..a437a1f 100644 --- a/cipher/ecc.c +++ b/cipher/ecc.c @@ -1395,7 +1395,23 @@ ecc_encrypt_raw (gcry_sexp_t *r_ciph, gcry_sexp_t s_data, gcry_sexp_t keyparms) _gcry_mpi_ec_mul_point (&R, data, &pk.Q, ec); if (_gcry_mpi_ec_get_affine (x, y, &R, ec)) - log_fatal ("ecdh: Failed to get affine coordinates for kdG\n"); + { + /* + * Here, X is 0. In the X25519 computation on Curve25519, X0 + * function maps infinity to zero. So, when PUBKEY_FLAG_DJB_TWEAK + * is enabled, return the result of 0 not raising an error. + * + * This is a corner case. It never occurs with properly + * generated public keys, but it might happen with blindly + * imported public key which might not follow the key + * generation procedure. + */ + if (!(flags & PUBKEY_FLAG_DJB_TWEAK)) + { /* It's not for X25519, then, the input data was simply wrong. */ + rc = GPG_ERR_INV_DATA; + goto leave; + } + } if (y) mpi_s = _gcry_ecc_ec2os (x, y, pk.E.p); else @@ -1416,7 +1432,10 @@ ecc_encrypt_raw (gcry_sexp_t *r_ciph, gcry_sexp_t s_data, gcry_sexp_t keyparms) _gcry_mpi_ec_mul_point (&R, data, &pk.E.G, ec); if (_gcry_mpi_ec_get_affine (x, y, &R, ec)) - log_fatal ("ecdh: Failed to get affine coordinates for kG\n"); + { + rc = GPG_ERR_INV_DATA; + goto leave; + } if (y) mpi_e = _gcry_ecc_ec2os (x, y, pk.E.p); else @@ -1598,8 +1617,8 @@ ecc_decrypt_raw (gcry_sexp_t *r_plain, gcry_sexp_t s_data, gcry_sexp_t keyparms) if (DBG_CIPHER) log_printpnt ("ecc_decrypt kG", &kG, NULL); - if (!(curvename && !strcmp (curvename, "Curve25519")) - /* For Curve25519, by its definition, validation should not be done. */ + if (!(flags & PUBKEY_FLAG_DJB_TWEAK) + /* For X25519, by its definition, validation should not be done. */ && !_gcry_mpi_ec_curve_point (&kG, ec)) { rc = GPG_ERR_INV_DATA; @@ -1619,14 +1638,32 @@ ecc_decrypt_raw (gcry_sexp_t *r_plain, gcry_sexp_t s_data, gcry_sexp_t keyparms) else y = mpi_new (0); - /* - * Here, x is 0. In the X25519 computation on Curve25519, X0 - * function maps infinity to zero. So, when PUBKEY_FLAG_DJB_TWEAK - * is enabled, we can just skip the check to get the result of 0. - */ - if (_gcry_mpi_ec_get_affine (x, y, &R, ec) - && !(flags & PUBKEY_FLAG_DJB_TWEAK)) - log_fatal ("ecdh: Failed to get affine coordinates\n"); + if (_gcry_mpi_ec_get_affine (x, y, &R, ec)) + { + rc = GPG_ERR_INV_DATA; + goto leave; + /* + * Note for X25519. + * + * By the definition of X25519, this is the case where X25519 + * returns 0, mapping infinity to zero. However, we + * deliberately let it return an error. + * + * For X25519 ECDH, comming here means that it might be + * decrypted by anyone with the shared secret of 0 (the result + * of this function could be always 0 by other scalar values, + * other than the private key of SK.D). + * + * So, it looks like an encrypted message but it can be + * decrypted by anyone, or at least something wrong + * happens. Recipient should not proceed as if it were + * properly encrypted message. + * + * This handling is needed for our major usage of GnuPG, + * where it does the One-Pass Diffie-Hellman method, + * C(1, 1, ECC CDH), with an ephemeral key. + */ + } if (y) r = _gcry_ecc_ec2os (x, y, sk.E.p); diff --git a/tests/t-cv25519.c b/tests/t-cv25519.c index 7e551c2..098c66a 100644 --- a/tests/t-cv25519.c +++ b/tests/t-cv25519.c @@ -32,7 +32,7 @@ #include "stopwatch.h" #define PGM "t-cv25519" -#define N_TESTS 6 +#define N_TESTS 18 #define my_isascii(c) (!((c) & 0x80)) #define digitp(p) (*(p) >= '0' && *(p) <= '9') @@ -499,6 +499,80 @@ check_cv25519 (void) "4a5d9d5ba4ce2de1728e3bf480350f25e07e21c947d19e3376f09b3c1e161742"); ntests++; + /* Seven tests which results 0. */ + test_cv (7, + "a546e36bf0527c9d3b16154b82465edd62144c0ac1fc5a18506a2244ba449ac4", + "0000000000000000000000000000000000000000000000000000000000000000", + "0000000000000000000000000000000000000000000000000000000000000000"); + ntests++; + + test_cv (8, + "a546e36bf0527c9d3b16154b82465edd62144c0ac1fc5a18506a2244ba449ac4", + "0100000000000000000000000000000000000000000000000000000000000000", + "0000000000000000000000000000000000000000000000000000000000000000"); + ntests++; + + test_cv (9, + "a546e36bf0527c9d3b16154b82465edd62144c0ac1fc5a18506a2244ba449ac4", + "e0eb7a7c3b41b8ae1656e3faf19fc46ada098deb9c32b1fd866205165f49b800", + "0000000000000000000000000000000000000000000000000000000000000000"); + ntests++; + + test_cv (10, + "a546e36bf0527c9d3b16154b82465edd62144c0ac1fc5a18506a2244ba449ac4", + "5f9c95bca3508c24b1d0b1559c83ef5b04445cc4581c8e86d8224eddd09f1157", + "0000000000000000000000000000000000000000000000000000000000000000"); + ntests++; + + test_cv (11, + "a546e36bf0527c9d3b16154b82465edd62144c0ac1fc5a18506a2244ba449ac4", + "ecffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff7f", + "0000000000000000000000000000000000000000000000000000000000000000"); + ntests++; + + test_cv (12, + "a546e36bf0527c9d3b16154b82465edd62144c0ac1fc5a18506a2244ba449ac4", + "edffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff7f", + "0000000000000000000000000000000000000000000000000000000000000000"); + ntests++; + + test_cv (13, + "a546e36bf0527c9d3b16154b82465edd62144c0ac1fc5a18506a2244ba449ac4", + "eeffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff7f", + "0000000000000000000000000000000000000000000000000000000000000000"); + ntests++; + + /* Five tests which resulted 0 if decodeUCoordinate didn't change MSB. */ + test_cv (14, + "a546e36bf0527c9d3b16154b82465edd62144c0ac1fc5a18506a2244ba449ac4", + "cdeb7a7c3b41b8ae1656e3faf19fc46ada098deb9c32b1fd866205165f49b880", + "7ce548bc4919008436244d2da7a9906528fe3a6d278047654bd32d8acde9707b"); + ntests++; + + test_cv (15, + "a546e36bf0527c9d3b16154b82465edd62144c0ac1fc5a18506a2244ba449ac4", + "4c9c95bca3508c24b1d0b1559c83ef5b04445cc4581c8e86d8224eddd09f11d7", + "e17902e989a034acdf7248260e2c94cdaf2fe1e72aaac7024a128058b6189939"); + ntests++; + + test_cv (16, + "a546e36bf0527c9d3b16154b82465edd62144c0ac1fc5a18506a2244ba449ac4", + "d9ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff", + "ea6e6ddf0685c31e152d5818441ac9ac8db1a01f3d6cb5041b07443a901e7145"); + ntests++; + + test_cv (17, + "a546e36bf0527c9d3b16154b82465edd62144c0ac1fc5a18506a2244ba449ac4", + "daffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff", + "845ddce7b3a9b3ee01a2f1fd4282ad293310f7a232cbc5459fb35d94bccc9d05"); + ntests++; + + test_cv (18, + "a546e36bf0527c9d3b16154b82465edd62144c0ac1fc5a18506a2244ba449ac4", + "dbffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff", + "6989e2cb1cea159acf121b0af6bf77493189c9bd32c2dac71669b540f9488247"); + ntests++; + if (ntests != N_TESTS) fail ("did %d tests but expected %d", ntests, N_TESTS); else if ((ntests % 256)) ----------------------------------------------------------------------- Summary of changes: cipher/ecc.c | 61 +++++++++++++++++++++++++++++++++++--------- tests/t-cv25519.c | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++++++- 2 files changed, 124 insertions(+), 13 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 wk at gnupg.org Wed Apr 13 09:33:53 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 13 Apr 2016 09:33:53 +0200 Subject: [git] GCRYPT - branch, master, updated. libgcrypt-1.6.0-378-g8472b71 In-Reply-To: (by NIIBE Yutaka's message of "Wed, 13 Apr 2016 03:33:39 +0200") References: Message-ID: <87oa9ec68u.fsf@wheatstone.g10code.de> On Wed, 13 Apr 2016 03:33, cvs at cvs.gnupg.org said: > ecc: Fix corner cases for X25519. Cool - That should be the final thing for 1.7. Let's do some tests and get 1.7 out this week. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From liza.churkyn at sociomantic.com Wed Apr 13 11:40:40 2016 From: liza.churkyn at sociomantic.com (liza) Date: Wed, 13 Apr 2016 11:40:40 +0200 Subject: Libgcrypt CFB-mode as CFB-8bit Message-ID: <570E1418.6060204@sociomantic.com> Hello, I need to be able to decrypt CFB-8bit with Libgcrypt. Since this is currently not supported, I would like to submit a patch that adds support for this. I'm writing to ask whether such a patch would be accepted. Thanks, Liza From wk at gnupg.org Wed Apr 13 18:05:18 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 13 Apr 2016 18:05:18 +0200 Subject: Libgcrypt CFB-mode as CFB-8bit In-Reply-To: <570E1418.6060204@sociomantic.com> (liza's message of "Wed, 13 Apr 2016 11:40:40 +0200") References: <570E1418.6060204@sociomantic.com> Message-ID: <87r3e9a400.fsf@wheatstone.g10code.de> On Wed, 13 Apr 2016 11:40, liza.churkyn at sociomantic.com said: > I need to be able to decrypt CFB-8bit with Libgcrypt. Since this is > currently not supported, I would like to submit a patch > that adds support for this. Can you name an application for an 8 bit CFB mode? I doubt that any new protocol will use that and support for legacy protocols should only be done if it is worth the trouble. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From liza.churkyn at sociomantic.com Thu Apr 14 13:03:14 2016 From: liza.churkyn at sociomantic.com (liza) Date: Thu, 14 Apr 2016 13:03:14 +0200 Subject: Libgcrypt CFB-mode as CFB-8bit In-Reply-To: <87r3e9a400.fsf@wheatstone.g10code.de> References: <570E1418.6060204@sociomantic.com> <87r3e9a400.fsf@wheatstone.g10code.de> Message-ID: <570F78F2.2070307@sociomantic.com> Hello, I am writing an application that must integrate with a number of other external systems over which I have no control. Several of those systems already use 8 bit CFB mode to encrypt some data they send and they are not likely to change anytime soon. I had hoped to use gcrypt to do the decryption and while it works for all the other algorithms in use it doesn't for this one. Thanks, Liza On 13/04/16 18:05, Werner Koch wrote: > On Wed, 13 Apr 2016 11:40, liza.churkyn at sociomantic.com said: > >> I need to be able to decrypt CFB-8bit with Libgcrypt. Since this is >> currently not supported, I would like to submit a patch >> that adds support for this. > Can you name an application for an 8 bit CFB mode? I doubt that any new > protocol will use that and support for legacy protocols should only be > done if it is worth the trouble. > > > Shalom-Salam, > > Werner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cvs at cvs.gnupg.org Thu Apr 14 14:42:37 2016 From: cvs at cvs.gnupg.org (by Werner Koch) Date: Thu, 14 Apr 2016 14:42:37 +0200 Subject: [git] GCRYPT - branch, master, updated. libgcrypt-1.6.0-380-g47c6a1f 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 47c6a1f88eb763e9baa394e34d873b761abcebbe (commit) via 88c6b98350193abbdcfb227754979b0c097ee09c (commit) from 8472b71812e71c69d66e2fcc02a6e21b66755f8b (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 47c6a1f88eb763e9baa394e34d873b761abcebbe Author: Werner Koch Date: Thu Apr 14 14:39:31 2016 +0200 cipher: Add constant for 8 bit CFB mode. * src/gcrypt.h.in (GCRY_CIPHER_MODE_CFB8): New. * tests/basic.c (check_cfb_cipher): Prepare for CFB-8 tests. -- Note that there is no implementation for the 8 bit CFB mode yet. We will add that as a bug fix after the release of 1.7.0. Signed-off-by: Werner Koch diff --git a/NEWS b/NEWS index 9cb5e36..7b53c1a 100644 --- a/NEWS +++ b/NEWS @@ -68,6 +68,7 @@ Noteworthy changes in version 1.7.0 (unreleased) gcry_mpi_ec_decode_point NEW. GCRY_CIPHER_MODE_POLY1305 NEW. GCRY_CIPHER_MODE_OCB NEW. + GCRY_CIPHER_MODE_CFB8 NEW constant. GCRYCTL_SET_TAGLEN NEW. GCRYCTL_GET_TAGLEN NEW. gcry_cipher_final NEW macro. diff --git a/doc/gcrypt.texi b/doc/gcrypt.texi index a78c5fd..0171cd6 100644 --- a/doc/gcrypt.texi +++ b/doc/gcrypt.texi @@ -1598,9 +1598,12 @@ set, this mode may be used to bypass the actual encryption. Electronic Codebook mode. @item GCRY_CIPHER_MODE_CFB + at item GCRY_CIPHER_MODE_CFB8 @cindex CFB, Cipher Feedback mode -Cipher Feedback mode. The shift size equals the block size of the -cipher (e.g. for AES it is CFB-128). +Cipher Feedback mode. For GCRY_CIPHER_MODE_CFB the shift size equals +the block size of the cipher (e.g. for AES it is CFB-128). For +GCRY_CIPHER_MODE_CFB8 the shift size is 8 bit but that variant is not +yet available. @item GCRY_CIPHER_MODE_CBC @cindex CBC, Cipher Block Chaining mode diff --git a/src/gcrypt.h.in b/src/gcrypt.h.in index bd25d1b..96d742a 100644 --- a/src/gcrypt.h.in +++ b/src/gcrypt.h.in @@ -961,7 +961,8 @@ enum gcry_cipher_modes GCRY_CIPHER_MODE_CCM = 8, /* Counter with CBC-MAC. */ GCRY_CIPHER_MODE_GCM = 9, /* Galois Counter Mode. */ GCRY_CIPHER_MODE_POLY1305 = 10, /* Poly1305 based AEAD mode. */ - GCRY_CIPHER_MODE_OCB = 11 /* OCB3 mode. */ + GCRY_CIPHER_MODE_OCB = 11, /* OCB3 mode. */ + GCRY_CIPHER_MODE_CFB8 = 12 /* Cipher feedback (8 bit mode). */ }; /* Flags used with the open function. */ diff --git a/tests/basic.c b/tests/basic.c index 4940f6a..96fb4cb 100644 --- a/tests/basic.c +++ b/tests/basic.c @@ -873,6 +873,7 @@ check_cfb_cipher (void) static const struct tv { int algo; + int cfb8; char key[MAX_DATA_LEN]; char iv[MAX_DATA_LEN]; struct data @@ -885,7 +886,7 @@ check_cfb_cipher (void) } tv[] = { /* http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf */ - { GCRY_CIPHER_AES, + { GCRY_CIPHER_AES, 0, "\x2b\x7e\x15\x16\x28\xae\xd2\xa6\xab\xf7\x15\x88\x09\xcf\x4f\x3c", "\x00\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f", { { "\x6b\xc1\xbe\xe2\x2e\x40\x9f\x96\xe9\x3d\x7e\x11\x73\x93\x17\x2a", @@ -902,7 +903,7 @@ check_cfb_cipher (void) "\xc0\x4b\x05\x35\x7c\x5d\x1c\x0e\xea\xc4\xc6\x6f\x9f\xf7\xf2\xe6" }, } }, - { GCRY_CIPHER_AES192, + { GCRY_CIPHER_AES192, 0, "\x8e\x73\xb0\xf7\xda\x0e\x64\x52\xc8\x10\xf3\x2b" "\x80\x90\x79\xe5\x62\xf8\xea\xd2\x52\x2c\x6b\x7b", "\x00\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f", @@ -920,7 +921,7 @@ check_cfb_cipher (void) "\xc0\x5f\x9f\x9c\xa9\x83\x4f\xa0\x42\xae\x8f\xba\x58\x4b\x09\xff" }, } }, - { GCRY_CIPHER_AES256, + { GCRY_CIPHER_AES256, 0, "\x60\x3d\xeb\x10\x15\xca\x71\xbe\x2b\x73\xae\xf0\x85\x7d\x77\x81" "\x1f\x35\x2c\x07\x3b\x61\x08\xd7\x2d\x98\x10\xa3\x09\x14\xdf\xf4", "\x00\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f", @@ -941,7 +942,7 @@ check_cfb_cipher (void) }; gcry_cipher_hd_t hde, hdd; unsigned char out[MAX_DATA_LEN]; - int i, j, keylen, blklen; + int i, j, keylen, blklen, mode; gcry_error_t err = 0; if (verbose) @@ -957,13 +958,15 @@ check_cfb_cipher (void) continue; } + mode = tv[i].cfb8? GCRY_CIPHER_MODE_CFB8 : GCRY_CIPHER_MODE_CFB; + if (verbose) fprintf (stderr, " checking CFB mode for %s [%i]\n", gcry_cipher_algo_name (tv[i].algo), tv[i].algo); - err = gcry_cipher_open (&hde, tv[i].algo, GCRY_CIPHER_MODE_CFB, 0); + err = gcry_cipher_open (&hde, tv[i].algo, mode, 0); if (!err) - err = gcry_cipher_open (&hdd, tv[i].algo, GCRY_CIPHER_MODE_CFB, 0); + err = gcry_cipher_open (&hdd, tv[i].algo, mode, 0); if (err) { fail ("aes-cfb, gcry_cipher_open failed: %s\n", gpg_strerror (err)); commit 88c6b98350193abbdcfb227754979b0c097ee09c Author: Werner Koch Date: Thu Apr 14 13:26:55 2016 +0200 tests: Add a new test for S-expressions. * tests/t-sexp.c (compare_to_canon): New. (back_and_forth_one): Add another test. -- Signed-off-by: Werner Koch diff --git a/tests/t-sexp.c b/tests/t-sexp.c index 4785b17..33a58ff 100644 --- a/tests/t-sexp.c +++ b/tests/t-sexp.c @@ -387,11 +387,46 @@ canon_len (void) } +/* Compare SE to the canonical formatted expression in + * (CANON,CANONLEN). This is done by a converting SE to canonical + * format and doing a byte compare. Returns 0 if they match. */ +static int +compare_to_canon (gcry_sexp_t se, const unsigned char *canon, size_t canonlen) +{ + size_t n, n1; + char *p1; + + n1 = gcry_sexp_sprint (se, GCRYSEXP_FMT_CANON, NULL, 0); + if (!n1) + { + fail ("get required length in compare_to_canon failed\n"); + return -1; + } + p1 = gcry_xmalloc (n1); + n = gcry_sexp_sprint (se, GCRYSEXP_FMT_CANON, p1, n1); + if (n1 != n+1) + { + fail ("length mismatch in compare_to_canon detected\n"); + xfree (p1); + return -1; + } + if (n1 != canonlen || memcmp (p1, canon, canonlen)) + { + xfree (p1); + return -1; + } + xfree (p1); + return 0; +} + + static void back_and_forth_one (int testno, const char *buffer, size_t length) { gcry_error_t rc; gcry_sexp_t se, se1; + unsigned char *canon; + size_t canonlen; /* Including the hidden nul suffix. */ size_t n, n1; char *p1; @@ -409,11 +444,14 @@ back_and_forth_one (int testno, const char *buffer, size_t length) } p1 = gcry_xmalloc (n1); n = gcry_sexp_sprint (se, GCRYSEXP_FMT_CANON, p1, n1); - if (n1 != n+1) /* sprints adds an extra 0 but dies not return it */ + if (n1 != n+1) /* sprints adds an extra 0 but does not return it. */ { fail ("baf %d: length mismatch for canon\n", testno); return; } + canonlen = n1; + canon = gcry_malloc (canonlen); + memcpy (canon, p1, canonlen); rc = gcry_sexp_create (&se1, p1, n, 0, gcry_free); if (rc) { @@ -449,9 +487,40 @@ back_and_forth_one (int testno, const char *buffer, size_t length) fail ("baf %d: memory corrupted (3)\n", testno); gcry_free (p1); + /* Check converting to advanced format. */ + n1 = gcry_sexp_sprint (se, GCRYSEXP_FMT_ADVANCED, NULL, 0); + if (!n1) + { + fail ("baf %d: get required length for advanced failed\n", testno); + return; + } + p1 = gcry_xmalloc (n1); + n = gcry_sexp_sprint (se, GCRYSEXP_FMT_ADVANCED, p1, n1); + if (n1 != n+1) /* sprints adds an extra 0 but does not return it */ + { + fail ("baf %d: length mismatch for advanced\n", testno); + return; + } + rc = gcry_sexp_create (&se1, p1, n, 0, gcry_free); + if (rc) + { + fail ("baf %d: gcry_sexp_create failed: %s\n", + testno, gpg_strerror (rc)); + return; + } + if (compare_to_canon (se1, canon, canonlen)) + { + fail ("baf %d: converting to advanced failed.\n", + testno, gpg_strerror (rc)); + return; + } + gcry_sexp_release (se1); + + /* FIXME: we need a lot more tests */ gcry_sexp_release (se); + xfree (canon); } @@ -474,6 +543,13 @@ back_and_forth (void) " #F7B0B535F8F8E22F4F3DA031224070303F82F9207D42952F1ACF21A4AB1C50304EBB25527992C7B265A9E9FF702826FB88759BDD55E4759E9FCA6C879538C9D043A9C60A326CB6681090BAA731289BD880A7D5774D9999F026E5E7963BFC8C0BDC9F061393CB734B4F259725C0A0A0B15BA39C39146EF6A1B3DC4DF30A22EBE09FD05AE6CB0C8C6532951A925F354F4E26A51964F5BBA50081690C421C8385C4074E9BAB9297D081B857756607EAE652415275A741C89E815558A50AC638EDC5F5030210B4395E3E1A40FF38DCCCB333A19EA88EFE7E4D51B54128C6DF27395646836679AC21B1B25C1DA6F0A7CE9F9BE078EFC7934FA9AE202CBB0AA06C20DFAF9A66FAB7E9073FBE96B9A7F25C3BA45EC3EECA65796AEE313BA148DE5314F30345B452B50B17C4D841A7F27397126E8C10BD0CE3B50A82C0425AAEE7798031671407B681F52916256F78CAF92A477AC27BCBE26DAFD1BCE386A853E2A036F8314BB2E8E5BB1F196434232EFB0288331C2AB16DBC5457CC295EB966CAC5CE73D5DA5D566E469F0EFA82F9A12B8693E0#)\n" " )\n" " )\n", 0 }, + { "((sha1 #8B98CBF4A9823CA7# \"2097\") #3B6FC9#)", 0 }, + { "((4:sha18:\x8B\x98\xCB\xF4\xA9\x82\x3C\xA7""4:2097)3:\x3B\x6F\xC9)", 0}, + { "((4:sha18:\x8B\x98\xCB\x22\xA9\x82\x3C\xA7""4:2097)3:\x3B\x6F\xC9)", 0}, + { "((sha1 #64652267686970C9# \"2097\") #3B6FC9#)", 0 }, + { "((4:sha18:\x64\x65\x22\x67\x68\xc3\xa4\x71""4:2097)3:\x3B\x6F\xC9)", 0}, + { "((sha1 \"defgh?q\" \"2097\") #3B6FC9#)", 0 }, + { "((sha1 \"de\\\"gh?q\" \"2097\") #3B6FC9#)", 0 }, { NULL, 0 } }; int idx; ----------------------------------------------------------------------- Summary of changes: NEWS | 1 + doc/gcrypt.texi | 7 ++++-- src/gcrypt.h.in | 3 ++- tests/basic.c | 15 ++++++----- tests/t-sexp.c | 78 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++- 5 files changed, 94 insertions(+), 10 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 wk at gnupg.org Thu Apr 14 14:45:10 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 14 Apr 2016 14:45:10 +0200 Subject: Libgcrypt CFB-mode as CFB-8bit In-Reply-To: <570F78F2.2070307@sociomantic.com> (liza's message of "Thu, 14 Apr 2016 13:03:14 +0200") References: <570E1418.6060204@sociomantic.com> <87r3e9a400.fsf@wheatstone.g10code.de> <570F78F2.2070307@sociomantic.com> Message-ID: <877fg08ill.fsf@wheatstone.g10code.de> On Thu, 14 Apr 2016 13:03, liza.churkyn at sociomantic.com said: > systems already use 8 bit CFB mode to encrypt some data they send and > they are not likely to change anytime soon. I had hoped to use gcrypt > to do the decryption and while it works for all the other algorithms It is too late for 1.7.0 to add this mode. Anyway, I just pushed a change which adds GCRY_CIPHER_MODE_CFB8 to prepare for an addition in 1.7.1 Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From justus at g10code.com Thu Apr 14 14:04:49 2016 From: justus at g10code.com (Justus Winter) Date: Thu, 14 Apr 2016 14:04:49 +0200 Subject: [PATCH] src: Improve S-expression parsing. Message-ID: <1460635489-19498-1-git-send-email-justus@g10code.com> * src/sexp.c (do_vsexp_sscan): Return an error if a closing parenthesis is encountered with no matching opening parenthesis. Signed-off-by: Justus Winter --- src/sexp.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/src/sexp.c b/src/sexp.c index 636f922..6077bab 100644 --- a/src/sexp.c +++ b/src/sexp.c @@ -1592,6 +1592,13 @@ do_vsexp_sscan (gcry_sexp_t *retsexp, size_t *erroff, err = GPG_ERR_SEXP_UNMATCHED_DH; goto leave; } + + if (level == 0) + { + *erroff = p - buffer; + err = GPG_ERR_SEXP_UNMATCHED_PAREN; + goto leave; + } MAKE_SPACE (0); *c.pos++ = ST_CLOSE; level--; -- 2.1.4 From wk at gnupg.org Thu Apr 14 15:21:13 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 14 Apr 2016 15:21:13 +0200 Subject: [PATCH] src: Improve S-expression parsing. In-Reply-To: <1460635489-19498-1-git-send-email-justus@g10code.com> (Justus Winter's message of "Thu, 14 Apr 2016 14:04:49 +0200") References: <1460635489-19498-1-git-send-email-justus@g10code.com> Message-ID: <87lh4g72d2.fsf@wheatstone.g10code.de> On Thu, 14 Apr 2016 14:04, justus at g10code.com said: > * src/sexp.c (do_vsexp_sscan): Return an error if a closing > parenthesis is encountered with no matching opening parenthesis. Good catch. In _gcry_sexp_canon_len that check is done, though. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From liza.churkyn at sociomantic.com Thu Apr 14 15:43:52 2016 From: liza.churkyn at sociomantic.com (liza) Date: Thu, 14 Apr 2016 15:43:52 +0200 Subject: Libgcrypt CFB-mode as CFB-8bit In-Reply-To: <877fg08ill.fsf@wheatstone.g10code.de> References: <570E1418.6060204@sociomantic.com> <87r3e9a400.fsf@wheatstone.g10code.de> <570F78F2.2070307@sociomantic.com> <877fg08ill.fsf@wheatstone.g10code.de> Message-ID: <570F9E98.4070200@sociomantic.com> Excellent. Did you want to do this yourself or would you like patches? I'm happy to do it, should just say this will be my first foray into encryption code so I may have to come back for advice :) Liza On 14/04/16 14:45, Werner Koch wrote: > On Thu, 14 Apr 2016 13:03, liza.churkyn at sociomantic.com said: > >> systems already use 8 bit CFB mode to encrypt some data they send and >> they are not likely to change anytime soon. I had hoped to use gcrypt >> to do the decryption and while it works for all the other algorithms > It is too late for 1.7.0 to add this mode. Anyway, I just pushed a > change which adds GCRY_CIPHER_MODE_CFB8 to prepare for an addition in > 1.7.1 > > > Shalom-Salam, > > Werner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cvs at cvs.gnupg.org Thu Apr 14 16:36:27 2016 From: cvs at cvs.gnupg.org (by Justus Winter) Date: Thu, 14 Apr 2016 16:36:27 +0200 Subject: [git] GCRYPT - branch, master, updated. libgcrypt-1.6.0-381-g491586b 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 491586bc7f7b9edc6b78331a77e653543983c9e4 (commit) from 47c6a1f88eb763e9baa394e34d873b761abcebbe (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 491586bc7f7b9edc6b78331a77e653543983c9e4 Author: Justus Winter Date: Thu Apr 14 13:53:55 2016 +0200 src: Improve S-expression parsing. * src/sexp.c (do_vsexp_sscan): Return an error if a closing parenthesis is encountered with no matching opening parenthesis. Signed-off-by: Justus Winter diff --git a/src/sexp.c b/src/sexp.c index 636f922..6077bab 100644 --- a/src/sexp.c +++ b/src/sexp.c @@ -1592,6 +1592,13 @@ do_vsexp_sscan (gcry_sexp_t *retsexp, size_t *erroff, err = GPG_ERR_SEXP_UNMATCHED_DH; goto leave; } + + if (level == 0) + { + *erroff = p - buffer; + err = GPG_ERR_SEXP_UNMATCHED_PAREN; + goto leave; + } MAKE_SPACE (0); *c.pos++ = ST_CLOSE; level--; ----------------------------------------------------------------------- Summary of changes: src/sexp.c | 7 +++++++ 1 file changed, 7 insertions(+) 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 cvs at cvs.gnupg.org Fri Apr 15 09:42:43 2016 From: cvs at cvs.gnupg.org (by Werner Koch) Date: Fri, 15 Apr 2016 09:42:43 +0200 Subject: [git] GCRYPT - branch, master, updated. libgcrypt-1.6.0-382-g1737c54 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 1737c546dc7268fa9edcd4a23b7439c56d37ee4f (commit) from 491586bc7f7b9edc6b78331a77e653543983c9e4 (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 1737c546dc7268fa9edcd4a23b7439c56d37ee4f Author: Werner Koch Date: Thu Apr 14 16:32:04 2016 +0200 tests: Add test vectors for 256 GiB test of SHA3-256. * tests/hashtest.c: Add new test vectros. Signed-off-by: Werner Koch diff --git a/tests/hashtest.c b/tests/hashtest.c index e2178aa..33907fb 100644 --- a/tests/hashtest.c +++ b/tests/hashtest.c @@ -102,6 +102,22 @@ static struct { "49920704ea9d6ee19f0742d6c868110fa3eda8ac09f026e9ef22cc731af53020" "de40eedef66cb1afd94c61e285fa9327e01336e804903740a9145ab1f065c2d5" }, + { GCRY_MD_SHA3_512, 256, -64, + "c6e082b3db996dbe5f2c5709818a7f325ef4febd883d7e9c545c06bfa7225198" + "1ecf40103788913cd5a5bdf13246b952ded6651043684b24197eb23544882a97" }, + { GCRY_MD_SHA3_512, 256, -1, + "d7bf28e8216bf7d3d0d3969e34078e94b98598e17b6f21f256379389e4eba8ee" + "74eb288774797263fec00bdfd357d132cea9e408be36b982f5a60ab56ad01613" }, + { GCRY_MD_SHA3_512, 256, +0, + "c1270852ba7b1e1a3eaa777969b8a65be28c3894537c61eb8cd22b1df6af703d" + "b59939f6adadeb64317faece8167d4817e73daf73e28a5ccd26bebee0a35c322" }, + { GCRY_MD_SHA3_512, 256, +1, + "8bdfeb3a1a9a1cdcef21172cbc5bb3b87c0d8f7111df0aaf7f1bc03ad4775bd6" + "a03e0a875c4e7d02d2230c213562c6a57be28d92eaf6e4bea4bc24690454c8ef" }, + { GCRY_MD_SHA3_512, 256, +64, + "0c91b91665ceaf7af5102e0ed31aa4f050668ab3c57b1f4763946d567efe66b3" + "ab9a2016cf238dee5b44eae9f0cdfbf7b7a6eb1e759986273243dc35894706b6" }, + { 0 } }; ----------------------------------------------------------------------- Summary of changes: tests/hashtest.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) 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 erik.nellessen at informatik.hu-berlin.de Fri Apr 15 12:41:02 2016 From: erik.nellessen at informatik.hu-berlin.de (Erik Nellessen) Date: Fri, 15 Apr 2016 12:41:02 +0200 Subject: Unexpected result when encrypting using gcry_pk_encrypt Message-ID: <5710C53E.4050306@informatik.hu-berlin.de> I am trying to perform an RSA encryption using the function gcry_error_t gcry_pk_encrypt (gcry_sexp_t *r_ciph, gcry_sexp_t data, gcry_sexp_t pkey) as described here: https://gnupg.org/documentation/manuals/gcrypt/Cryptographic-Functions.html I put a minimal working example in the attachment. To perform the RSA encryption, I convert strings to mpis (as described on https://gnupg.org/documentation/manuals/gcrypt/MPI-formats.html) and mpis to sexps (as described on https://gnupg.org/documentation/manuals/gcrypt/Working-with-S_002dexpressions.html). This works just as I would expect. When I print the mpis and sexps to the command line, I get the original strings. Doing the encryption also works without any error. But when I print the result to the command line, I get a lot of cryptographic signs. Now that is in general not a surprise when printing a cipher text, but in this scenario I would have expected a string representing an integer, just like the modulus I used. I have the impression that I missed or misunderstood something important here. Am I converting my strings in a wrong way? Is there anything going wrong with the encryption? I am using libgcrypt 1.6.3 on Debian Jessie. Any kind of help would be appreciated! Kind regards, Erik -------------- next part -------------- all: gcc -l gcrypt -o mwe mwe.c -------------- next part -------------- A non-text attachment was scrubbed... Name: mwe.c Type: text/x-csrc Size: 3875 bytes Desc: not available URL: From wk at gnupg.org Fri Apr 15 14:01:44 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 15 Apr 2016 14:01:44 +0200 Subject: Unexpected result when encrypting using gcry_pk_encrypt In-Reply-To: <5710C53E.4050306@informatik.hu-berlin.de> (Erik Nellessen's message of "Fri, 15 Apr 2016 12:41:02 +0200") References: <5710C53E.4050306@informatik.hu-berlin.de> Message-ID: <87ega7ytav.fsf@wheatstone.g10code.de> Hi, here are a few quick comments: > void print_mpi(gcry_mpi_t mpi){ > unsigned char *returned_string; > int returned_string_length; > gcry_error_t rc = gcry_mpi_aprint(GCRYMPI_FMT_USG, &returned_string, &returned_string_length, mpi); > if(rc){ > fprintf(stderr, "File: %s, Line: %i.\n", __FILE__, __LINE__); > exit(-1); > } > printf("length of returned string: %i\n", returned_string_length); > printf("returned string: "); > int i; > for(i = 0; i < returned_string_length; i++){ > printf("%c", returned_string[i]); You are printing binary data here. The printing is actually the same as fputs ("returned string: ", stdout); fwrite (returned_string, returned_string_length, 1, stdout); If you want a hex presentation you need to use rc = gcry_mpi_aprint(GCRYMPI_FMT_HEX, &returned_string, ....) GCRYMPI_FMT_USG returns an unsigned integer binary representation. Given that this is just for debug output, the use of gcry_log_debugmpi ("returned string", mpi); is probably easier (goes by default to stderr, though). > void print_sexp(gcry_sexp_t sexp){ > unsigned char buffer[BUFFER_SIZE]; > size_t bytes_printed = gcry_sexp_sprint(sexp, GCRYSEXP_FMT_DEFAULT, buffer, BUFFER_SIZE); Here you should use GCRYSEXP_FMT_ADVANCED to get a printable output. Or use gcry_log_debugsxp ("returned sexp", sexp); Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From cvs at cvs.gnupg.org Fri Apr 15 16:07:31 2016 From: cvs at cvs.gnupg.org (by Werner Koch) Date: Fri, 15 Apr 2016 16:07:31 +0200 Subject: [git] GCRYPT - branch, master, updated. libgcrypt-1.7.0-1-geecc081 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 eecc081f8ae02c43454abaee4a4f72efaee42745 (commit) via 795f9cb090c776658a0e3117996e3fb7e2ebd94a (commit) from 1737c546dc7268fa9edcd4a23b7439c56d37ee4f (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 ----------------------------------------------------------------- ----------------------------------------------------------------------- Summary of changes: AUTHORS | 19 +++-- NEWS | 209 ++++++++++++++++++++++++++++++++++++-------------- README | 54 +++++-------- compat/compat.c | 6 +- configure.ac | 5 +- src/gcrypt.h.in | 6 +- src/versioninfo.rc.in | 2 +- 7 files changed, 186 insertions(+), 115 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 erik.nellessen at informatik.hu-berlin.de Fri Apr 15 18:31:24 2016 From: erik.nellessen at informatik.hu-berlin.de (Erik Nellessen) Date: Fri, 15 Apr 2016 18:31:24 +0200 Subject: Unexpected result when encrypting using gcry_pk_encrypt In-Reply-To: <87ega7ytav.fsf@wheatstone.g10code.de> References: <5710C53E.4050306@informatik.hu-berlin.de> <87ega7ytav.fsf@wheatstone.g10code.de> Message-ID: <5711175C.5060902@informatik.hu-berlin.de> Ah, now I see! I misunderstood the gcry_mpi_scan function. I had to convert my strings to a binary representation, before passing them to gcry_mpi_scan. Then, also the mpis consist mostly of cryptographic signs, if printed directly. When using the functions you supposed, of course a nicer representation is shown. I was able to encrypt some data now, and also to decrypt it, everything went fine. Thank you very much for your help! Erik Werner Koch: > Hi, > > here are a few quick comments: > >> void print_mpi(gcry_mpi_t mpi){ >> unsigned char *returned_string; >> int returned_string_length; >> gcry_error_t rc = gcry_mpi_aprint(GCRYMPI_FMT_USG, &returned_string, &returned_string_length, mpi); >> if(rc){ >> fprintf(stderr, "File: %s, Line: %i.\n", __FILE__, __LINE__); >> exit(-1); >> } >> printf("length of returned string: %i\n", returned_string_length); >> printf("returned string: "); >> int i; >> for(i = 0; i < returned_string_length; i++){ >> printf("%c", returned_string[i]); > > You are printing binary data here. The printing is actually the same as > > fputs ("returned string: ", stdout); > fwrite (returned_string, returned_string_length, 1, stdout); > > If you want a hex presentation you need to use > > rc = gcry_mpi_aprint(GCRYMPI_FMT_HEX, &returned_string, ....) > > GCRYMPI_FMT_USG returns an unsigned integer binary representation. > Given that this is just for debug output, the use of > > gcry_log_debugmpi ("returned string", mpi); > > is probably easier (goes by default to stderr, though). > >> void print_sexp(gcry_sexp_t sexp){ >> unsigned char buffer[BUFFER_SIZE]; >> size_t bytes_printed = gcry_sexp_sprint(sexp, GCRYSEXP_FMT_DEFAULT, buffer, BUFFER_SIZE); > > Here you should use GCRYSEXP_FMT_ADVANCED to get a printable output. Or > use > > gcry_log_debugsxp ("returned sexp", sexp); > > > > > Salam-Shalom, > > Werner > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From cvs at cvs.gnupg.org Tue Apr 19 20:06:48 2016 From: cvs at cvs.gnupg.org (by Werner Koch) Date: Tue, 19 Apr 2016 20:06:48 +0200 Subject: [git] GCRYPT - branch, master, updated. libgcrypt-1.7.0-2-g4545372 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 4545372c0f8dd35aef2a7abc12b588ed1a4a0363 (commit) from eecc081f8ae02c43454abaee4a4f72efaee42745 (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 4545372c0f8dd35aef2a7abc12b588ed1a4a0363 Author: Werner Koch Date: Tue Apr 19 20:05:07 2016 +0200 asm fix for older gcc versions. * cipher/crc-intel-pclmul.c: Remove extra trailing colon from asm statements. -- gcc 4.2 is not able to grok a third colon without clobber expressions. Reported for FreeBSD 9. GnuPG-bug-id: 2326 Signed-off-by: Werner Koch diff --git a/cipher/crc-intel-pclmul.c b/cipher/crc-intel-pclmul.c index 5002f80..c034e2e 100644 --- a/cipher/crc-intel-pclmul.c +++ b/cipher/crc-intel-pclmul.c @@ -143,7 +143,7 @@ crc32_reflected_bulk (u32 *pcrc, const byte *inbuf, size_t inlen, [inbuf_2] "m" (inbuf[2 * 16]), [inbuf_3] "m" (inbuf[3 * 16]), [crc] "m" (*pcrc) - : ); + ); inbuf += 4 * 16; inlen -= 4 * 16; @@ -151,7 +151,7 @@ crc32_reflected_bulk (u32 *pcrc, const byte *inbuf, size_t inlen, asm volatile ("movdqa %[k1k2], %%xmm4\n\t" : : [k1k2] "m" (consts->k[1 - 1]) - : ); + ); /* Fold by 4. */ while (inlen >= 4 * 16) @@ -188,7 +188,7 @@ crc32_reflected_bulk (u32 *pcrc, const byte *inbuf, size_t inlen, [inbuf_1] "m" (inbuf[1 * 16]), [inbuf_2] "m" (inbuf[2 * 16]), [inbuf_3] "m" (inbuf[3 * 16]) - : ); + ); inbuf += 4 * 16; inlen -= 4 * 16; @@ -199,7 +199,7 @@ crc32_reflected_bulk (u32 *pcrc, const byte *inbuf, size_t inlen, : : [k3k4] "m" (consts->k[3 - 1]), [my_p] "m" (consts->my_p[0]) - : ); + ); /* Fold 4 to 1. */ @@ -222,7 +222,7 @@ crc32_reflected_bulk (u32 *pcrc, const byte *inbuf, size_t inlen, "pxor %%xmm4, %%xmm0\n\t" : : - : ); + ); } else { @@ -236,7 +236,7 @@ crc32_reflected_bulk (u32 *pcrc, const byte *inbuf, size_t inlen, [crc] "m" (*pcrc), [k3k4] "m" (consts->k[3 - 1]), [my_p] "m" (consts->my_p[0]) - : ); + ); inbuf += 16; inlen -= 16; @@ -256,7 +256,7 @@ crc32_reflected_bulk (u32 *pcrc, const byte *inbuf, size_t inlen, "pxor %%xmm1, %%xmm0\n\t" : : [inbuf] "m" (*inbuf) - : ); + ); inbuf += 16; inlen -= 16; @@ -288,7 +288,7 @@ crc32_reflected_bulk (u32 *pcrc, const byte *inbuf, size_t inlen, [mask] "m" (crc32_partial_fold_input_mask[inlen]), [shl_shuf] "m" (crc32_refl_shuf_shift[inlen]), [shr_shuf] "m" (crc32_refl_shuf_shift[inlen + 16]) - : ); + ); inbuf += inlen; inlen -= inlen; @@ -318,7 +318,7 @@ crc32_reflected_bulk (u32 *pcrc, const byte *inbuf, size_t inlen, "pextrd $2, %%xmm0, %[out]\n\t" : [out] "=m" (*pcrc) : [k5] "m" (consts->k[5 - 1]) - : ); + ); } static inline void @@ -333,7 +333,7 @@ crc32_reflected_less_than_16 (u32 *pcrc, const byte *inbuf, size_t inlen, asm volatile ("movdqa %[my_p], %%xmm5\n\t" : : [my_p] "m" (consts->my_p[0]) - : ); + ); if (inlen == 1) { @@ -372,7 +372,7 @@ crc32_reflected_less_than_16 (u32 *pcrc, const byte *inbuf, size_t inlen, : [out] "=m" (*pcrc) : [in] "rm" (data), [crc] "rm" (crc) - : ); + ); } else if (inlen == 4) { @@ -391,7 +391,7 @@ crc32_reflected_less_than_16 (u32 *pcrc, const byte *inbuf, size_t inlen, : [in] "m" (*inbuf), [crc] "m" (*pcrc), [my_p] "m" (consts->my_p[0]) - : ); + ); } else { @@ -404,14 +404,14 @@ crc32_reflected_less_than_16 (u32 *pcrc, const byte *inbuf, size_t inlen, [crc] "m" (*pcrc), [my_p] "m" (consts->my_p[0]), [k3k4] "m" (consts->k[3 - 1]) - : ); + ); if (inlen >= 8) { asm volatile ("movq %[inbuf], %%xmm0\n\t" : : [inbuf] "m" (*inbuf) - : ); + ); if (inlen > 8) { asm volatile (/*"pinsrq $1, %[inbuf_tail], %%xmm0\n\t"*/ @@ -422,7 +422,7 @@ crc32_reflected_less_than_16 (u32 *pcrc, const byte *inbuf, size_t inlen, : [inbuf_tail] "m" (inbuf[inlen - 8]), [merge_shuf] "m" (*crc32_merge9to15_shuf[inlen - 9]) - : ); + ); } } else @@ -435,7 +435,7 @@ crc32_reflected_less_than_16 (u32 *pcrc, const byte *inbuf, size_t inlen, [inbuf_tail] "m" (inbuf[inlen - 4]), [merge_shuf] "m" (*crc32_merge5to7_shuf[inlen - 5]) - : ); + ); } /* Final fold. */ @@ -465,7 +465,7 @@ crc32_reflected_less_than_16 (u32 *pcrc, const byte *inbuf, size_t inlen, "pextrd $2, %%xmm0, %[out]\n\t" : [out] "=m" (*pcrc) : [k5] "m" (consts->k[5 - 1]) - : ); + ); } } @@ -477,7 +477,7 @@ crc32_bulk (u32 *pcrc, const byte *inbuf, size_t inlen, asm volatile ("movdqa %[bswap], %%xmm7\n\t" : : [bswap] "m" (*crc32_bswap_shuf) - : ); + ); if (inlen >= 8 * 16) { @@ -497,7 +497,7 @@ crc32_bulk (u32 *pcrc, const byte *inbuf, size_t inlen, [inbuf_2] "m" (inbuf[2 * 16]), [inbuf_3] "m" (inbuf[3 * 16]), [crc] "m" (*pcrc) - : ); + ); inbuf += 4 * 16; inlen -= 4 * 16; @@ -505,7 +505,7 @@ crc32_bulk (u32 *pcrc, const byte *inbuf, size_t inlen, asm volatile ("movdqa %[k1k2], %%xmm4\n\t" : : [k1k2] "m" (consts->k[1 - 1]) - : ); + ); /* Fold by 4. */ while (inlen >= 4 * 16) @@ -546,7 +546,7 @@ crc32_bulk (u32 *pcrc, const byte *inbuf, size_t inlen, [inbuf_1] "m" (inbuf[1 * 16]), [inbuf_2] "m" (inbuf[2 * 16]), [inbuf_3] "m" (inbuf[3 * 16]) - : ); + ); inbuf += 4 * 16; inlen -= 4 * 16; @@ -557,7 +557,7 @@ crc32_bulk (u32 *pcrc, const byte *inbuf, size_t inlen, : : [k3k4] "m" (consts->k[3 - 1]), [my_p] "m" (consts->my_p[0]) - : ); + ); /* Fold 4 to 1. */ @@ -580,7 +580,7 @@ crc32_bulk (u32 *pcrc, const byte *inbuf, size_t inlen, "pxor %%xmm4, %%xmm0\n\t" : : - : ); + ); } else { @@ -595,7 +595,7 @@ crc32_bulk (u32 *pcrc, const byte *inbuf, size_t inlen, [crc] "m" (*pcrc), [k3k4] "m" (consts->k[3 - 1]), [my_p] "m" (consts->my_p[0]) - : ); + ); inbuf += 16; inlen -= 16; @@ -616,7 +616,7 @@ crc32_bulk (u32 *pcrc, const byte *inbuf, size_t inlen, "pxor %%xmm1, %%xmm0\n\t" : : [inbuf] "m" (*inbuf) - : ); + ); inbuf += 16; inlen -= 16; @@ -650,7 +650,7 @@ crc32_bulk (u32 *pcrc, const byte *inbuf, size_t inlen, [mask] "m" (crc32_partial_fold_input_mask[inlen]), [shl_shuf] "m" (crc32_refl_shuf_shift[32 - inlen]), [shr_shuf] "m" (crc32_shuf_shift[inlen + 16]) - : ); + ); inbuf += inlen; inlen -= inlen; @@ -697,7 +697,7 @@ crc32_less_than_16 (u32 *pcrc, const byte *inbuf, size_t inlen, asm volatile ("movdqa %[my_p], %%xmm5\n\t" : : [my_p] "m" (consts->my_p[0]) - : ); + ); if (inlen == 1) { @@ -774,14 +774,14 @@ crc32_less_than_16 (u32 *pcrc, const byte *inbuf, size_t inlen, [crc] "m" (*pcrc), [my_p] "m" (consts->my_p[0]), [k3k4] "m" (consts->k[3 - 1]) - : ); + ); if (inlen >= 8) { asm volatile ("movq %[inbuf], %%xmm0\n\t" : : [inbuf] "m" (*inbuf) - : ); + ); if (inlen > 8) { asm volatile (/*"pinsrq $1, %[inbuf_tail], %%xmm0\n\t"*/ @@ -792,7 +792,7 @@ crc32_less_than_16 (u32 *pcrc, const byte *inbuf, size_t inlen, : [inbuf_tail] "m" (inbuf[inlen - 8]), [merge_shuf] "m" (*crc32_merge9to15_shuf[inlen - 9]) - : ); + ); } } else @@ -805,7 +805,7 @@ crc32_less_than_16 (u32 *pcrc, const byte *inbuf, size_t inlen, [inbuf_tail] "m" (inbuf[inlen - 4]), [merge_shuf] "m" (*crc32_merge5to7_shuf[inlen - 5]) - : ); + ); } /* Final fold. */ ----------------------------------------------------------------------- Summary of changes: cipher/crc-intel-pclmul.c | 62 +++++++++++++++++++++++------------------------ 1 file changed, 31 insertions(+), 31 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 ametzler at bebt.de Thu Apr 21 18:53:24 2016 From: ametzler at bebt.de (Andreas Metzler) Date: Thu, 21 Apr 2016 18:53:24 +0200 Subject: libgcrypt 1.7.0 segfault (libcrypt-gcrypt-perl) Message-ID: <20160421165324.GA1392@argenau.bebt.de> Hello, libcrypt-gcrypt-perl triggers a segfault in libgcrypt 1.7.0. This does not show with libgcrypt 1.6. Quoting Niko Tyni ---------------------------------------------- The failure can be triggered with this: % perl -MCrypt::GCrypt -e '$c=Crypt::GCrypt->new(type=>"cipher",algorithm=>"aes");$c->start("encrypting"); $c->encrypt("a").$c->finish' which gets a SIGSEGV in libgcrypt. Backtrace below. Adding a $c->setkey('whatever') before calling encrypt() makes it go away. The test isn't trying to do anything meaningful at that point, it's just checking that it gets a warning when not calling $c->finish() or something like that. Later tests of actual encrypting pass. Is this something to be fixed on the libgcrypt side? I guess I can come up with a C test case if needed, but maybe you can cook up one easier? The perl side setkey() just seems to wrap gcry_cipher_setkey(). Core was generated by `debugperl -Iblib/lib -Iblib/arch -MCrypt::GCrypt -e $c=Crypt::GCrypt->new(type='. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x0000000000000000 in ?? () (gdb) bt #0 0x0000000000000000 in ?? () #1 0x00007f5a5bce89c5 in _gcry_aes_cbc_enc (context=0x280a8e0, iv=0x280a6d0 "", outbuf_arg=, inbuf_arg=, nblocks=1, cbc_mac=0) at ../../cipher/rijndael.c:811 #2 0x00007f5a5bcc6565 in _gcry_cipher_cbc_encrypt (c=0x280a660, outbuf=outbuf at entry=0x27cf850 "a", '\017' , outbuflen=outbuflen at entry=16, inbuf=inbuf at entry=0x2840650 "a", '\017' , inbuflen=) at ../../cipher/cipher-cbc.c:65 #3 0x00007f5a5bcc5400 in cipher_encrypt (inbuflen=, inbuf=0x2840650 "a", '\017' , outbuflen=16, outbuf=0x27cf850 "a", '\017' , c=) at ../../cipher/cipher.c:826 #4 _gcry_cipher_encrypt (h=, out=out at entry=0x27cf850, outsize=outsize at entry=16, in=in at entry=0x2840650, inlen=, inlen at entry=16) at ../../cipher/cipher.c:913 #5 0x00007f5a5bcba91e in gcry_cipher_encrypt (h=, out=0x27cf850, outsize=16, in=0x2840650, inlen=16) at ../../src/visibility.c:828 #6 0x00007f5a5bfc1a53 in XS_Crypt__GCrypt_finish (my_perl=0x2785010, cv=0x27d47f0) at GCrypt.xs:439 #7 0x000000000050f456 in Perl_pp_entersub (my_perl=0x2785010) at pp_hot.c:3270 #8 0x00000000004da689 in Perl_runops_debug (my_perl=0x2785010) at dump.c:2234 #9 0x0000000000450e92 in S_run_body (oldscope=1, my_perl=0x2785010) at perl.c:2453 #10 perl_run (my_perl=0x2785010) at perl.c:2376 #11 0x000000000041d09b in main (argc=6, argv=0x7ffc0f9ebfe8, env=0x7ffc0f9ec020) at perlmain.c:116 ---------------------------------------------------------------- cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From gniibe at fsij.org Fri Apr 22 02:33:17 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 22 Apr 2016 09:33:17 +0900 Subject: libgcrypt 1.7.0 segfault (libcrypt-gcrypt-perl) In-Reply-To: <20160421165324.GA1392@argenau.bebt.de> References: <20160421165324.GA1392@argenau.bebt.de> Message-ID: <5719714D.6000606@fsij.org> On 04/22/2016 01:53 AM, Andreas Metzler wrote: > libcrypt-gcrypt-perl triggers a segfault in libgcrypt 1.7.0. This does > not show with libgcrypt 1.6. Thank you for the report. Err..., yes, it's a regression. Nevertheless, I ask you to change the use of libcrypt-gcrypt(-perl) so that it always call setkey before encryption, while libgcrypt will be fixed. Here is the detail... > % perl -MCrypt::GCrypt -e '$c=Crypt::GCrypt->new(type=>"cipher",algorithm=>"aes");$c->start("encrypting"); $c->encrypt("a").$c->finish' > > which gets a SIGSEGV in libgcrypt. Backtrace below. > > Adding a $c->setkey('whatever') before calling encrypt() makes it go > away. The test isn't trying to do anything meaningful at that point, > it's just checking that it gets a warning when not calling $c->finish() > or something like that. Later tests of actual encrypting pass. I see the scenario. Libgcrypt 1.7 assumes setkey is called before encryption. Let me explain the situation of libgcrypt. In the modification of libgcrypt 1.6 to 1.7, performance improvement with SSSE3 was introduced. Internally, it now has ctx->encrypt_fn. When setkey is called, ctx->encrypt_fn is configured at runtime. When setkey is not called, it will get SEGV at encryption as it's not initialized. > Is this something to be fixed on the libgcrypt side? I think it is better that segfault should be fixed. And documentation should be fixed to explicitly explain expected call sequences (the condition: setkey is required before encryption). For me, easier fix on the libgcrypt side would be: at encryption, let it return an error for not-initialized key (no setkey called before encryption). I don't think modification for encryption by ZERO (which was done in older libgcrypt) should be done to keep (undocumented?) backward compatibility. How do you think? -- From wk at gnupg.org Fri Apr 22 09:23:25 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 22 Apr 2016 09:23:25 +0200 Subject: libgcrypt 1.7.0 segfault (libcrypt-gcrypt-perl) In-Reply-To: <5719714D.6000606@fsij.org> (NIIBE Yutaka's message of "Fri, 22 Apr 2016 09:33:17 +0900") References: <20160421165324.GA1392@argenau.bebt.de> <5719714D.6000606@fsij.org> Message-ID: <87r3dy85ua.fsf@wheatstone.g10code.de> On Fri, 22 Apr 2016 02:33, gniibe at fsij.org said: > For me, easier fix on the libgcrypt side would be: > > at encryption, let it return an error for not-initialized key (no > setkey called before encryption). I concur. We do this at other places as well, for example in cipher-ocb.c: if (!c->marks.key) return GPG_ERR_INV_STATE; /* Key must have been set first. */ > I don't think modification for encryption by ZERO (which was done in > older libgcrypt) should be done to keep (undocumented?) backward > compatibility. If that was possible, it was clearly a bug. I do not see a problem to fix it. The fix may actually reveal improper use, for example always using a ZERO key instead of the desired key. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From liza.churkyn at sociomantic.com Tue Apr 26 12:31:04 2016 From: liza.churkyn at sociomantic.com (liza) Date: Tue, 26 Apr 2016 12:31:04 +0200 Subject: Libgcrypt CFB-mode as CFB-8bit In-Reply-To: <570F9E98.4070200@sociomantic.com> References: <570E1418.6060204@sociomantic.com> <87r3e9a400.fsf@wheatstone.g10code.de> <570F78F2.2070307@sociomantic.com> <877fg08ill.fsf@wheatstone.g10code.de> <570F9E98.4070200@sociomantic.com> Message-ID: <571F4368.1080209@sociomantic.com> Hello, I'm not sure whether I missed your answer :) So at the risk of repeating myself... will a patch to support CFB 8 bit be welcomed, or were you going to add it yourself? Thanks, Liza On 14/04/16 15:43, liza wrote: > Excellent. Did you want to do this yourself or would you like patches? > > I'm happy to do it, should just say this will be my first foray into > encryption code so I may have to come back for advice :) > > Liza > > On 14/04/16 14:45, Werner Koch wrote: >> On Thu, 14 Apr 2016 13:03,liza.churkyn at sociomantic.com said: >> >>> systems already use 8 bit CFB mode to encrypt some data they send and >>> they are not likely to change anytime soon. I had hoped to use gcrypt >>> to do the decryption and while it works for all the other algorithms >> It is too late for 1.7.0 to add this mode. Anyway, I just pushed a >> change which adds GCRY_CIPHER_MODE_CFB8 to prepare for an addition in >> 1.7.1 >> >> >> Shalom-Salam, >> >> Werner >> > > > > _______________________________________________ > Gcrypt-devel mailing list > Gcrypt-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gcrypt-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From cvs at cvs.gnupg.org Tue Apr 26 15:47:42 2016 From: cvs at cvs.gnupg.org (by Werner Koch) Date: Tue, 26 Apr 2016 15:47:42 +0200 Subject: [git] GCRYPT - branch, master, updated. libgcrypt-1.7.0-3-gee5a322 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 ee5a32226a7ca4ab067864e06623fc11a1768900 (commit) from 4545372c0f8dd35aef2a7abc12b588ed1a4a0363 (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 ee5a32226a7ca4ab067864e06623fc11a1768900 Author: Werner Koch Date: Tue Apr 26 15:46:30 2016 +0200 random: Try to use getrandom() instead of /dev/urandom (Linux only). * configure.ac: Check for syscall. * random/rndlinux.c [HAVE_SYSCALL]: Include sys/syscall.h. (_gcry_rndlinux_gather_random): Use getrandom is available. Signed-off-by: Werner Koch diff --git a/configure.ac b/configure.ac index 5f9f711..ad06dfd 100644 --- a/configure.ac +++ b/configure.ac @@ -1514,7 +1514,7 @@ AC_CHECK_FUNCS(strtoul memmove stricmp atexit raise) # Other checks AC_CHECK_FUNCS(strerror rand mmap getpagesize sysconf waitpid wait4) AC_CHECK_FUNCS(gettimeofday getrusage gethrtime clock_gettime syslog) -AC_CHECK_FUNCS(fcntl ftruncate flockfile) +AC_CHECK_FUNCS(syscall fcntl ftruncate flockfile) GNUPG_CHECK_MLOCK diff --git a/random/rndlinux.c b/random/rndlinux.c index 0cb65df..592b9ac 100644 --- a/random/rndlinux.c +++ b/random/rndlinux.c @@ -32,6 +32,10 @@ #include #include #include +#if defined(__linux__) && defined(HAVE_SYSCALL) +# include +#endif + #include "types.h" #include "g10lib.h" #include "rand-internal.h" @@ -232,6 +236,50 @@ _gcry_rndlinux_gather_random (void (*add)(const void*, size_t, } } + /* If we have a modern Linux kernel and we want to read from the + * the non-blocking /dev/urandom, we first try to use the new + * getrandom syscall. That call guarantees that the kernel's + * RNG has been properly seeded before returning any data. This + * is different from /dev/urandom which may, due to its + * non-blocking semantics, return data even if the kernel has + * not been properly seeded. Unfortunately we need to use a + * syscall and not a new device and thus we are not able to use + * select(2) to have a timeout. */ +#if defined(__linux__) && defined(HAVE_SYSCALL) && defined(__NR_getrandom) + if (fd == fd_urandom) + { + long ret; + size_t nbytes; + + do + { + nbytes = length < sizeof(buffer)? length : sizeof(buffer); + if (nbytes > 256) + nbytes = 256; + ret = syscall (__NR_getrandom, + (void*)buffer, (size_t)nbytes, (unsigned int)0); + } + while (ret == -1 && errno == EINTR); + if (ret == -1 && errno == ENOSYS) + ; /* The syscall is not supported - fallback to /dev/urandom. */ + else + { /* The syscall is supported. Some sanity checks. */ + if (ret == -1) + log_fatal ("unexpected error from getrandom: %s\n", + strerror (errno)); + else if (ret != nbytes) + log_fatal ("getrandom returned only" + " %ld of %zu requested bytes\n", ret, nbytes); + + log_debug ("getrandom returned %zu requested bytes\n", nbytes); + (*add)(buffer, nbytes, origin); + length -= nbytes; + continue; /* until LENGTH is zero. */ + } + log_debug ("syscall(getrandom) not supported; errno = %d\n", errno); + } +#endif + do { size_t nbytes; ----------------------------------------------------------------------- Summary of changes: configure.ac | 2 +- random/rndlinux.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 49 insertions(+), 1 deletion(-) 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 wk at gnupg.org Tue Apr 26 16:00:42 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 26 Apr 2016 16:00:42 +0200 Subject: Libgcrypt CFB-mode as CFB-8bit In-Reply-To: <571F4368.1080209@sociomantic.com> (liza's message of "Tue, 26 Apr 2016 12:31:04 +0200") References: <570E1418.6060204@sociomantic.com> <87r3e9a400.fsf@wheatstone.g10code.de> <570F78F2.2070307@sociomantic.com> <877fg08ill.fsf@wheatstone.g10code.de> <570F9E98.4070200@sociomantic.com> <571F4368.1080209@sociomantic.com> Message-ID: <87k2jktqph.fsf@wheatstone.g10code.de> On Tue, 26 Apr 2016 12:31, liza.churkyn at sociomantic.com said: > I'm not sure whether I missed your answer :) So at the risk of > repeating myself... will a patch to support CFB 8 bit be welcomed, or [I hoped someone else would answer first ;-)] I would certainly accept a proper patch. However, given that you are new to Libgcrypt it may need some time until we have answered your questions and got the patch into a proper shape. Given all the other open tasks, I doubt that gniibe or me will be able to write that in the near future. Thus, even if it takes longer for you, it will be faster than if you wait for us. Master and also 1.7.0 already have a GCRY_CIPHER_MODE_CFB8 constant and thus we only need the implementation. Please do not try to extend any of the asm optimized bulk modes for CFB8 - the plain standard implementation in cipher-cfb.c will be preferred. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From buraphalinuxserver at gmail.com Wed Apr 27 03:42:39 2016 From: buraphalinuxserver at gmail.com (Somchai Smythe) Date: Wed, 27 Apr 2016 08:42:39 +0700 Subject: libgcrypt-1.7 fails self-test for all 'basic' with 'Checksum error' (log attached) Message-ID: Note: If replying to mailing list please cc me since I'm not subscribed. + LINGUAS='en th' + CC='gcc -std=gnu11' + CFLAGS='-O3 -m64 -march=x86-64 -mtune=generic -pipe' + ./configure --prefix=/usr --mandir=/usr/man --infodir=/usr/info --sysconfdir=/etc --disable-static --with-pic checking for a BSD-compatible install... /usr/bin/ginstall -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking whether to enable maintainer-specific portions of Makefiles... no checking whether make supports nested variables... (cached) yes checking whether make sets $(MAKE)... (cached) yes checking for gcc... gcc -std=gnu11 checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc -std=gnu11 accepts -g... yes checking for gcc -std=gnu11 option to accept ISO C89... none needed checking whether gcc -std=gnu11 understands -c and -o together... yes checking for style of include used by make... GNU checking dependency style of gcc -std=gnu11... gcc3 checking how to run the C preprocessor... gcc -std=gnu11 -E checking dependency style of gcc -std=gnu11... gcc3 checking for library containing strerror... none required checking for gawk... (cached) gawk checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking minix/config.h usability... no checking minix/config.h presence... no checking for minix/config.h... no checking whether it is safe to define __EXTENSIONS__... yes checking for cc for build... gcc -std=gnu11 checking how to print strings... printf checking for a sed that does not truncate output... /bin/sed checking for fgrep... /bin/grep -F checking for ld used by gcc -std=gnu11... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 3458764513820540925 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... yes checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop checking for /usr/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for dlltool... no checking how to associate runtime and link libraries... printf %s\n checking for ar... ar checking for archiver @FILE support... @ checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm -B output from gcc -std=gnu11 object... ok checking for sysroot... no checking for mt... mt checking if mt is a manifest tool... no checking for dlfcn.h... yes checking for objdir... .libs checking if gcc -std=gnu11 supports -fno-rtti -fno-exceptions... no checking for gcc -std=gnu11 option to produce PIC... -fPIC -DPIC checking if gcc -std=gnu11 PIC flag -fPIC -DPIC works... yes checking if gcc -std=gnu11 static flag -static works... yes checking if gcc -std=gnu11 supports -c -o file.o... yes checking if gcc -std=gnu11 supports -c -o file.o... (cached) yes checking whether the gcc -std=gnu11 linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for windres... no checking whether byte ordering is bigendian... no checking size of unsigned short... 2 checking size of unsigned int... 4 checking size of unsigned long... 8 checking size of unsigned long long... 8 checking size of void *... 8 checking for uintptr_t... yes checking for UINT64_C... yes checking size of uint64_t... 8 checking which symmetric ciphers to include... arcfour blowfish cast5 des aes twofish serpent rfc2268 seed camellia idea salsa20 gost28147 chacha20 checking which public-key ciphers to include... dsa elgamal rsa ecc checking which message digests to include... crc gostr3411-94 md4 md5 rmd160 sha1 sha256 sha512 sha3 tiger whirlpool stribog checking which key derivation functions to include... s2k pkdf2 scrypt checking which random module to use... default checking whether use of /dev/random is requested... yes checking whether the experimental random daemon is requested... no checking whether MPI assembler modules are requested... yes checking whether memory guard is requested... no checking whether to run large data tests... no checking whether use of capabilities is requested... no checking whether a HMAC binary check is requested... no checking whether padlock support is requested... yes checking whether AESNI support is requested... yes checking whether PCLMUL support is requested... yes checking whether DRNG support is requested... yes checking whether AVX support is requested... yes checking whether AVX2 support is requested... yes checking whether NEON support is requested... yes checking whether a -O flag munging is requested... yes checking whether to enable AMD64 as(1) feature detection... yes checking for gpg-error-config... /usr/bin/gpg-error-config checking for GPG Error - version >= 1.13... yes (1.21) checking for pthread_create in -lpthread... yes checking for library containing setsockopt... none required checking for library containing setsockopt... (cached) none required checking for ANSI C header files... (cached) yes checking for unistd.h... (cached) yes checking sys/select.h usability... yes checking sys/select.h presence... yes checking for sys/select.h... yes checking sys/msg.h usability... yes checking sys/msg.h presence... yes checking for sys/msg.h... yes checking for an ANSI C-conforming const... yes checking for inline... inline checking for size_t... yes checking return type of signal handlers... void checking whether sys_siglist is declared... yes checking for pid_t... yes checking for byte typedef... no checking for ushort typedef... yes checking for ulong typedef... yes checking for u16 typedef... no checking for u32 typedef... no checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes checking for socklen_t... yes checking for __builtin_bswap32... yes checking for __builtin_bswap64... yes checking for __builtin_ctz... yes checking whether the variable length arrays are supported... yes checking whether the visibility attribute is supported... yes checking for broken visibility attribute... no checking for broken alias attribute... no checking if gcc supports -fvisibility=hidden... yes checking whether the GCC style aligned attribute is supported... yes checking whether the GCC style packed attribute is supported... yes checking whether 'asm' assembler keyword is supported... yes checking whether '__asm__' assembler keyword is supported... yes checking whether inline assembly memory barrier is supported... yes checking whether GCC assembler is compatible for ARM assembly implementations... no checking for _ prefix in compiled symbols... no checking architecture and mpi assembler functions... x86 checking whether compiler supports 'ms_abi' function attribute... yes checking whether compiler supports 'sysv_abi' function attribute... yes checking whether default calling convention is 'ms_abi'... no checking whether default calling convention is 'sysv_abi'... yes checking whether GCC inline assembler supports SSSE3 instructions... yes checking whether GCC inline assembler supports PCLMUL instructions... yes checking whether GCC inline assembler supports AVX instructions... yes checking whether GCC inline assembler supports AVX2 instructions... yes checking whether GCC inline assembler supports BMI2 instructions... yes checking whether GCC assembler handles division correctly... yes checking whether GCC assembler is compatible for amd64 assembly implementations... yes checking whether GCC assembler is compatible for Intel syntax assembly implementations... yes checking whether compiler is configured for ARMv6 or newer architecture... n/a checking whether GCC inline assembler supports NEON instructions... n/a checking for vprintf... yes checking for _doprnt... no checking for stpcpy... yes checking for strcasecmp... yes checking for strtoul... yes checking for memmove... yes checking for stricmp... no checking for atexit... yes checking for raise... yes checking for strerror... yes checking for rand... yes checking for mmap... yes checking for getpagesize... yes checking for sysconf... yes checking for waitpid... yes checking for wait4... yes checking for gettimeofday... yes checking for getrusage... yes checking for gethrtime... no checking for clock_gettime... yes checking for syslog... yes checking for fcntl... yes checking for ftruncate... yes checking for flockfile... yes checking for mlock... yes checking for sysconf... (cached) yes checking for getpagesize... (cached) yes checking whether mlock is broken... no checking for getpid... yes checking for clock... yes checking for random device... yes checking whether non excutable stack support is requested... yes checking whether assembler supports --noexecstack option... yes checking that generated files are newer than configure... done configure: creating ./config.status config.status: creating Makefile config.status: creating m4/Makefile config.status: creating compat/Makefile config.status: creating mpi/Makefile config.status: creating cipher/Makefile config.status: creating random/Makefile config.status: creating doc/Makefile config.status: creating src/Makefile config.status: creating src/gcrypt.h config.status: creating src/libgcrypt-config config.status: creating src/versioninfo.rc config.status: creating tests/Makefile config.status: creating tests/hashtest-256g config.status: creating config.h config.status: linking mpi/amd64/mpih-add1.S to mpi/mpih-add1-asm.S config.status: linking mpi/amd64/mpih-sub1.S to mpi/mpih-sub1-asm.S config.status: linking mpi/amd64/mpih-mul1.S to mpi/mpih-mul1-asm.S config.status: linking mpi/amd64/mpih-mul2.S to mpi/mpih-mul2-asm.S config.status: linking mpi/amd64/mpih-mul3.S to mpi/mpih-mul3-asm.S config.status: linking mpi/amd64/mpih-lshift.S to mpi/mpih-lshift-asm.S config.status: linking mpi/amd64/mpih-rshift.S to mpi/mpih-rshift-asm.S config.status: linking mpi/generic/mpi-asm-defs.h to mpi/mpi-asm-defs.h config.status: executing depfiles commands config.status: executing libtool commands config.status: executing gcrypt-conf commands Libgcrypt v1.7.0 has been configured as follows: Platform: GNU/Linux (x86_64-unknown-linux-gnu) Hardware detection module: hwf-x86 Enabled cipher algorithms: arcfour blowfish cast5 des aes twofish serpent rfc2268 seed camellia idea salsa20 gost28147 chacha20 Enabled digest algorithms: crc gostr3411-94 md4 md5 rmd160 sha1 sha256 sha512 sha3 tiger whirlpool stribog Enabled kdf algorithms: s2k pkdf2 scrypt Enabled pubkey algorithms: dsa elgamal rsa ecc Random number generator: default Using linux capabilities: no Try using Padlock crypto: yes Try using AES-NI crypto: yes Try using Intel PCLMUL: yes Try using DRNG (RDRAND): yes Try using Intel AVX: yes Try using Intel AVX2: yes Try using ARM NEON: n/a Then a normal build with a few warnings. Then make check fails like this: + make check Making check in compat make[1]: Entering directory '/home/tmp/libgcrypt-1.7.0/compat' make[1]: Nothing to be done for 'check'. make[1]: Leaving directory '/home/tmp/libgcrypt-1.7.0/compat' Making check in mpi make[1]: Entering directory '/home/tmp/libgcrypt-1.7.0/mpi' make[1]: Nothing to be done for 'check'. make[1]: Leaving directory '/home/tmp/libgcrypt-1.7.0/mpi' Making check in cipher make[1]: Entering directory '/home/tmp/libgcrypt-1.7.0/cipher' make[1]: Nothing to be done for 'check'. make[1]: Leaving directory '/home/tmp/libgcrypt-1.7.0/cipher' Making check in random make[1]: Entering directory '/home/tmp/libgcrypt-1.7.0/random' make[1]: Nothing to be done for 'check'. make[1]: Leaving directory '/home/tmp/libgcrypt-1.7.0/random' Making check in src make[1]: Entering directory '/home/tmp/libgcrypt-1.7.0/src' make[1]: Nothing to be done for 'check'. make[1]: Leaving directory '/home/tmp/libgcrypt-1.7.0/src' Making check in doc make[1]: Entering directory '/home/tmp/libgcrypt-1.7.0/doc' make check-am make[2]: Entering directory '/home/tmp/libgcrypt-1.7.0/doc' make[2]: Nothing to be done for 'check-am'. make[2]: Leaving directory '/home/tmp/libgcrypt-1.7.0/doc' make[1]: Leaving directory '/home/tmp/libgcrypt-1.7.0/doc' Making check in tests make[1]: Entering directory '/home/tmp/libgcrypt-1.7.0/tests' make check-TESTS make[2]: Entering directory '/home/tmp/libgcrypt-1.7.0/tests' version:1.7.0: ciphers:arcfour:blowfish:cast5:des:aes:twofish:serpent:rfc2268:seed:camellia:idea:salsa20:gost28147:chacha20: pubkeys:dsa:elgamal:rsa:ecc: digests:crc:gostr3411-94::md4:md5:rmd160:sha1:sha256:sha512:sha3:tiger:whirlpool:stribog: rnd-mod:linux: cpu-arch:x86: mpi-asm:amd64/mpih-add1.S:amd64/mpih-sub1.S:amd64/mpih-mul1.S:amd64/mpih-mul2.S:amd64/mpih-mul3.S:amd64/mpih-lshift.S:amd64/mpih-rshift.S: hwflist:intel-cpu:intel-fast-shld:intel-bmi2:intel-ssse3:intel-sse4.1:intel-pclmul:intel-aesni:intel-rdrand:intel-avx:intel-avx2: fips-mode:n:n: rng-type:standard:1: PASS: version PASS: mpitests PASS: t-sexp PASS: t-convert PASS: t-mpi-bit PASS: t-mpi-point PASS: curves PASS: t-lock PASS: prime expected: 28 23 38 45 2b fd 42 45 43 64 7e 67 7f f4 8b cd computed: 02 c3 67 44 93 ce 3f 19 dc d4 17 f0 22 9c e3 c6 cipher-ocb, encrypt tag mismatch (large, algo 310) cipher-ocb, gcry_cipher_checktag failed (large, algo 310): Checksum error expected: 28 23 38 45 2b fd 42 45 43 64 7e 67 7f f4 8b cd computed: 02 c3 67 44 93 ce 3f 19 dc d4 17 f0 22 9c e3 c6 cipher-ocb, encrypt tag mismatch (large, algo 310) cipher-ocb, gcry_cipher_checktag failed (large, algo 310): Checksum error expected: 28 23 38 45 2b fd 42 45 43 64 7e 67 7f f4 8b cd computed: 02 c3 67 44 93 ce 3f 19 dc d4 17 f0 22 9c e3 c6 cipher-ocb, encrypt tag mismatch (large, algo 310) cipher-ocb, gcry_cipher_checktag failed (large, algo 310): Checksum error expected: 28 23 38 45 2b fd 42 45 43 64 7e 67 7f f4 8b cd computed: 02 c3 67 44 93 ce 3f 19 dc d4 17 f0 22 9c e3 c6 cipher-ocb, encrypt tag mismatch (large, algo 310) cipher-ocb, gcry_cipher_checktag failed (large, algo 310): Checksum error expected: ee ca e5 39 27 2d 33 e7 79 74 b0 1d 37 12 d5 6c computed: 20 b9 b8 3e 07 af de e6 12 16 42 56 6c ab 55 c8 cipher-ocb, encrypt tag mismatch (large, algo 311) cipher-ocb, gcry_cipher_checktag failed (large, algo 311): Checksum error expected: ee ca e5 39 27 2d 33 e7 79 74 b0 1d 37 12 d5 6c computed: 20 b9 b8 3e 07 af de e6 12 16 42 56 6c ab 55 c8 cipher-ocb, encrypt tag mismatch (large, algo 311) cipher-ocb, gcry_cipher_checktag failed (large, algo 311): Checksum error expected: ee ca e5 39 27 2d 33 e7 79 74 b0 1d 37 12 d5 6c computed: 20 b9 b8 3e 07 af de e6 12 16 42 56 6c ab 55 c8 cipher-ocb, encrypt tag mismatch (large, algo 311) cipher-ocb, gcry_cipher_checktag failed (large, algo 311): Checksum error expected: ee ca e5 39 27 2d 33 e7 79 74 b0 1d 37 12 d5 6c computed: 20 b9 b8 3e 07 af de e6 12 16 42 56 6c ab 55 c8 cipher-ocb, encrypt tag mismatch (large, algo 311) cipher-ocb, gcry_cipher_checktag failed (large, algo 311): Checksum error expected: 39 39 d0 2d 05 68 74 ee 18 6b ea 3d 0b d3 58 ae computed: bc d9 bd f2 bc eb e2 4c 38 0e 78 8c af 9e d0 3c cipher-ocb, encrypt tag mismatch (large, algo 312) cipher-ocb, gcry_cipher_checktag failed (large, algo 312): Checksum error expected: 39 39 d0 2d 05 68 74 ee 18 6b ea 3d 0b d3 58 ae computed: bc d9 bd f2 bc eb e2 4c 38 0e 78 8c af 9e d0 3c cipher-ocb, encrypt tag mismatch (large, algo 312) cipher-ocb, gcry_cipher_checktag failed (large, algo 312): Checksum error expected: 39 39 d0 2d 05 68 74 ee 18 6b ea 3d 0b d3 58 ae computed: bc d9 bd f2 bc eb e2 4c 38 0e 78 8c af 9e d0 3c cipher-ocb, encrypt tag mismatch (large, algo 312) cipher-ocb, gcry_cipher_checktag failed (large, algo 312): Checksum error expected: 39 39 d0 2d 05 68 74 ee 18 6b ea 3d 0b d3 58 ae computed: bc d9 bd f2 bc eb e2 4c 38 0e 78 8c af 9e d0 3c cipher-ocb, encrypt tag mismatch (large, algo 312) cipher-ocb, gcry_cipher_checktag failed (large, algo 312): Checksum error expected: 3c fb 66 14 3c c8 6c 67 26 b8 23 eb af 43 98 69 computed: c9 d3 37 c8 c0 eb dc 5c 6b f5 ff 55 31 89 e1 32 cipher-ocb, encrypt tag mismatch (large, algo 304) cipher-ocb, gcry_cipher_checktag failed (large, algo 304): Checksum error expected: 3c fb 66 14 3c c8 6c 67 26 b8 23 eb af 43 98 69 computed: c9 d3 37 c8 c0 eb dc 5c 6b f5 ff 55 31 89 e1 32 cipher-ocb, encrypt tag mismatch (large, algo 304) cipher-ocb, gcry_cipher_checktag failed (large, algo 304): Checksum error expected: 3c fb 66 14 3c c8 6c 67 26 b8 23 eb af 43 98 69 computed: c9 d3 37 c8 c0 eb dc 5c 6b f5 ff 55 31 89 e1 32 cipher-ocb, encrypt tag mismatch (large, algo 304) cipher-ocb, gcry_cipher_checktag failed (large, algo 304): Checksum error expected: 3c fb 66 14 3c c8 6c 67 26 b8 23 eb af 43 98 69 computed: c9 d3 37 c8 c0 eb dc 5c 6b f5 ff 55 31 89 e1 32 cipher-ocb, encrypt tag mismatch (large, algo 304) cipher-ocb, gcry_cipher_checktag failed (large, algo 304): Checksum error expected: 5e 62 27 c5 32 c3 1d e6 2e 65 e7 d6 fb 05 d7 b2 computed: fd cc 11 3a 3e 80 a8 2e ad f9 2e ee 31 35 5d 5a cipher-ocb, encrypt tag mismatch (large, algo 305) cipher-ocb, gcry_cipher_checktag failed (large, algo 305): Checksum error expected: 5e 62 27 c5 32 c3 1d e6 2e 65 e7 d6 fb 05 d7 b2 computed: fd cc 11 3a 3e 80 a8 2e ad f9 2e ee 31 35 5d 5a cipher-ocb, encrypt tag mismatch (large, algo 305) cipher-ocb, gcry_cipher_checktag failed (large, algo 305): Checksum error expected: 5e 62 27 c5 32 c3 1d e6 2e 65 e7 d6 fb 05 d7 b2 computed: fd cc 11 3a 3e 80 a8 2e ad f9 2e ee 31 35 5d 5a cipher-ocb, encrypt tag mismatch (large, algo 305) cipher-ocb, gcry_cipher_checktag failed (large, algo 305): Checksum error expected: 5e 62 27 c5 32 c3 1d e6 2e 65 e7 d6 fb 05 d7 b2 computed: fd cc 11 3a 3e 80 a8 2e ad f9 2e ee 31 35 5d 5a cipher-ocb, encrypt tag mismatch (large, algo 305) cipher-ocb, gcry_cipher_checktag failed (large, algo 305): Checksum error expected: e7 8b e6 d4 2f 7a 36 4c ba ee 20 e2 68 f4 cb cc computed: ff b9 14 87 51 21 71 82 c0 17 e4 a5 f8 ac 9f cd cipher-ocb, encrypt tag mismatch (large, algo 306) cipher-ocb, gcry_cipher_checktag failed (large, algo 306): Checksum error expected: e7 8b e6 d4 2f 7a 36 4c ba ee 20 e2 68 f4 cb cc computed: ff b9 14 87 51 21 71 82 c0 17 e4 a5 f8 ac 9f cd cipher-ocb, encrypt tag mismatch (large, algo 306) cipher-ocb, gcry_cipher_checktag failed (large, algo 306): Checksum error expected: e7 8b e6 d4 2f 7a 36 4c ba ee 20 e2 68 f4 cb cc computed: ff b9 14 87 51 21 71 82 c0 17 e4 a5 f8 ac 9f cd cipher-ocb, encrypt tag mismatch (large, algo 306) cipher-ocb, gcry_cipher_checktag failed (large, algo 306): Checksum error expected: e7 8b e6 d4 2f 7a 36 4c ba ee 20 e2 68 f4 cb cc computed: ff b9 14 87 51 21 71 82 c0 17 e4 a5 f8 ac 9f cd cipher-ocb, encrypt tag mismatch (large, algo 306) cipher-ocb, gcry_cipher_checktag failed (large, algo 306): Checksum error FAIL: basic and the rest passes. I tried on a home-built system (LFS derived) and got the failure, so tried again on an up-to-date Ubuntu 16.04 system and got identical results (the failure). I'm on an adm64 platform if it matters. Full 'make check' output from Ubuntu 16.04 system attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: log Type: application/octet-stream Size: 44282 bytes Desc: not available URL: From wk at gnupg.org Wed Apr 27 12:41:20 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 27 Apr 2016 12:41:20 +0200 Subject: libgcrypt-1.7 fails self-test for all 'basic' with 'Checksum error' (log attached) In-Reply-To: (Somchai Smythe's message of "Wed, 27 Apr 2016 08:42:39 +0700") References: Message-ID: <87twinpc4v.fsf@wheatstone.g10code.de> On Wed, 27 Apr 2016 03:42, buraphalinuxserver at gmail.com said: > + LINGUAS='en th' > + CC='gcc -std=gnu11' > + CFLAGS='-O3 -m64 -march=x86-64 -mtune=generic -pipe' > + ./configure --prefix=/usr --mandir=/usr/man --infodir=/usr/info > --sysconfdir=/etc --disable-static --with-pic It seems that the '+' shall indicate that this is one long line, right? You should not run configure in this way, but put the envar settings on the ./configure command line so that configure can track them, To track down the problem, build again without modified CFLAGS and then add more options until you see the error again. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From buraphalinuxserver at gmail.com Thu Apr 28 10:31:12 2016 From: buraphalinuxserver at gmail.com (Somchai Smythe) Date: Thu, 28 Apr 2016 15:31:12 +0700 Subject: libgcrypt-1.7 fails self-test for all 'basic' with 'Checksum error' (log attached) In-Reply-To: <87twinpc4v.fsf@wheatstone.g10code.de> References: <87twinpc4v.fsf@wheatstone.g10code.de> Message-ID: -O3 seems to trigger the problem. Gmail will often mangle long lines, but this should still be enough for you to see the problems. This works: ./configure \ --prefix=/usr \ --mandir=/usr/man \ --infodir=/usr/info \ --sysconfdir=/etc \ --disable-static \ --with-pic \ CC='gcc -std=gnu11' \ CFLAGS='-O3 -fno-strict-aliasing -m64 -march=x86-64 -mtune=generic -pipe' This fails: ./configure \ --prefix=/usr \ --mandir=/usr/man \ --infodir=/usr/info \ --sysconfdir=/etc \ --disable-static \ --with-pic \ CC='gcc -std=gnu11' \ CFLAGS='-O3 -m64 -march=x86-64 -mtune=generic -pipe' This shows an aliasing issue that may be related to the problem: ./configure \ --prefix=/usr \ --mandir=/usr/man \ --infodir=/usr/info \ --sysconfdir=/etc \ --disable-static \ --with-pic \ CC='gcc -std=gnu11' \ CFLAGS='-O3 -Wall -fstrict-aliasing -Wstrict-aliasing=1 -m64 -march=x86-64 -mtune=generic -pipe' .... /bin/bash ../libtool --tag=CC --mode=compile gcc -std=gnu11 -DHAVE_CONFIG_H -I. -I.. -O3 -Wall -fstrict-aliasing -Wstrict-aliasing=1 -m64 libtool: compile: gcc -std=gnu11 -DHAVE_CONFIG_H -I. -I.. -O3 -Wall -fstrict-aliasing -Wstrict-aliasing=1 -m64 -march=x86-64 -mtune=generic -pip sexp.c: In function '_gcry_sexp_vextract_param': sexp.c:2333:19: warning: dereferencing type-punned pointer might break strict-aliasing rules [-Wstrict-aliasing] gcry_buffer_t *spec = (gcry_buffer_t*)array[idx]; ^ sexp.c:2353:19: warning: dereferencing type-punned pointer might break strict-aliasing rules [-Wstrict-aliasing] gcry_buffer_t *spec = (gcry_buffer_t*)array[idx]; ^ sexp.c:2421:11: warning: dereferencing type-punned pointer might break strict-aliasing rules [-Wstrict-aliasing] gcry_buffer_t *spec = (gcry_buffer_t*)array[idx]; ^ sexp.c:2427:11: warning: dereferencing type-punned pointer might break strict-aliasing rules [-Wstrict-aliasing] gcry_buffer_t *spec = (gcry_buffer_t*)array[idx]; ^ .... The compiler in use: gcc --version gcc (Ubuntu 5.3.1-14ubuntu2) 5.3.1 20160413 On 4/27/16, Werner Koch wrote: > On Wed, 27 Apr 2016 03:42, buraphalinuxserver at gmail.com said: > >> + LINGUAS='en th' >> + CC='gcc -std=gnu11' >> + CFLAGS='-O3 -m64 -march=x86-64 -mtune=generic -pipe' >> + ./configure --prefix=/usr --mandir=/usr/man --infodir=/usr/info >> --sysconfdir=/etc --disable-static --with-pic > > It seems that the '+' shall indicate that this is one long line, right? > You should not run configure in this way, but put the envar settings on > the ./configure command line so that configure can track them, > > To track down the problem, build again without modified CFLAGS and then > add more options until you see the error again. > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > From wk at gnupg.org Thu Apr 28 11:07:55 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 28 Apr 2016 11:07:55 +0200 Subject: libgcrypt-1.7 fails self-test for all 'basic' with 'Checksum error' (log attached) In-Reply-To: (Somchai Smythe's message of "Thu, 28 Apr 2016 15:31:12 +0700") References: <87twinpc4v.fsf@wheatstone.g10code.de> Message-ID: <877ffim784.fsf@wheatstone.g10code.de> On Thu, 28 Apr 2016 10:31, buraphalinuxserver at gmail.com said: > -O3 seems to trigger the problem. Gmail will often mangle long lines, > but this should still be enough for you to see the problems. Thanks. Can you please try with another gcc version? > This shows an aliasing issue that may be related to the problem: > sexp.c: In function '_gcry_sexp_vextract_param': No this is not related. The tests fail in cipher-ocb where we do not use any s-expression code. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From jussi.kivilinna at iki.fi Thu Apr 28 17:09:52 2016 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Thu, 28 Apr 2016 18:09:52 +0300 Subject: libgcrypt-1.7 fails self-test for all 'basic' with 'Checksum error' (log attached) In-Reply-To: <877ffim784.fsf@wheatstone.g10code.de> References: <87twinpc4v.fsf@wheatstone.g10code.de> <877ffim784.fsf@wheatstone.g10code.de> Message-ID: <572227C0.4030107@iki.fi> Hello, On 28.04.2016 12:07, Werner Koch wrote: > On Thu, 28 Apr 2016 10:31, buraphalinuxserver at gmail.com said: >> -O3 seems to trigger the problem. Gmail will often mangle long lines, >> but this should still be enough for you to see the problems. > > Thanks. Can you please try with another gcc version? > Looks as this is caused by some compiler error. I reproduced this with gcc-5.3 on Ubuntu 16.04. With -O3 optimization level, gcc inlines _gcry_cipher_ocb_get_l, double_block_cpy and double_block to _gcry_cipher_ocb_authenticate. Inlined double_block_cpy/double_block for main ocb_authentication loop (on line ~306-308) look as: ++ tail of _gcry_cipher_ocb_get_l inlined into _gcry_cipher_ocb_authenticate: ++ start double_block_cpy: >> double_block_cpy (l_tmp, c->u_mode.ocb.L[OCB_L_TABLE_SIZE - 1]); c2f: 4c 39 64 24 08 cmp %r12,0x8(%rsp) c34: 74 18 je c4e <_gcry_cipher_ocb_authenticate+0x34e> c36: 48 8b b3 c0 01 00 00 mov 0x1c0(%rbx),%rsi c3d: 48 8b bb c8 01 00 00 mov 0x1c8(%rbx),%rdi c44: 48 89 74 24 10 mov %rsi,0x10(%rsp) c49: 48 89 7c 24 18 mov %rdi,0x18(%rsp) c4e: 48 8b 7c 24 10 mov 0x10(%rsp),%rdi c53: 48 8b 74 24 18 mov 0x18(%rsp),%rsi c58: 48 0f cf bswap %rdi c5b: 48 0f ce bswap %rsi c5e: 4c 8d 0c 3f lea (%rdi,%rdi,1),%r9 c62: 48 89 f2 mov %rsi,%rdx c65: 48 c1 ff 3f sar $0x3f,%rdi c69: 48 c1 ea 3f shr $0x3f,%rdx c6d: 81 e7 87 00 00 00 and $0x87,%edi c73: 48 01 f6 add %rsi,%rsi c76: 4c 31 ca xor %r9,%rdx c79: 48 31 fe xor %rdi,%rsi c7c: 85 c0 test %eax,%eax c7e: 48 0f ca bswap %rdx c81: 48 0f ce bswap %rsi >> here new block generated in double_block_cpy is stored to stack (variable l_tmp): c84: 48 89 54 24 10 mov %rdx,0x10(%rsp) c89: 48 89 74 24 18 mov %rsi,0x18(%rsp) -- end double_block_cpy ++ start double_block loop of _gcry_cipher_ocb_get_l >> for (ntz -= OCB_L_TABLE_SIZE; ntz; ntz--) >> double_block (l_tmp); c8e: 74 32 je cc2 <_gcry_cipher_ocb_authenticate+0x3c2> c90: 48 89 d7 mov %rdx,%rdi c93: 48 0f ce bswap %rsi c96: 48 0f cf bswap %rdi c99: 48 89 f2 mov %rsi,%rdx c9c: 48 01 f6 add %rsi,%rsi c9f: 4c 8d 0c 3f lea (%rdi,%rdi,1),%r9 ca3: 48 c1 ff 3f sar $0x3f,%rdi ca7: 48 c1 ea 3f shr $0x3f,%rdx cab: 81 e7 87 00 00 00 and $0x87,%edi cb1: 4c 31 ca xor %r9,%rdx cb4: 48 31 fe xor %rdi,%rsi cb7: 83 e8 01 sub $0x1,%eax >> in double_block loop, new block generated is _not_ stored to stack, which seems to cause OCB to fail. cba: 48 0f ca bswap %rdx cbd: 48 0f ce bswap %rsi cc0: 75 ce jne c90 <_gcry_cipher_ocb_authenticate+0x390> -- end double_block loop >> return l_tmp; cc2: 4c 89 e0 mov %r12,%rax cc5: e9 2e fe ff ff jmpq af8 <_gcry_cipher_ocb_authenticate+0x1f8> -- returning jump from inlined _gcry_cipher_ocb_get_l, %rax has pointer to l_tmp variable. %rdx holds first 64-bit half of new block and %rsi the second half. Target of jump is on line 307 of cipher-ocb.c: buf_xor_1 (c->u_mode.ocb.aad_offset, >> ocb_get_l (c, l_tmp, c->u_mode.ocb.aad_nblocks), OCB_BLOCK_LEN); >> Xoring c->u_mode.ocb.aad_offset[0..63-bit] to L[0..63-bit]. Ok as %rdx is preloaded with first 64-bits of L block in each code path jumping at : af8: 48 33 93 e0 01 00 00 xor 0x1e0(%rbx),%rdx aff: 49 83 ed 10 sub $0x10,%r13 >> Overwriting %rsi, loses second half of L block computed in double_block loop: b03: 4c 89 e6 mov %r12,%rsi b06: 48 8b 3c 24 mov (%rsp),%rdi b0a: 49 83 c6 10 add $0x10,%r14 b0e: 48 89 93 e0 01 00 00 mov %rdx,0x1e0(%rbx) >> Tries to load second half of L block from stack for xoring. All other code-paths have stored second half to l_tmp stack variable but this was not done in double_block loop: b15: 48 8b 40 08 mov 0x8(%rax),%rax b19: 48 33 83 e8 01 00 00 xor 0x1e8(%rbx),%rax b20: 48 89 83 e8 01 00 00 mov %rax,0x1e8(%rbx) b27: 49 33 46 f8 xor -0x8(%r14),%rax b2b: 49 33 56 f0 xor -0x10(%r14),%rdx b2f: 48 89 44 24 18 mov %rax,0x18(%rsp) b34: 48 8b 43 18 mov 0x18(%rbx),%rax b38: 48 89 54 24 10 mov %rdx,0x10(%rsp) b3d: 4c 89 e2 mov %r12,%rdx b40: ff 50 40 callq *0x40(%rax) b43: 48 8b 44 24 10 mov 0x10(%rsp),%rax b48: 48 31 83 f0 01 00 00 xor %rax,0x1f0(%rbx) b4f: 48 8b 44 24 18 mov 0x18(%rsp),%rax b54: 48 31 83 f8 01 00 00 xor %rax,0x1f8(%rbx) Simple workaround that avoid this is to add __attribute__((noinline)) for _gcry_cipher_ocb_get_l to prevent inlining inside cipher-ocb.c. -Jussi >> This shows an aliasing issue that may be related to the problem: > > >> sexp.c: In function '_gcry_sexp_vextract_param': > > No this is not related. The tests fail in cipher-ocb where we do not > use any s-expression code. > > > Salam-Shalom, > > Werner > From wk at gnupg.org Fri Apr 29 08:30:05 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 29 Apr 2016 08:30:05 +0200 Subject: libgcrypt-1.7 fails self-test for all 'basic' with 'Checksum error' (log attached) In-Reply-To: <572227C0.4030107@iki.fi> (Jussi Kivilinna's message of "Thu, 28 Apr 2016 18:09:52 +0300") References: <87twinpc4v.fsf@wheatstone.g10code.de> <877ffim784.fsf@wheatstone.g10code.de> <572227C0.4030107@iki.fi> Message-ID: <87fuu5exle.fsf@wheatstone.g10code.de> On Thu, 28 Apr 2016 17:09, jussi.kivilinna at iki.fi said: > Looks as this is caused by some compiler error. I reproduced this with > gcc-5.3 on Ubuntu 16.04. > > With -O3 optimization level, gcc inlines _gcry_cipher_ocb_get_l, > double_block_cpy and double_block to _gcry_cipher_ocb_authenticate. Thanks for your analysis. > Simple workaround that avoid this is to add __attribute__((noinline)) > for _gcry_cipher_ocb_get_l to prevent inlining inside cipher-ocb.c. I do not think this is a good idea because this only works around the gcc bug at in at this place. Fortunately we detected this but we can't know whether this problem is lurking at other places at well. Instead we should - check whether this bug has been fixed in a later gcc version - report the bug to gcc if it is not yet known - add a hint to Libgcrypt's README telling that some gcc versions create wrong code when using -O3. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.