From ruben at rubenkerkhof.com Thu Aug 11 16:08:34 2016 From: ruben at rubenkerkhof.com (Ruben Kerkhof) Date: Thu, 11 Aug 2016 16:08:34 +0200 Subject: [PATCH 1/2] mlock incorrectly marked as broken on FreeBSD Message-ID: <20160811140835.23510-1-ruben@rubenkerkhof.com> On FreeBSD, if there are not enough free pages, mlock() can return EAGAIN, as documented in mlock(2). That doesn't mean that mlock is broken. I suspect this same issue also exists on the other BSD's. --- acinclude.m4 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/acinclude.m4 b/acinclude.m4 index 96be833..dcdadfd 100644 --- a/acinclude.m4 +++ b/acinclude.m4 @@ -242,7 +242,7 @@ int main() pool += (pgsize - ((long int)pool % pgsize)); err = mlock( pool, 4096 ); - if( !err || errno == EPERM ) + if( !err || errno == EPERM || errno == EAGAIN) return 0; /* okay */ return 1; /* hmmm */ -- 2.9.2 From ruben at rubenkerkhof.com Thu Aug 11 16:08:35 2016 From: ruben at rubenkerkhof.com (Ruben Kerkhof) Date: Thu, 11 Aug 2016 16:08:35 +0200 Subject: [PATCH 2/2] lock_pool: check err instead of errno In-Reply-To: <20160811140835.23510-1-ruben@rubenkerkhof.com> References: <20160811140835.23510-1-ruben@rubenkerkhof.com> Message-ID: <20160811140835.23510-2-ruben@rubenkerkhof.com> The errno set by mlock() is overwritten by the call to the next system function. --- src/secmem.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/src/secmem.c b/src/secmem.c index c4e8414..59f75b4 100644 --- a/src/secmem.c +++ b/src/secmem.c @@ -264,15 +264,15 @@ lock_pool (void *p, size_t n) if (err) { - if (errno != EPERM + if (err != EPERM #ifdef EAGAIN /* OpenBSD returns this */ - && errno != EAGAIN + && err != EAGAIN #endif #ifdef ENOSYS /* Some SCOs return this (function not implemented) */ - && errno != ENOSYS + && err != ENOSYS #endif #ifdef ENOMEM /* Linux might return this. */ - && errno != ENOMEM + && err != ENOMEM #endif ) log_error ("can't lock memory: %s\n", strerror (err)); @@ -323,15 +323,15 @@ lock_pool (void *p, size_t n) if (err) { - if (errno != EPERM + if (err != EPERM #ifdef EAGAIN /* OpenBSD returns this. */ - && errno != EAGAIN + && err != EAGAIN #endif #ifdef ENOSYS /* Some SCOs return this (function not implemented). */ - && errno != ENOSYS + && err != ENOSYS #endif #ifdef ENOMEM /* Linux might return this. */ - && errno != ENOMEM + && err != ENOMEM #endif ) log_error ("can't lock memory: %s\n", strerror (err)); -- 2.9.2 From cvs at cvs.gnupg.org Wed Aug 17 13:44:56 2016 From: cvs at cvs.gnupg.org (by Werner Koch) Date: Wed, 17 Aug 2016 13:44:56 +0200 Subject: [git] GCRYPT - branch, master, updated. libgcrypt-1.7.3-1-gbf3388a 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 bf3388a17d1871b03c630b5a66b31e2e44b44edf (commit) via f8241874971478bdcd2bc2082d901d05db7b256d (commit) via 8dd45ad957b54b939c288a68720137386c7f6501 (commit) via 2f62103b4bb6d6f9ce806e01afb7fdc58aa33513 (commit) from f38199dbc290003898a1799adc367265267784c2 (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: NEWS | 19 +++++++++- configure.ac | 4 +- random/random-csprng.c | 100 +++++++++++++++++++++++++------------------------ 3 files changed, 72 insertions(+), 51 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 burdges at gnunet.org Mon Aug 22 19:42:42 2016 From: burdges at gnunet.org (Jeff Burdges) Date: Mon, 22 Aug 2016 19:42:42 +0200 Subject: Fault attacks on RSA in libgcrypt Message-ID: <1471887762.11550.159.camel@gnunet.org> Dear gcrypt-devel, I implemented the protection against fault attacks recommended in "Making RSA-PSS Provably Secure Against Non-Random Faults" by Gilles Barthe, Fran?ois Dupressoir, Pierre-Alain Fouque, Benjamin Gr?goire, Mehdi Tibouchi and Jean-Christophe Zapalowicz. https://eprint.iacr.org/2014/252 It worries that a targeted fault attack could subvert the conditional currently used to protect against fault attacks. Apply the attached patch by switching to a new branch of master and running : git am ../Fault-attacks-on-RSA.patch At present, I'm using rho = ctx.nbits-1 because Remark 2 on page 8 recommends roughly rho = ctx.nbits/2+200 and blind signing applications like Taler need an FDH instead of a randomized scheme like PSS. In fact, if one worries about attacks on a conditional, then maybe one should worry about attacks on ctx.nbits or even ctx.flags & PUBKEY_FLAG_NO_BLINDING as well. If so, Remark 2 argues that rho=512 should more than suffice, even if not covered by their proof, and provide more security against fault attacks on ctx. Thoughts? In any case, I'd suggest disabling support for PUBKEY_FLAG_NO_BLINDING by default too, with a compile time option to enable it. Any occurrence sounds like a bit flit attack target that enables timing attacks. Best, Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: Fault-attacks-on-RSA.patch Type: text/x-patch Size: 2458 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From burdges at gnunet.org Mon Aug 22 22:48:33 2016 From: burdges at gnunet.org (Jeff Burdges) Date: Mon, 22 Aug 2016 22:48:33 +0200 Subject: Fault attacks on RSA in libgcrypt In-Reply-To: <1471887762.11550.159.camel@gnunet.org> References: <1471887762.11550.159.camel@gnunet.org> Message-ID: <1471898913.11197.7.camel@gnunet.org> Also, there are discussion threads on this topic elsewhere : https://github.com/briansmith/ring/issues/264 https://www.ietf.org/mail-archive/web/tls/current/msg20750.html Best, Jeff On Mon, 2016-08-22 at 19:42 +0200, Jeff Burdges wrote: > Dear gcrypt-devel, > > I implemented the protection against fault attacks recommended in > "Making RSA-PSS Provably Secure Against Non-Random Faults" by Gilles > Barthe, Fran?ois Dupressoir, Pierre-Alain Fouque, Benjamin Gr?goire, > Mehdi Tibouchi and Jean-Christophe Zapalowicz. > https://eprint.iacr.org/2014/252 > It worries that a targeted fault attack could subvert the conditional > currently used to protect against fault attacks. > > Apply the attached patch by switching to a new branch of master and > running : > git am ../Fault-attacks-on-RSA.patch > > At present, I'm using rho = ctx.nbits-1 because Remark 2 on page 8 > recommends roughly rho = ctx.nbits/2+200 and blind signing applications > like Taler need an FDH instead of a randomized scheme like PSS. > > In fact, if one worries about attacks on a conditional, then maybe one > should worry about attacks on ctx.nbits or even ctx.flags & > PUBKEY_FLAG_NO_BLINDING as well. If so, Remark 2 argues that rho=512 > should more than suffice, even if not covered by their proof, and > provide more security against fault attacks on ctx. Thoughts? > > In any case, I'd suggest disabling support for PUBKEY_FLAG_NO_BLINDING > by default too, with a compile time option to enable it. Any occurrence > sounds like a bit flit attack target that enables timing attacks. > > Best, > Jeff > > > _______________________________________________ > Gcrypt-devel mailing list > Gcrypt-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gcrypt-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From smueller at chronox.de Tue Aug 23 07:54:22 2016 From: smueller at chronox.de (Stephan Mueller) Date: Tue, 23 Aug 2016 07:54:22 +0200 Subject: Fault attacks on RSA in libgcrypt In-Reply-To: <1471887762.11550.159.camel@gnunet.org> References: <1471887762.11550.159.camel@gnunet.org> Message-ID: <2427728.KG7kgE9pzK@tauon.atsec.com> Am Montag, 22. August 2016, 19:42:42 CEST schrieb Jeff Burdges: Hi Jeff, > Dear gcrypt-devel, > > I implemented the protection against fault attacks recommended in > "Making RSA-PSS Provably Secure Against Non-Random Faults" by Gilles > Barthe, Fran?ois Dupressoir, Pierre-Alain Fouque, Benjamin Gr?goire, > Mehdi Tibouchi and Jean-Christophe Zapalowicz. > https://eprint.iacr.org/2014/252 > It worries that a targeted fault attack could subvert the conditional > currently used to protect against fault attacks. May I ask why that patch is limited to rsa_sign? Shouldn't the decrypt part also be covered with a similar logic considering that it also operates with the private key? Ciao Stephan From burdges at gnunet.org Tue Aug 23 10:24:24 2016 From: burdges at gnunet.org (Jeff Burdges) Date: Tue, 23 Aug 2016 10:24:24 +0200 Subject: Fault attacks on RSA in libgcrypt In-Reply-To: <2427728.KG7kgE9pzK@tauon.atsec.com> References: <1471887762.11550.159.camel@gnunet.org> <2427728.KG7kgE9pzK@tauon.atsec.com> Message-ID: <1471940664.11197.112.camel@gnunet.org> On Tue, 2016-08-23 at 07:54 +0200, Stephan Mueller wrote: > Am Montag, 22. August 2016, 19:42:42 CEST schrieb Jeff Burdges: > > I implemented the protection against fault attacks recommended in > > "Making RSA-PSS Provably Secure Against Non-Random Faults" by Gilles > > Barthe, Fran?ois Dupressoir, Pierre-Alain Fouque, Benjamin Gr?goire, > > Mehdi Tibouchi and Jean-Christophe Zapalowicz. > > https://eprint.iacr.org/2014/252 > > It worries that a targeted fault attack could subvert the conditional > > currently used to protect against fault attacks. > > May I ask why that patch is limited to rsa_sign? Shouldn't the decrypt part > also be covered with a similar logic considering that it also operates with > the private key? As with Lenstra's attack, a normal decryption operation should not reveal the result of the secret computation, but a signature operation does reveal this result. All this patch does is expands the existing protections against Lenstra's attack to the case where an adversary can flip the conditional used to detect Lenstra's attack by corrupting some memory with rowhammer or similar. Lenstra's attack becomes especially relevant for blind signatures, as in Taler, because the adversary can make the signer sign anything. Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From grothoff at gnunet.org Tue Aug 23 09:54:50 2016 From: grothoff at gnunet.org (Christian Grothoff) Date: Tue, 23 Aug 2016 09:54:50 +0200 Subject: Fault attacks on RSA in libgcrypt In-Reply-To: <2427728.KG7kgE9pzK@tauon.atsec.com> References: <1471887762.11550.159.camel@gnunet.org> <2427728.KG7kgE9pzK@tauon.atsec.com> Message-ID: <57BC014A.80702@gnunet.org> Unlike a signature, the result of a decryption operation is typically then NOT send over the network, so even if the decrypted value leaks bits about the private key, that's not so bad as most likely it'll cause a failure locally next, causing the result to be discarded. On 08/23/2016 07:54 AM, Stephan Mueller wrote: > May I ask why that patch is limited to rsa_sign? Shouldn't the decrypt part > also be covered with a similar logic considering that it also operates with > the private key? -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xE29FC3CC.asc Type: application/pgp-keys Size: 26252 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From burdges at gnunet.org Tue Aug 23 23:18:15 2016 From: burdges at gnunet.org (Jeff Burdges) Date: Tue, 23 Aug 2016 23:18:15 +0200 Subject: Fault attacks on RSA in libgcrypt In-Reply-To: <1471887762.11550.159.camel@gnunet.org> References: <1471887762.11550.159.camel@gnunet.org> Message-ID: <1471987095.12716.8.camel@gnunet.org> On Mon, 2016-08-22 at 19:42 +0200, Jeff Burdges wrote: > I implemented the protection against fault attacks recommended in > "Making RSA-PSS Provably Secure Against Non-Random Faults" by Gilles > Barthe, Fran?ois Dupressoir, Pierre-Alain Fouque, Benjamin Gr?goire, > Mehdi Tibouchi and Jean-Christophe Zapalowicz. > https://eprint.iacr.org/2014/252 I chatted with the hardware attack folk in the office briefly today. And I'm no longer so sure this fault attack is actually realistic. At least it's much more subtle than I'd initially imagined. In the Lenstra comparison, the two MPIs should live on the heap, but actual comparison result should live in a register. We could've rowhammer like attacks on either the code page or on the MPIs, but probably not on the comparison result itself, well not unless the thread gets switched out. Non-random fault attacks on the code pages are obviously fatal, but maybe that's out of scope, and quite unlikely. I think attacks on the MPIs do no good because our attacker is trying to obtain the first one, so say zeroing those lengths ruins it, and they cannot make the first match the second. I think our only plausible fault attack is to run a Lenstra-like attack, while concurrently running code on the machine that attempts to force the RSA task to be swapped out after the MPI comparison operation fails, and rowhammer the OSes thread data structures to attempt to switch this one register. At this point, we're discussing rowhammering kernel memory, so maybe a privilege escalation would be easier. Thoughts? It's probably worth better understanding the real strength of the security proof. Jeff p.s. It's worth asking if one can attack anything else too. You could maybe rowhammer a few bits in the private key to produce a faulty modulus with small factors and small hamming distance to the original modulus. Ain't clear if one could really do this while preserving ed=1 mod phi though. If not, the Lenstra comparison should still fail. Yet, phi need not be phi(n) exactly here, so maybe it's possible. I'm unsure if the security proof in that paper addresses this case, maybe not. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From burdges at gnunet.org Wed Aug 24 13:46:06 2016 From: burdges at gnunet.org (Jeff Burdges) Date: Wed, 24 Aug 2016 13:46:06 +0200 Subject: Fault attacks on RSA in libgcrypt In-Reply-To: <1471987095.12716.8.camel@gnunet.org> References: <1471887762.11550.159.camel@gnunet.org> <1471987095.12716.8.camel@gnunet.org> Message-ID: <1472039166.12716.105.camel@gnunet.org> I found an article which provides the same sort of fault protections with a randomized CRT algorithm. I'd expect it gives stronger protections against timing attacks, etc., even if fault attacks prove not to be realistic. http://dl.acm.org/citation.cfm?doid=1873548.1873556 This is probably more the sort of thing one should be doing. It appears the random numbers injected should be quite small, making this scheme fairly fast. This particular paper however only really focuses on fault attacks. It would be good to see this or similar schemes evaluated for timing attack protections though, as folks understandably care way more about timing than about fault attacks. Best, Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From wk at gnupg.org Wed Aug 24 15:25:36 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 24 Aug 2016 15:25:36 +0200 Subject: Fault attacks on RSA in libgcrypt In-Reply-To: <1471887762.11550.159.camel@gnunet.org> (Jeff Burdges's message of "Mon, 22 Aug 2016 19:42:42 +0200") References: <1471887762.11550.159.camel@gnunet.org> Message-ID: <878tvmmh7z.fsf@wheatstone.g10code.de> On Mon, 22 Aug 2016 19:42, burdges at gnunet.org said: > I implemented the protection against fault attacks recommended in > "Making RSA-PSS Provably Secure Against Non-Random Faults" by Gilles > Barthe, Fran?ois Dupressoir, Pierre-Alain Fouque, Benjamin Gr?goire, I do not have the time to read that paper right now. We recently had a similar thing with gpgv and dpkg and it was not clear whether we can do anything about it anyway. Wouldn't a signature verification after creation catch that fault? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From burdges at gnunet.org Wed Aug 24 17:47:11 2016 From: burdges at gnunet.org (Jeff Burdges) Date: Wed, 24 Aug 2016 17:47:11 +0200 Subject: Fault attacks on RSA in libgcrypt In-Reply-To: <878tvmmh7z.fsf@wheatstone.g10code.de> References: <1471887762.11550.159.camel@gnunet.org> <878tvmmh7z.fsf@wheatstone.g10code.de> Message-ID: <1472053631.12716.118.camel@gnunet.org> On Wed, 2016-08-24 at 15:25 +0200, Werner Koch wrote: > I do not have the time to read that paper right now. We recently had > a similar thing with gpgv and dpkg and it was not clear whether we can > do anything about it anyway. > > Wouldn't a signature verification after creation catch that fault? I donno. There are definitely some provable security artifacts here where just to make the proof scheme make sense they must hypothesize a ridiculously strong adversary. I now think the more promising approach is http://dl.acm.org/citation.cfm?doid=1873548.1873556 which is not what I implemented in this patch sadly. I think this better approach still focuses excessively on fault attacks, but the methods employed look useful for defeating timing attack protections too. At present, I know too little about timing attack protections in RSA, but maybe we can find a scheme whose real payoff is timing attack protections, while giving a measure of fault attack protections. Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From wk at gnupg.org Fri Aug 26 11:08:18 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 26 Aug 2016 11:08:18 +0200 Subject: Test - please ignore Message-ID: <87eg5bsxrx.fsf@wheatstone.g10code.de> Hi, I am currently working on our infrastructure. Please have some patience if you encountere failures over the next days. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: