From wk at gnupg.org Tue Oct 3 19:15:02 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 03 Oct 2017 19:15:02 +0200 Subject: Extremely Slow Ed25519 Key Generation (Entropy Source?) In-Reply-To: <8760c0otaz.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Sat, 30 Sep 2017 15:55:16 -0400") References:

<87y3oz1025.fsf@wheatstone.g10code.de> <8760c0otaz.fsf@fifthhorseman.net> Message-ID: <87h8vgw3u1.fsf@wheatstone.g10code.de> On Sat, 30 Sep 2017 21:55, dkg at fifthhorseman.net said: > If we're using getrandom() with the appropriate semantics, shouldn't > this be the default? As random(4) says: Meanwhile I would say yes, but I don't want to get into this kind of discussions again (cf. large RSA keys). A config option leaves enough freedom to everyone. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From chrisballinger at gmail.com Thu Oct 5 04:57:27 2017 From: chrisballinger at gmail.com (Chris Ballinger) Date: Wed, 4 Oct 2017 19:57:27 -0700 Subject: libgcrypt fails to compile with Xcode 9 against iOS 11 SDK In-Reply-To: References:

Message-ID: Resending again because I think it bounced? On Sat, Sep 30, 2017 at 12:57 PM, Chris Ballinger wrote: > Resending due to DMARC failure... > > ---------- Forwarded message ---------- > From: Chris Ballinger > Date: Fri, Sep 29, 2017 at 1:44 PM > Subject: Re: libgcrypt fails to compile with Xcode 9 against iOS 11 SDK > To: gcrypt-devel > > > An additional problem I found in v1.8.1 with Xcode 9. The > mpih-add1-asm.S asm fails to compile for arm64. Reverting to 1.7.9 also > does not fix the issue. > > mpih-add1-asm.S:37:1: error: unknown directive > .type _gcry_mpih_add_n,%function > ^ > mpih-add1-asm.S:71:1: error: unknown directive > .size _gcry_mpih_add_n,.-_gcry_mpih_add_n; > ^ > > > On Fri, Sep 29, 2017 at 12:00 PM, Chris Ballinger > wrote: > >> This affects 1.7.x (and probably lower) through 1.8.1. The issue is that >> calling 'system()' is not allowed on iOS and is a now compile error with >> the latest Xcode 9 / iOS 11 toolchain. >> >> For now I will just comment out the system() calls, but I'll submit a >> better ifdef patch when I get around to it. >> >> >> random.c:556:11: error: 'system' is unavailable: not available on iOS >> >> if (system (cmdline)) >> >> ^ >> >> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneS >> imulator.platform/Developer/SDKs/iPhoneSimulator11.0.sdk/usr/include/stdlib.h:195:6: >> note: >> >> 'system' has been explicitly marked unavailable here >> >> int system(const char *) __DARWIN_ALIAS_C(system); >> >> ^ >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrisballinger at gmail.com Thu Oct 5 07:17:24 2017 From: chrisballinger at gmail.com (Chris Ballinger) Date: Wed, 4 Oct 2017 22:17:24 -0700 Subject: libgcrypt fails to compile with Xcode 9 against iOS 11 SDK In-Reply-To: References:

Message-ID: Ah, apologies for the spam then. I'm actually using clang/llvm 9.0.0 on macOS. I think the issue is that mach-o doesn't support the .type and .size directive but I really don't know how to fix that in a way that would be merged back into libgcrypt, so I just disabled asm. Simply removing those lines allows the asm to compile but then it won't link, so obviously that's not the solution. I ended up having to disable arm64 assembly entirely, although that's not really ideal. I'm sure someone else using libgcrypt on iOS will eventually run into this issue, hopefully whoever it is has a better idea of how to fix it than me. On Wed, Oct 4, 2017 at 9:58 PM, R0b0t1 wrote: > Hello friend! > > On Wed, Oct 4, 2017 at 9:57 PM, Chris Ballinger > wrote: > > Resending again because I think it bounced? > > > > The list received it. You may want to ask on the GCC mailing list > after attempting to read some documentation. Hopefully they can > explain the error well enough to make the fix obvious. > > Cheers, > R0b0t1 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From r030t1 at gmail.com Thu Oct 5 06:58:45 2017 From: r030t1 at gmail.com (R0b0t1) Date: Wed, 4 Oct 2017 23:58:45 -0500 Subject: libgcrypt fails to compile with Xcode 9 against iOS 11 SDK In-Reply-To: References:

Message-ID: Hello friend! On Wed, Oct 4, 2017 at 9:57 PM, Chris Ballinger wrote: > Resending again because I think it bounced? > The list received it. You may want to ask on the GCC mailing list after attempting to read some documentation. Hopefully they can explain the error well enough to make the fix obvious. Cheers, R0b0t1 From ben at adversary.org Sat Oct 7 16:24:30 2017 From: ben at adversary.org (Ben McGinnes) Date: Sun, 8 Oct 2017 01:24:30 +1100 Subject: libgcrypt fails to compile with Xcode 9 against iOS 11 SDK In-Reply-To: References:

Message-ID: <20171007142430.i7ehmsgu7wo4bxr5@adversary.org> On Thu, Oct 05, 2017 at 05:17:24AM +0000, Chris Ballinger wrote: > > Ah, apologies for the spam then. I'm actually using clang/llvm 9.0.0 > on macOS. I've generally found that to be unwise for any project which is specifically part of the GNU Project software. It's one of a number of reasons behind managing libs and dependencies through MacPorts. That way any of the GNU Project software can easily continue using GCC (including gcrypt, gnutls, gmime and all of the gnupg libs), but with clang still hanging around for almost everything else. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: From wk at gnupg.org Mon Oct 9 10:12:10 2017 From: wk at gnupg.org (Werner Koch) Date: Mon, 09 Oct 2017 10:12:10 +0200 Subject: libgcrypt fails to compile with Xcode 9 against iOS 11 SDK In-Reply-To: <20171007142430.i7ehmsgu7wo4bxr5@adversary.org> (Ben McGinnes's message of "Sun, 8 Oct 2017 01:24:30 +1100") References:

<20171007142430.i7ehmsgu7wo4bxr5@adversary.org> Message-ID: <87r2ucpwo5.fsf@wheatstone.g10code.de> On Sat, 7 Oct 2017 16:24, ben at adversary.org said: > (including gcrypt, gnutls, gmime and all of the gnupg libs), but with > clang still hanging around for almost everything else. All GnuPG components aim to be portable over all Unices and thus the compiler should never matter. The system(3) call in the test suite is actually a shortcut to avoid adding a lot of other code and is not a security problem because we don't use setuid and we control all parameters. I am also sure that there is a way to keep on using system(3) because this API is part of ISO C. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From qianyue.zj at alibaba-inc.com Sat Oct 14 19:05:56 2017 From: qianyue.zj at alibaba-inc.com (=?UTF-8?B?5byg5L2zKOS5vui2iik=?=) Date: Sun, 15 Oct 2017 01:05:56 +0800 Subject: [PATCH] sm3: implement SM3 hash algorithm Message-ID: <59E243F4.3030308@alibaba-inc.com> Hi Werner, This is the review request for SM3 hash algorithm. Plz see the commit header and patch for more details. SM3 hash algorithm is already accepted and supported by TPM 2.0 spec. So it is necessary to implement this algorithm in a famous open source software for checking the digest value computed by TPM. Plz refer to this PR (https://github.com/gpg/libgcrypt/pull/2) for code review. Thanks, Jia From r030t1 at gmail.com Sat Oct 14 22:16:10 2017 From: r030t1 at gmail.com (R0b0t1) Date: Sat, 14 Oct 2017 15:16:10 -0500 Subject: [PATCH] sm3: implement SM3 hash algorithm In-Reply-To: <59E243F4.3030308@alibaba-inc.com> References: <59E243F4.3030308@alibaba-inc.com> Message-ID: On Sat, Oct 14, 2017 at 12:05 PM, ??(??) wrote: > Hi Werner, > > This is the review request for SM3 hash algorithm. Plz see the commit > header and patch for more details. > > SM3 hash algorithm is already accepted and supported by TPM 2.0 spec. > So it is necessary to implement this algorithm in a famous open source > software for checking the digest value computed by TPM. > > Plz refer to this PR (https://github.com/gpg/libgcrypt/pull/2) for code > review. > > Thanks, > Jia > Jia, It is my understanding that SM3 was not accepted into any global TPM specification and is merely mandated for use within China. My research on SM3 has turned up only one detailed cryptanalysis of the function.[1] That cryptanalysis implies that the techniques used to "strengthen" SM3 do not accomplish what the creators claim, and may even weaken the hash function when compared to its inspiration, SHA-2. Less detailed analysis[3] of the claims presented by the creators reflect poorly on their work. For starters, none of the techniques meant to increase the security of SM3 are explained. Their utility is unknown, and a cursory glance shows that in at least one case a round operation is simplified. Perhaps more distressing is the selection of constants with no justification. It seems very likely that the algorithm has undisclosed backdoors. Also pertinent is the existence of GmSSL,[3] a fork of OpenSSL which contains various cryptographic standards developed by the Chinese government that were, presumably, not deemed fit for inclusion in OpenSSL. Inclusion of weak cryptography in gcrypt would be a disservice to those users which trust gcrypt with their life. I understand I am not the person to whom you addressed your message, nor am I a gcrypt developer, but I felt it necessary to reply to this conversation. Respectfully, R0b0t1 [1]: https://eprint.iacr.org/2012/274.pdf, also attached. [2]: https://tinycrypt.wordpress.com/2017/02/22/asmcodes-sm3/ [3]: http://gmssl.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: sm3_cryptanalysis.pdf Type: application/pdf Size: 269852 bytes Desc: not available URL: From w.k at berkeley.edu Sun Oct 15 10:13:11 2017 From: w.k at berkeley.edu (Weikeng Chen) Date: Sun, 15 Oct 2017 01:13:11 -0700 Subject: [PATCH] sm3: implement SM3 hash algorithm In-Reply-To: References: <59E243F4.3030308@alibaba-inc.com> Message-ID: There is a released document that SM3-256 is registered by TPM. But I don't think TPM is an organization that verifies cryptographic primitives. https://www.trustedcomputinggroup.org/wp-content/uploads/TCG_Algorithm_Registry_Rev_1.22.pdf Besides the boring reason that my country, China, wants to have some independent cryptographic algorithms. There are no cryptographic and scientific reasons to put so many alternative cryptographic algorithms inside, so do SM3. For me, AES-GCM, SHA3 (or maybe MD6?) is enough for both research, academic, and therefore industrial uses. If not for compatible concerns, gcrypt could also remove some old ciphers -- the mainstream ones are sufficient. I generally don't take a serious care of research papers not published to a high-level conference, neither does that 2012/274. But also the few research papers on SM3 also indicates insufficient academic discussion. Generally, they are not ready for immediate use. Although some professors in China are very eager to make it a standard and win research funding, I still don't feel confident about it. I know and understand that Alibaba sometimes has to work with the government on some projects that are required to use SM1-4. I think it is independent of submitting to gcrypt. It is not needed and not a wise decision. Also, due to the few resource on SM3, it is hard to verify the implementation. Implementations require very careful observations. Here. I would like to reclaim here that the implementation in gcrypt of ElGamal is not semantic secure! I will prepare a post recently. On Sat, Oct 14, 2017 at 1:16 PM, R0b0t1 wrote: > On Sat, Oct 14, 2017 at 12:05 PM, ??(??) wrote: >> Hi Werner, >> >> This is the review request for SM3 hash algorithm. Plz see the commit >> header and patch for more details. >> >> SM3 hash algorithm is already accepted and supported by TPM 2.0 spec. >> So it is necessary to implement this algorithm in a famous open source >> software for checking the digest value computed by TPM. >> >> Plz refer to this PR (https://github.com/gpg/libgcrypt/pull/2) for code >> review. >> >> Thanks, >> Jia >> > > Jia, > > It is my understanding that SM3 was not accepted into any global TPM > specification and is merely mandated for use within China. > > My research on SM3 has turned up only one detailed cryptanalysis of > the function.[1] That cryptanalysis implies that the techniques used > to "strengthen" SM3 do not accomplish what the creators claim, and may > even weaken the hash function when compared to its inspiration, SHA-2. > > Less detailed analysis[3] of the claims presented by the creators > reflect poorly on their work. For starters, none of the techniques > meant to increase the security of SM3 are explained. Their utility is > unknown, and a cursory glance shows that in at least one case a round > operation is simplified. Perhaps more distressing is the selection of > constants with no justification. > > It seems very likely that the algorithm has undisclosed backdoors. > > Also pertinent is the existence of GmSSL,[3] a fork of OpenSSL which > contains various cryptographic standards developed by the Chinese > government that were, presumably, not deemed fit for inclusion in > OpenSSL. > > Inclusion of weak cryptography in gcrypt would be a disservice to > those users which trust gcrypt with their life. I understand I am not > the person to whom you addressed your message, nor am I a gcrypt > developer, but I felt it necessary to reply to this conversation. > > Respectfully, > R0b0t1 > > > [1]: https://eprint.iacr.org/2012/274.pdf, also attached. > [2]: https://tinycrypt.wordpress.com/2017/02/22/asmcodes-sm3/ > [3]: http://gmssl.org/ > > _______________________________________________ > Gcrypt-devel mailing list > Gcrypt-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gcrypt-devel > -- Weikeng Chen @ 795 Soda Hall From w.k at berkeley.edu Sun Oct 15 10:18:16 2017 From: w.k at berkeley.edu (Weikeng Chen) Date: Sun, 15 Oct 2017 01:18:16 -0700 Subject: [PATCH] sm3: implement SM3 hash algorithm In-Reply-To: References: <59E243F4.3030308@alibaba-inc.com> Message-ID: Finding Collisions for Round-Reduced SM3 https://link.springer.com/chapter/10.1007/978-3-642-36095-4_12 On Sat, Oct 14, 2017 at 1:16 PM, R0b0t1 wrote: > On Sat, Oct 14, 2017 at 12:05 PM, ??(??) wrote: >> Hi Werner, >> >> This is the review request for SM3 hash algorithm. Plz see the commit >> header and patch for more details. >> >> SM3 hash algorithm is already accepted and supported by TPM 2.0 spec. >> So it is necessary to implement this algorithm in a famous open source >> software for checking the digest value computed by TPM. >> >> Plz refer to this PR (https://github.com/gpg/libgcrypt/pull/2) for code >> review. >> >> Thanks, >> Jia >> > > Jia, > > It is my understanding that SM3 was not accepted into any global TPM > specification and is merely mandated for use within China. > > My research on SM3 has turned up only one detailed cryptanalysis of > the function.[1] That cryptanalysis implies that the techniques used > to "strengthen" SM3 do not accomplish what the creators claim, and may > even weaken the hash function when compared to its inspiration, SHA-2. > > Less detailed analysis[3] of the claims presented by the creators > reflect poorly on their work. For starters, none of the techniques > meant to increase the security of SM3 are explained. Their utility is > unknown, and a cursory glance shows that in at least one case a round > operation is simplified. Perhaps more distressing is the selection of > constants with no justification. > > It seems very likely that the algorithm has undisclosed backdoors. > > Also pertinent is the existence of GmSSL,[3] a fork of OpenSSL which > contains various cryptographic standards developed by the Chinese > government that were, presumably, not deemed fit for inclusion in > OpenSSL. > > Inclusion of weak cryptography in gcrypt would be a disservice to > those users which trust gcrypt with their life. I understand I am not > the person to whom you addressed your message, nor am I a gcrypt > developer, but I felt it necessary to reply to this conversation. > > Respectfully, > R0b0t1 > > > [1]: https://eprint.iacr.org/2012/274.pdf, also attached. > [2]: https://tinycrypt.wordpress.com/2017/02/22/asmcodes-sm3/ > [3]: http://gmssl.org/ > > _______________________________________________ > Gcrypt-devel mailing list > Gcrypt-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gcrypt-devel > -- Weikeng Chen @ 795 Soda Hall From w.k at berkeley.edu Sun Oct 15 10:47:02 2017 From: w.k at berkeley.edu (Weikeng Chen) Date: Sun, 15 Oct 2017 01:47:02 -0700 Subject: [PATCH] sm3: implement SM3 hash algorithm In-Reply-To: References: <59E243F4.3030308@alibaba-inc.com> Message-ID: I think it is unlikely that SM3 contains a backdoor. It is intended to be used in governments and mission-critical devices. There is no reason to use something dangerous (then U.S. can break?). And it is generally not that easy to add a backdoor in a symmetric algorithm if we obtain randomness from a physical source. gcrypt cannot have all new functions -- otherwise, why not balloon hashing and scrypt (the latter is used in many kinds of cryptocurrency)? On Sat, Oct 14, 2017 at 1:16 PM, R0b0t1 wrote: > On Sat, Oct 14, 2017 at 12:05 PM, ??(??) wrote: >> Hi Werner, >> >> This is the review request for SM3 hash algorithm. Plz see the commit >> header and patch for more details. >> >> SM3 hash algorithm is already accepted and supported by TPM 2.0 spec. >> So it is necessary to implement this algorithm in a famous open source >> software for checking the digest value computed by TPM. >> >> Plz refer to this PR (https://github.com/gpg/libgcrypt/pull/2) for code >> review. >> >> Thanks, >> Jia >> > > Jia, > > It is my understanding that SM3 was not accepted into any global TPM > specification and is merely mandated for use within China. > > My research on SM3 has turned up only one detailed cryptanalysis of > the function.[1] That cryptanalysis implies that the techniques used > to "strengthen" SM3 do not accomplish what the creators claim, and may > even weaken the hash function when compared to its inspiration, SHA-2. > > Less detailed analysis[3] of the claims presented by the creators > reflect poorly on their work. For starters, none of the techniques > meant to increase the security of SM3 are explained. Their utility is > unknown, and a cursory glance shows that in at least one case a round > operation is simplified. Perhaps more distressing is the selection of > constants with no justification. > > It seems very likely that the algorithm has undisclosed backdoors. > > Also pertinent is the existence of GmSSL,[3] a fork of OpenSSL which > contains various cryptographic standards developed by the Chinese > government that were, presumably, not deemed fit for inclusion in > OpenSSL. > > Inclusion of weak cryptography in gcrypt would be a disservice to > those users which trust gcrypt with their life. I understand I am not > the person to whom you addressed your message, nor am I a gcrypt > developer, but I felt it necessary to reply to this conversation. > > Respectfully, > R0b0t1 > > > [1]: https://eprint.iacr.org/2012/274.pdf, also attached. > [2]: https://tinycrypt.wordpress.com/2017/02/22/asmcodes-sm3/ > [3]: http://gmssl.org/ > > _______________________________________________ > Gcrypt-devel mailing list > Gcrypt-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gcrypt-devel > -- Weikeng Chen @ 795 Soda Hall From w.k at berkeley.edu Sun Oct 15 18:17:20 2017 From: w.k at berkeley.edu (Weikeng Chen) Date: Sun, 15 Oct 2017 09:17:20 -0700 Subject: [PATCH] sm3: implement SM3 hash algorithm In-Reply-To: <4eda55e2-370c-4b4e-9fc3-a1fc0ab86a4f.qianyue.zj@alibaba-inc.com> References: <59E243F4.3030308@alibaba-inc.com> <4eda55e2-370c-4b4e-9fc3-a1fc0ab86a4f.qianyue.zj@alibaba-inc.com> Message-ID: I think now the two questions are: (1) following the common practice of gcrypt, what requirement should be met to add a new hash function? (2) there are very few resources available for SM3 -- even the Chinese resource. This makes it really hard to double check and make code review. The problem is, there is no English official release? This is a very crucial step because open-source community is very international. Weikeng On Oct 15, 2017 8:31 AM, "??(??)" wrote: Plz search "Trusted Platform Module Library" spec rev 1.38 for the references to SM3. Also, I have a working TPM 2.0 hardware showing the capability of support on sm3. $tpm2_dump_capability -c algorithms | grep 'hash:\s*set' -B 3 TPMA_ALGORITHM for ALG_ID: 0x4 - sha1 asymmetric: clear symmetric: clear hash: set -- TPMA_ALGORITHM for ALG_ID: 0x5 - hmac asymmetric: clear symmetric: clear hash: set -- TPMA_ALGORITHM for ALG_ID: 0x7 - mgf1 asymmetric: clear symmetric: clear hash: set -- TPMA_ALGORITHM for ALG_ID: 0x8 - keyedhash asymmetric: clear symmetric: clear hash: set -- TPMA_ALGORITHM for ALG_ID: 0xa - xor asymmetric: clear symmetric: set hash: set -- TPMA_ALGORITHM for ALG_ID: 0xb - sha256 asymmetric: clear symmetric: clear hash: set -- TPMA_ALGORITHM for ALG_ID: 0x12 - sm3_256 asymmetric: clear symmetric: clear hash: set -- TPMA_ALGORITHM for ALG_ID: 0x20 - kdf1_sp800_56a asymmetric: clear symmetric: clear hash: set -- TPMA_ALGORITHM for ALG_ID: 0x22 - kdf1_sp800_108 asymmetric: clear symmetric: clear hash: set Jia ------------------------------------------------------------------ ????Weikeng Chen ?????2017?10?15?(???) 16:47 ????R0b0t1 ? ????(??) ; wk ; gcrypt-devel < gcrypt-devel at gnupg.org> ? ??Re: [PATCH] sm3: implement SM3 hash algorithm I think it is unlikely that SM3 contains a backdoor. It is intended to be used in governments and mission-critical devices. There is no reason to use something dangerous (then U.S. can break?). And it is generally not that easy to add a backdoor in a symmetric algorithm if we obtain randomness from a physical source. gcrypt cannot have all new functions -- otherwise, why not balloon hashing and scrypt (the latter is used in many kinds of cryptocurrency)? On Sat, Oct 14, 2017 at 1:16 PM, R0b0t1 wrote: > On Sat, Oct 14, 2017 at 12:05 PM, ??(??) wrote: >> Hi Werner, >> >> This is the review request for SM3 hash algorithm. Plz see the commit >> header and patch for more details. >> >> SM3 hash algorithm is already accepted and supported by TPM 2.0 spec. >> So it is necessary to implement this algorithm in a famous open source >> software for checking the digest value computed by TPM. >> >> Plz refer to this PR (https://github.com/gpg/libgcrypt/pull/2) for code >> review. >> >> Thanks, >> Jia >> > > Jia, > > It is my understanding that SM3 was not accepted into any global TPM > specification and is merely mandated for use within China. > > My research on SM3 has turned up only one detailed cryptanalysis of > the function.[1] That cryptanalysis implies that the techniques used > to "strengthen" SM3 do not accomplish what the creators claim, and may > even weaken the hash function when compared to its inspiration, SHA-2. > > Less detailed analysis[3] of the claims presented by the creators > reflect poorly on their work. For starters, none of the techniques > meant to increase the security of SM3 are explained. Their utility is > unknown, and a cursory glance shows that in at least one case a round > operation is simplified. Perhaps more distressing is the selection of > constants with no justification. > > It seems very likely that the algorithm has undisclosed backdoors. > > Also pertinent is the existence of GmSSL,[3] a fork of OpenSSL which > contains various cryptographic standards developed by the Chinese > government that were, presumably, not deemed fit for inclusion in > OpenSSL. > > Inclusion of weak cryptography in gcrypt would be a disservice to > those users which trust gcrypt with their life. I understand I am not > the person to whom you addressed your message, nor am I a gcrypt > developer, but I felt it necessary to reply to this conversation. > > Respectfully, > R0b0t1 > > > [1]: https://eprint.iacr.org/2012/274.pdf, also attached. > [2]: https://tinycrypt.wordpress.com/2017/02/22/asmcodes-sm3/ > [3]: http://gmssl.org/ > > _______________________________________________ > Gcrypt-devel mailing list > Gcrypt-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gcrypt-devel > -- Weikeng Chen @ 795 Soda Hall -------------- next part -------------- An HTML attachment was scrubbed... URL: From qianyue.zj at alibaba-inc.com Sun Oct 15 17:25:03 2017 From: qianyue.zj at alibaba-inc.com (=?UTF-8?B?5byg5L2zKOS5vui2iik=?=) Date: Sun, 15 Oct 2017 23:25:03 +0800 Subject: =?UTF-8?B?5Zue5aSN77yaW1BBVENIXSBzbTM6IGltcGxlbWVudCBTTTMgaGFzaCBhbGdvcml0aG0=?= In-Reply-To: CAHr+ZK8G=5crAUeOXuKUpkBRAsatPZQhhzVZptSVc+eDhb56sA@mail.gmail.com References: <59E243F4.3030308@alibaba-inc.com> , CAHr+ZK8G=5crAUeOXuKUpkBRAsatPZQhhzVZptSVc+eDhb56sA@mail.gmail.com Message-ID: And yes, the author also mentiones they used the similiar tech for collision attack on sha2. Jia------------------------------------------------------------------????Weikeng Chen ?????2017?10?15?(???) 16:18????R0b0t1 ??????(??) ; wk ; gcrypt-devel ????Re: [PATCH] sm3: implement SM3 hash algorithm Finding?Collisions?for?Round-Reduced?SM3 https://link.springer.com/chapter/10.1007/978-3-642-36095-4_12 On?Sat,?Oct?14,?2017?at?1:16?PM,?R0b0t1??wrote: >?On?Sat,?Oct?14,?2017?at?12:05?PM,???(??)??wrote: >>?Hi?Werner, >> >>?This?is?the?review?request?for?SM3?hash?algorithm.?Plz?see?the?commit >>?header?and?patch?for?more?details. >> >>?SM3?hash?algorithm?is?already?accepted?and?supported?by?TPM?2.0?spec. >>?So?it?is?necessary?to?implement?this?algorithm?in?a?famous?open?source >>?software?for?checking?the?digest?value?computed?by?TPM. >> >>?Plz?refer?to?this?PR?(https://github.com/gpg/libgcrypt/pull/2)?for?code >>?review. >> >>?Thanks, >>?Jia >> > >?Jia, > >?It?is?my?understanding?that?SM3?was?not?accepted?into?any?global?TPM >?specification?and?is?merely?mandated?for?use?within?China. > >?My?research?on?SM3?has?turned?up?only?one?detailed?cryptanalysis?of >?the?function.[1]?That?cryptanalysis?implies?that?the?techniques?used >?to?"strengthen"?SM3?do?not?accomplish?what?the?creators?claim,?and?may >?even?weaken?the?hash?function?when?compared?to?its?inspiration,?SHA-2. > >?Less?detailed?analysis[3]?of?the?claims?presented?by?the?creators >?reflect?poorly?on?their?work.?For?starters,?none?of?the?techniques >?meant?to?increase?the?security?of?SM3?are?explained.?Their?utility?is >?unknown,?and?a?cursory?glance?shows?that?in?at?least?one?case?a?round >?operation?is?simplified.?Perhaps?more?distressing?is?the?selection?of >?constants?with?no?justification. > >?It?seems?very?likely?that?the?algorithm?has?undisclosed?backdoors. > >?Also?pertinent?is?the?existence?of?GmSSL,[3]?a?fork?of?OpenSSL?which >?contains?various?cryptographic?standards?developed?by?the?Chinese >?government?that?were,?presumably,?not?deemed?fit?for?inclusion?in >?OpenSSL. > >?Inclusion?of?weak?cryptography?in?gcrypt?would?be?a?disservice?to >?those?users?which?trust?gcrypt?with?their?life.?I?understand?I?am?not >?the?person?to?whom?you?addressed?your?message,?nor?am?I?a?gcrypt >?developer,?but?I?felt?it?necessary?to?reply?to?this?conversation. > >?Respectfully, >??????R0b0t1 > > >?[1]:?https://eprint.iacr.org/2012/274.pdf,?also?attached. >?[2]:?https://tinycrypt.wordpress.com/2017/02/22/asmcodes-sm3/ >?[3]:?http://gmssl.org/ > >?_______________________________________________ >?Gcrypt-devel?mailing?list >?Gcrypt-devel at gnupg.org >?http://lists.gnupg.org/mailman/listinfo/gcrypt-devel > --? Weikeng?Chen?@?795?Soda?Hall -------------- next part -------------- An HTML attachment was scrubbed... URL: From qianyue.zj at alibaba-inc.com Sun Oct 15 17:30:54 2017 From: qianyue.zj at alibaba-inc.com (=?UTF-8?B?5byg5L2zKOS5vui2iik=?=) Date: Sun, 15 Oct 2017 23:30:54 +0800 Subject: =?UTF-8?B?5Zue5aSN77yaW1BBVENIXSBzbTM6IGltcGxlbWVudCBTTTMgaGFzaCBhbGdvcml0aG0=?= In-Reply-To: CAHr+ZK_Ye7XGz78X7Q_pyEf0qTiBuDcvAwU+ynW=yf3hUwpjFA@mail.gmail.com References: <59E243F4.3030308@alibaba-inc.com> , CAHr+ZK_Ye7XGz78X7Q_pyEf0qTiBuDcvAwU+ynW=yf3hUwpjFA@mail.gmail.com Message-ID: <4eda55e2-370c-4b4e-9fc3-a1fc0ab86a4f.qianyue.zj@alibaba-inc.com> Plz search "Trusted Platform Module Library" spec rev 1.38 for the references to SM3. Also, I have a working TPM 2.0 hardware showing the capability of support on sm3. $tpm2_dump_capability?-c?algorithms?|?grep?'hash:\s*set'?-B?3 TPMA_ALGORITHM?for?ALG_ID:?0x4?-?sha1 ??asymmetric:?clear ??symmetric:??clear ??hash:???????set -- TPMA_ALGORITHM?for?ALG_ID:?0x5?-?hmac ??asymmetric:?clear ??symmetric:??clear ??hash:???????set -- TPMA_ALGORITHM?for?ALG_ID:?0x7?-?mgf1 ??asymmetric:?clear ??symmetric:??clear ??hash:???????set -- TPMA_ALGORITHM?for?ALG_ID:?0x8?-?keyedhash ??asymmetric:?clear ??symmetric:??clear ??hash:???????set -- TPMA_ALGORITHM?for?ALG_ID:?0xa?-?xor ??asymmetric:?clear ??symmetric:??set ??hash:???????set -- TPMA_ALGORITHM?for?ALG_ID:?0xb?-?sha256 ??asymmetric:?clear ??symmetric:??clear ??hash:???????set -- TPMA_ALGORITHM?for?ALG_ID:?0x12?-?sm3_256 ??asymmetric:?clear ??symmetric:??clear ??hash:???????set -- TPMA_ALGORITHM?for?ALG_ID:?0x20?-?kdf1_sp800_56a ??asymmetric:?clear ??symmetric:??clear ??hash:???????set -- TPMA_ALGORITHM?for?ALG_ID:?0x22?-?kdf1_sp800_108 ??asymmetric:?clear ??symmetric:??clear ??hash:???????set Jia ------------------------------------------------------------------????Weikeng Chen ?????2017?10?15?(???) 16:47????R0b0t1 ??????(??) ; wk ; gcrypt-devel ????Re: [PATCH] sm3: implement SM3 hash algorithm I?think?it?is?unlikely?that?SM3?contains?a?backdoor. It?is?intended?to?be?used?in?governments?and?mission-critical?devices. There?is?no?reason?to?use?something?dangerous?(then?U.S.?can?break?). And?it?is?generally?not?that?easy?to?add?a?backdoor?in?a?symmetric algorithm?if?we?obtain?randomness?from?a?physical?source. gcrypt?cannot?have?all?new?functions?--?otherwise,?why?not?balloon hashing?and?scrypt?(the?latter?is?used?in?many?kinds?of cryptocurrency)? On?Sat,?Oct?14,?2017?at?1:16?PM,?R0b0t1??wrote: >?On?Sat,?Oct?14,?2017?at?12:05?PM,???(??)??wrote: >>?Hi?Werner, >> >>?This?is?the?review?request?for?SM3?hash?algorithm.?Plz?see?the?commit >>?header?and?patch?for?more?details. >> >>?SM3?hash?algorithm?is?already?accepted?and?supported?by?TPM?2.0?spec. >>?So?it?is?necessary?to?implement?this?algorithm?in?a?famous?open?source >>?software?for?checking?the?digest?value?computed?by?TPM. >> >>?Plz?refer?to?this?PR?(https://github.com/gpg/libgcrypt/pull/2)?for?code >>?review. >> >>?Thanks, >>?Jia >> > >?Jia, > >?It?is?my?understanding?that?SM3?was?not?accepted?into?any?global?TPM >?specification?and?is?merely?mandated?for?use?within?China. > >?My?research?on?SM3?has?turned?up?only?one?detailed?cryptanalysis?of >?the?function.[1]?That?cryptanalysis?implies?that?the?techniques?used >?to?"strengthen"?SM3?do?not?accomplish?what?the?creators?claim,?and?may >?even?weaken?the?hash?function?when?compared?to?its?inspiration,?SHA-2. > >?Less?detailed?analysis[3]?of?the?claims?presented?by?the?creators >?reflect?poorly?on?their?work.?For?starters,?none?of?the?techniques >?meant?to?increase?the?security?of?SM3?are?explained.?Their?utility?is >?unknown,?and?a?cursory?glance?shows?that?in?at?least?one?case?a?round >?operation?is?simplified.?Perhaps?more?distressing?is?the?selection?of >?constants?with?no?justification. > >?It?seems?very?likely?that?the?algorithm?has?undisclosed?backdoors. > >?Also?pertinent?is?the?existence?of?GmSSL,[3]?a?fork?of?OpenSSL?which >?contains?various?cryptographic?standards?developed?by?the?Chinese >?government?that?were,?presumably,?not?deemed?fit?for?inclusion?in >?OpenSSL. > >?Inclusion?of?weak?cryptography?in?gcrypt?would?be?a?disservice?to >?those?users?which?trust?gcrypt?with?their?life.?I?understand?I?am?not >?the?person?to?whom?you?addressed?your?message,?nor?am?I?a?gcrypt >?developer,?but?I?felt?it?necessary?to?reply?to?this?conversation. > >?Respectfully, >??????R0b0t1 > > >?[1]:?https://eprint.iacr.org/2012/274.pdf,?also?attached. >?[2]:?https://tinycrypt.wordpress.com/2017/02/22/asmcodes-sm3/ >?[3]:?http://gmssl.org/ > >?_______________________________________________ >?Gcrypt-devel?mailing?list >?Gcrypt-devel at gnupg.org >?http://lists.gnupg.org/mailman/listinfo/gcrypt-devel > --? Weikeng?Chen?@?795?Soda?Hall -------------- next part -------------- An HTML attachment was scrubbed... URL: From qianyue.zj at alibaba-inc.com Sun Oct 15 18:30:47 2017 From: qianyue.zj at alibaba-inc.com (=?UTF-8?B?5byg5L2zKOS5vui2iik=?=) Date: Mon, 16 Oct 2017 00:30:47 +0800 Subject: [PATCH] sm3: implement SM3 hash algorithm In-Reply-To: References: <59E243F4.3030308@alibaba-inc.com> <4eda55e2-370c-4b4e-9fc3-a1fc0ab86a4f.qianyue.zj@alibaba-inc.com> Message-ID: <59E38D37.4080200@alibaba-inc.com> ? 2017/10/16 ??12:17, Weikeng Chen ??: > I think now the two questions are: > > (1) following the common practice of gcrypt, what requirement should be > met to add a new hash function? I'm quite new to libgcrypt, but I think SM3 would be OK as long as it is still not a weak algorithm such as sha1 and md5. Finally, we seem to not evict sha1 and md5 from the default libgcrypt configuration. Generally, they should have to be enabled via explicitly specifying, e.g, --enforce-digest-algs=sha1,md5, to let people "trust gcrypt with their life". I mean currently I don't see why sm3 should not be here. > > (2) there are very few resources available for SM3 -- even the Chinese > resource. This makes it really hard to double check and make code > review. The problem is, there is no English official release? This is a > very crucial step because open-source community is very international. After all SM3 is explicitly supported by TPM 2.0 spec, assuming TCG is not stupid. Jia > > Weikeng > > On Oct 15, 2017 8:31 AM, "??(??)" > wrote: > > Plz search "Trusted Platform Module Library" spec rev 1.38 for the > references to SM3. Also, I have a working TPM 2.0 hardware showing > the capability of support on sm3. > > $tpm2_dump_capability -c algorithms | grep 'hash:\s*set' -B 3 > TPMA_ALGORITHM for ALG_ID: 0x4 - sha1 > asymmetric: clear > symmetric: clear > hash: set > -- > TPMA_ALGORITHM for ALG_ID: 0x5 - hmac > asymmetric: clear > symmetric: clear > hash: set > -- > TPMA_ALGORITHM for ALG_ID: 0x7 - mgf1 > asymmetric: clear > symmetric: clear > hash: set > -- > TPMA_ALGORITHM for ALG_ID: 0x8 - keyedhash > asymmetric: clear > symmetric: clear > hash: set > -- > TPMA_ALGORITHM for ALG_ID: 0xa - xor > asymmetric: clear > symmetric: set > hash: set > -- > TPMA_ALGORITHM for ALG_ID: 0xb - sha256 > asymmetric: clear > symmetric: clear > hash: set > -- > TPMA_ALGORITHM for ALG_ID: 0x12 - sm3_256 > asymmetric: clear > symmetric: clear > hash: set > -- > TPMA_ALGORITHM for ALG_ID: 0x20 - kdf1_sp800_56a > asymmetric: clear > symmetric: clear > hash: set > -- > TPMA_ALGORITHM for ALG_ID: 0x22 - kdf1_sp800_108 > asymmetric: clear > symmetric: clear > hash: set > > Jia > > ------------------------------------------------------------------ > ????Weikeng Chen > > ?????2017?10?15?(???) 16:47 > ????R0b0t1 > > ??????(??) >; wk >; gcrypt-devel

> > ????Re: [PATCH] sm3: implement SM3 hash algorithm > > I think it is unlikely that SM3 contains a backdoor. > > It is intended to be used in governments and mission-critical devices. > There is no reason to use something dangerous (then U.S. can break?). > And it is generally not that easy to add a backdoor in a symmetric > algorithm if we obtain randomness from a physical source. > > > gcrypt cannot have all new functions -- otherwise, why not balloon > hashing and scrypt (the latter is used in many kinds of > cryptocurrency)? > > > > On Sat, Oct 14, 2017 at 1:16 PM, R0b0t1 > wrote: > > On Sat, Oct 14, 2017 at 12:05 PM, ??(? > ?) > wrote: > >> Hi Werner, > >> > >> This is the review request > for SM3 hash algorithm. Plz see the commit > >> header and patch for more details. > >> > >> SM3 hash algorithm is already accepted and supported by TPM 2.0 spec. > >> So it is necessary to implement this algorithm in a famous open source > >> software for checking the digest value computed by TPM. > >> > >> Plz refer to this PR (https://github.com/gpg/libgcrypt/pull/2 ) for code > >> review. > >> > >> Thanks, > >> Jia > >> > > > > Jia, > > > > It is my understanding that SM3 was not accepted into any > global TPM > > specification and is merely mandated for use within China. > > > > My research on SM3 has turned up only one detailed cryptanalysis of > > the function.[1] That cryptanalysis implies that the techniques used > > to "strengthen" SM3 do not accomplish what the creators claim, and may > > even weaken the hash function when compared to its inspiration, SHA-2. > > > > Less detailed analysis[3] of the claims presented by the creators > > reflect poorly on their work. For starters, none of the techniques > > meant to increase the security of SM3 are explained. Their utility is > > unknown, and a cursory glance shows that in at least one case a round > > operation is simplified. Perhaps more distressing is the selection of > > constants with no justification. > > > > It seems very likely that the algorithm has undisclosed backdoors. > > > > Also pertinent is the existence of GmSSL,[3] a fork of OpenSSL which > > contains various cryptographic standards developed by the Chinese > > government that were, presumably, not deemed fit for inclusion in > > OpenSSL. > > > > Inclusion of weak cryptography in gcrypt would be a disservice to > > those users which trust gcrypt with their life. I understand I am not > > the person to whom you addressed your message, nor am I a gcrypt > > developer, but I felt it necessary to reply to this conversation. > > > > Respectfully, > > R0b0t1 > > > > > > [1]: https://eprint.iacr.org/2012/274.pdf > , also attached. > > [2]: https://tinycrypt.wordpress.com/2017/02/22/asmcodes-sm3/ > > > [3]: http://gmssl.org/ > > > > _______________________________________________ > > Gcrypt-devel mailing list > > Gcrypt-devel at gnupg.org > > http://lists.gnupg.org/mailman/listinfo/gcrypt-devel > > > > > > > -- > > Weikeng Chen @ 795 Soda Hall > > From r030t1 at gmail.com Mon Oct 16 01:21:56 2017 From: r030t1 at gmail.com (R0b0t1) Date: Sun, 15 Oct 2017 18:21:56 -0500 Subject: [PATCH] sm3: implement SM3 hash algorithm In-Reply-To: References: <59E243F4.3030308@alibaba-inc.com> Message-ID: On Sun, Oct 15, 2017 at 3:47 AM, Weikeng Chen wrote: > I think it is unlikely that SM3 contains a backdoor. > This is giving the authors of SM3 a dangerous amount of credit where it is not due. Their algorithm fails a very basic test: https://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number. At best, they don't know what they are doing and made changes randomly. At worst, they made changes to make the algorithm susceptible to an undisclosed attack and could find no justification to use as a lie. Just because you personally can not imagine some weakness in SM3 does not mean there are no weaknesses in SM3. > It is intended to be used in governments and mission-critical devices. > There is no reason to use something dangerous (then U.S. can break?). > And it is generally not that easy to add a backdoor in a symmetric > algorithm if we obtain randomness from a physical source. > The problem with proving a negative in this context; that is, proving there are no back doors to the algorithm, is that it takes a huge amount of work. The "Limitations" section of the Wikipedia article above explains it well: the problem space is so large that any number of design constraints could have been engineered to provide a weakness that is only accessible to a party with special knowledge. In this sense a weakness can be made "safe" and turned into a back door. This is one of the major reasons that lack of cryptanalysis for an algorithm is suspicious: other researchers could consider it a waste of time to investigate a plausibly backdoored algorithm. Even if, however, other nation states were already aware of and could exploit the weakness, I expect that China would use a weak algorithm. China may not have the capabilities that other actors do, and may need to rely on algorithms that would be considered weak to other actors if China wants to monitor communication within its borders. As a good example, look at Russian certificate authorities and content hosts. Many of them use very weak cryptographic keys. I have seen many 512 bit RSA keys that are nowhere close to expiring. Seeing as the Russian intelligence services are apparently not capable of factoring extremely large primes, they "recommend" weak keys to their citizens (or for some other reason many businesses use weak keys). The intent behind this is to protect communication from civilian espionage but not from their own state or other states. Respectfully, R0b0t1 > > gcrypt cannot have all new functions -- otherwise, why not balloon > hashing and scrypt (the latter is used in many kinds of > cryptocurrency)? > > > > On Sat, Oct 14, 2017 at 1:16 PM, R0b0t1 wrote: >> On Sat, Oct 14, 2017 at 12:05 PM, ??(??) wrote: >>> Hi Werner, >>> >>> This is the review request for SM3 hash algorithm. Plz see the commit >>> header and patch for more details. >>> >>> SM3 hash algorithm is already accepted and supported by TPM 2.0 spec. >>> So it is necessary to implement this algorithm in a famous open source >>> software for checking the digest value computed by TPM. >>> >>> Plz refer to this PR (https://github.com/gpg/libgcrypt/pull/2) for code >>> review. >>> >>> Thanks, >>> Jia >>> >> >> Jia, >> >> It is my understanding that SM3 was not accepted into any global TPM >> specification and is merely mandated for use within China. >> >> My research on SM3 has turned up only one detailed cryptanalysis of >> the function.[1] That cryptanalysis implies that the techniques used >> to "strengthen" SM3 do not accomplish what the creators claim, and may >> even weaken the hash function when compared to its inspiration, SHA-2. >> >> Less detailed analysis[3] of the claims presented by the creators >> reflect poorly on their work. For starters, none of the techniques >> meant to increase the security of SM3 are explained. Their utility is >> unknown, and a cursory glance shows that in at least one case a round >> operation is simplified. Perhaps more distressing is the selection of >> constants with no justification. >> >> It seems very likely that the algorithm has undisclosed backdoors. >> >> Also pertinent is the existence of GmSSL,[3] a fork of OpenSSL which >> contains various cryptographic standards developed by the Chinese >> government that were, presumably, not deemed fit for inclusion in >> OpenSSL. >> >> Inclusion of weak cryptography in gcrypt would be a disservice to >> those users which trust gcrypt with their life. I understand I am not >> the person to whom you addressed your message, nor am I a gcrypt >> developer, but I felt it necessary to reply to this conversation. >> >> Respectfully, >> R0b0t1 >> >> >> [1]: https://eprint.iacr.org/2012/274.pdf, also attached. >> [2]: https://tinycrypt.wordpress.com/2017/02/22/asmcodes-sm3/ >> [3]: http://gmssl.org/ >> >> _______________________________________________ >> Gcrypt-devel mailing list >> Gcrypt-devel at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gcrypt-devel >> > > > > -- > > Weikeng Chen @ 795 Soda Hall From w.k at berkeley.edu Mon Oct 16 02:01:50 2017 From: w.k at berkeley.edu (Weikeng Chen) Date: Sun, 15 Oct 2017 17:01:50 -0700 Subject: [PATCH] sm3: implement SM3 hash algorithm In-Reply-To: References: <59E243F4.3030308@alibaba-inc.com> Message-ID: [1] Understood your concern that SM3 does not release the reason for picking constants. This is somehow not solvable. I think this is a sufficient reason not to include it in the gpupg. Because including it would be regarded as an endorsement from open source community. If one day something is wrong, it would be problematic. [2] off-topic issues. Please believe that people in China visiting Google, Facebook, and Youtube are already experts in censorship circumvention (but it is not that easy) -- we are not that stupid after all and not that controlled by the government. I think you misunderstand the usage of SM1-4. It is only used for government-relevant or critical circles (that would be another reason that it is not needed to include today). It is impossible to be used to alternate the HTTPS or anything in today's Internet. So, the government using SM1-4 everywhere does not make it an advantage in breaking our RSA/ECDSA/SHA2/SHA3 based Internet communication that the major public is using (I think we should partly attribute this to the development of gpupg). The political concern now goes a little bit far. [3] Independent of this, I think it is crucial that we have a general rule to discuss to accept or not accept a cipher into gcrypt. Although it is unlikely that in recent years, new standards to replace AES and SHA3 are needed. "Just because you personally can not imagine some weakness in SM3 does not mean there are no weaknesses in SM3." This is not a gold standard that we can use in the future. Cryptography is based on problems that we believe hard today. If P=NP, then theoretically, we have rightly zero cryptographic primitives that can be long-term secure. Many reasons to dispute SM3 can also be used to criticize SHA3, SHA2. No need to say MD2, MD4. There are a bunch of papers on the reduced-round attack in many mainstream ciphers in CRYPTO. But "attack-paper-less" cryptographic algorithms are also not good because of few discussions. [4] Unlike asymmetric encryption, the evaluation of symmetric encryption is really hard. Weikeng On Sun, Oct 15, 2017 at 4:21 PM, R0b0t1 wrote: > On Sun, Oct 15, 2017 at 3:47 AM, Weikeng Chen wrote: >> I think it is unlikely that SM3 contains a backdoor. >> > > This is giving the authors of SM3 a dangerous amount of credit where > it is not due. Their algorithm fails a very basic test: > https://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number. > > At best, they don't know what they are doing and made changes > randomly. At worst, they made changes to make the algorithm > susceptible to an undisclosed attack and could find no justification > to use as a lie. > > Just because you personally can not imagine some weakness in SM3 does > not mean there are no weaknesses in SM3. > >> It is intended to be used in governments and mission-critical devices. >> There is no reason to use something dangerous (then U.S. can break?). >> And it is generally not that easy to add a backdoor in a symmetric >> algorithm if we obtain randomness from a physical source. >> > > The problem with proving a negative in this context; that is, proving > there are no back doors to the algorithm, is that it takes a huge > amount of work. The "Limitations" section of the Wikipedia article > above explains it well: the problem space is so large that any number > of design constraints could have been engineered to provide a weakness > that is only accessible to a party with special knowledge. In this > sense a weakness can be made "safe" and turned into a back door. > > This is one of the major reasons that lack of cryptanalysis for an > algorithm is suspicious: other researchers could consider it a waste > of time to investigate a plausibly backdoored algorithm. > > Even if, however, other nation states were already aware of and could > exploit the weakness, I expect that China would use a weak algorithm. > China may not have the capabilities that other actors do, and may need > to rely on algorithms that would be considered weak to other actors if > China wants to monitor communication within its borders. > > As a good example, look at Russian certificate authorities and content > hosts. Many of them use very weak cryptographic keys. I have seen many > 512 bit RSA keys that are nowhere close to expiring. Seeing as the > Russian intelligence services are apparently not capable of factoring > extremely large primes, they "recommend" weak keys to their citizens > (or for some other reason many businesses use weak keys). The intent > behind this is to protect communication from civilian espionage but > not from their own state or other states. > > Respectfully, > R0b0t1 > > >> >> gcrypt cannot have all new functions -- otherwise, why not balloon >> hashing and scrypt (the latter is used in many kinds of >> cryptocurrency)? >> >> >> >> On Sat, Oct 14, 2017 at 1:16 PM, R0b0t1 wrote: >>> On Sat, Oct 14, 2017 at 12:05 PM, ??(??) wrote: >>>> Hi Werner, >>>> >>>> This is the review request for SM3 hash algorithm. Plz see the commit >>>> header and patch for more details. >>>> >>>> SM3 hash algorithm is already accepted and supported by TPM 2.0 spec. >>>> So it is necessary to implement this algorithm in a famous open source >>>> software for checking the digest value computed by TPM. >>>> >>>> Plz refer to this PR (https://github.com/gpg/libgcrypt/pull/2) for code >>>> review. >>>> >>>> Thanks, >>>> Jia >>>> >>> >>> Jia, >>> >>> It is my understanding that SM3 was not accepted into any global TPM >>> specification and is merely mandated for use within China. >>> >>> My research on SM3 has turned up only one detailed cryptanalysis of >>> the function.[1] That cryptanalysis implies that the techniques used >>> to "strengthen" SM3 do not accomplish what the creators claim, and may >>> even weaken the hash function when compared to its inspiration, SHA-2. >>> >>> Less detailed analysis[3] of the claims presented by the creators >>> reflect poorly on their work. For starters, none of the techniques >>> meant to increase the security of SM3 are explained. Their utility is >>> unknown, and a cursory glance shows that in at least one case a round >>> operation is simplified. Perhaps more distressing is the selection of >>> constants with no justification. >>> >>> It seems very likely that the algorithm has undisclosed backdoors. >>> >>> Also pertinent is the existence of GmSSL,[3] a fork of OpenSSL which >>> contains various cryptographic standards developed by the Chinese >>> government that were, presumably, not deemed fit for inclusion in >>> OpenSSL. >>> >>> Inclusion of weak cryptography in gcrypt would be a disservice to >>> those users which trust gcrypt with their life. I understand I am not >>> the person to whom you addressed your message, nor am I a gcrypt >>> developer, but I felt it necessary to reply to this conversation. >>> >>> Respectfully, >>> R0b0t1 >>> >>> >>> [1]: https://eprint.iacr.org/2012/274.pdf, also attached. >>> [2]: https://tinycrypt.wordpress.com/2017/02/22/asmcodes-sm3/ >>> [3]: http://gmssl.org/ >>> >>> _______________________________________________ >>> Gcrypt-devel mailing list >>> Gcrypt-devel at gnupg.org >>> http://lists.gnupg.org/mailman/listinfo/gcrypt-devel >>> >> >> >> >> -- >> >> Weikeng Chen @ 795 Soda Hall -- Weikeng Chen @ 795 Soda Hall From w.k at berkeley.edu Mon Oct 16 02:34:10 2017 From: w.k at berkeley.edu (Weikeng Chen) Date: Sun, 15 Oct 2017 17:34:10 -0700 Subject: [SUGGESTION NEEDED] A request for suggestion on furthering the discussion over ElGamal Message-ID: Hi Werner, Niibe, and other developers, This is a request for a suggestion. I am going to continue my post last month on the ElGamal in gcrypt. I am sorry to say gcrypt is the beginning of many wrong implementations of ElGamal. Some Github repo owners use this to show their implementation is correct. It uses a safe prime but the generator is still wrong. This makes the ElGamal not semantic secure. My post in September "question on ElGamal implementation" has made the beginning of that. I would like to make a post to continue this further and make sure that we fix ElGamal eventually. Niibe has mentioned that ElGamal used for hybrid encryption in general (which would be secure), but we two agree that we should improve. Some programmers may use ElGamal for homomorphic encryption and computation over encrypted data. Before my post which would explain the details, I have some observations: (1) Showing the current ElGamal implementation is not secure would be easy, as Wikipedia and some 17 years ago papers have some information. If we consult expert cryptographers in the field. They can clearly say the current implementation is insecure. --------- Do you think an experiment or proof-of-concept will be necessary? (2) Providing a corrected version is not trivial -- it is not just making the generator correct. We also need to embed the message (a binary string) into an element in a specific subgroup (and recovered later). There are many papers, and many years ago, to say some ideas about this encoding. One of that is my proposed solution. However, there is no official example. Even the original paper by El Gamal is not secure under this concern. Besides gcrypt, ---------- how to find a gold standard for ElGamal implementations? OpenSSL implements DH (also wrong but not a big deal in the real world, because it is for DH key exchange not ElGamal) ------ and one thing for sure, how to make it easy to follow in order to persuade a sufficiently large community to accept this change? (3) The solution will be incompatible with existing applications running ElGamal in gcrypt -- their ciphertexts will be undecryptable. ----- What is your opinion to deal with this? My question list is: (1) What do you think is needed, served as sufficient evidence, to persuade people to believe (1) current implementation is wrong; (2) the proposed algorithm is correct? (2) What do you think would be a solution for compatibility? (3) Should we consider the external review from cryptographic experts? My doubt on ElGamal encryption is a result of my cryptographic class CS276 at Berkeley. This page contains some reading (http://people.eecs.berkeley.edu/~alexch/classes/CS276-F2015.html). LEC NOTE 14 and PROB SET 4 have further information. Weikeng -- Weikeng Chen @ 795 Soda Hall From qianyue.zj at alibaba-inc.com Mon Oct 16 03:07:50 2017 From: qianyue.zj at alibaba-inc.com (Jia Zhang) Date: Mon, 16 Oct 2017 09:07:50 +0800 Subject: [PATCH] sm3: implement SM3 hash algorithm In-Reply-To: References: <59E243F4.3030308@alibaba-inc.com> Message-ID: <59E40666.7090104@alibaba-inc.com> Everyone has different expection with gcript, and personally I respect the established fact: - TCG approved - Not broke - Known weak algorithms still exist in gcrypt gcrypt is not arrogant. It helps to extend the use of cryptography usage. I think it is time to end up talking about all non-engineering discussion. Until now there is no people talking about the code itself. Jia ? 2017/10/16 ??8:01, Weikeng Chen ??: > [1] Understood your concern that SM3 does not release the reason for > picking constants. This is somehow not solvable. > > I think this is a sufficient reason not to include it in the gpupg. > Because including it would be regarded as an endorsement from open > source community. If one day something is wrong, it would be > problematic. > > > [2] off-topic issues. Please believe that people in China visiting > Google, Facebook, and Youtube are already experts in censorship > circumvention (but it is not that easy) -- we are not that stupid > after all and not that controlled by the government. > > I think you misunderstand the usage of SM1-4. It is only used for > government-relevant or critical circles (that would be another reason > that it is not needed to include today). It is impossible to be used > to alternate the HTTPS or anything in today's Internet. So, the > government using SM1-4 everywhere does not make it an advantage in > breaking our RSA/ECDSA/SHA2/SHA3 based Internet communication that the > major public is using (I think we should partly attribute this to the > development of gpupg). > > The political concern now goes a little bit far. > > > [3] Independent of this, I think it is crucial that we have a general > rule to discuss to accept or not accept a cipher into gcrypt. Although > it is unlikely that in recent years, new standards to replace AES and > SHA3 are needed. > > "Just because you personally can not imagine some weakness in SM3 does > not mean there are no weaknesses in SM3." > > This is not a gold standard that we can use in the future. > Cryptography is based on problems that we believe hard today. If P=NP, > then theoretically, we have rightly zero cryptographic primitives that > can be long-term secure. Many reasons to dispute SM3 can also be used > to criticize SHA3, SHA2. No need to say MD2, MD4. There are a bunch of > papers on the reduced-round attack in many mainstream ciphers in > CRYPTO. But "attack-paper-less" cryptographic algorithms are also not > good because of few discussions. > > > [4] Unlike asymmetric encryption, the evaluation of symmetric > encryption is really hard. > > > Weikeng > > On Sun, Oct 15, 2017 at 4:21 PM, R0b0t1 wrote: >> On Sun, Oct 15, 2017 at 3:47 AM, Weikeng Chen wrote: >>> I think it is unlikely that SM3 contains a backdoor. >>> >> >> This is giving the authors of SM3 a dangerous amount of credit where >> it is not due. Their algorithm fails a very basic test: >> https://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number. >> >> At best, they don't know what they are doing and made changes >> randomly. At worst, they made changes to make the algorithm >> susceptible to an undisclosed attack and could find no justification >> to use as a lie. >> >> Just because you personally can not imagine some weakness in SM3 does >> not mean there are no weaknesses in SM3. >> >>> It is intended to be used in governments and mission-critical devices. >>> There is no reason to use something dangerous (then U.S. can break?). >>> And it is generally not that easy to add a backdoor in a symmetric >>> algorithm if we obtain randomness from a physical source. >>> >> >> The problem with proving a negative in this context; that is, proving >> there are no back doors to the algorithm, is that it takes a huge >> amount of work. The "Limitations" section of the Wikipedia article >> above explains it well: the problem space is so large that any number >> of design constraints could have been engineered to provide a weakness >> that is only accessible to a party with special knowledge. In this >> sense a weakness can be made "safe" and turned into a back door. >> >> This is one of the major reasons that lack of cryptanalysis for an >> algorithm is suspicious: other researchers could consider it a waste >> of time to investigate a plausibly backdoored algorithm. >> >> Even if, however, other nation states were already aware of and could >> exploit the weakness, I expect that China would use a weak algorithm. >> China may not have the capabilities that other actors do, and may need >> to rely on algorithms that would be considered weak to other actors if >> China wants to monitor communication within its borders. >> >> As a good example, look at Russian certificate authorities and content >> hosts. Many of them use very weak cryptographic keys. I have seen many >> 512 bit RSA keys that are nowhere close to expiring. Seeing as the >> Russian intelligence services are apparently not capable of factoring >> extremely large primes, they "recommend" weak keys to their citizens >> (or for some other reason many businesses use weak keys). The intent >> behind this is to protect communication from civilian espionage but >> not from their own state or other states. >> >> Respectfully, >> R0b0t1 >> >> >>> >>> gcrypt cannot have all new functions -- otherwise, why not balloon >>> hashing and scrypt (the latter is used in many kinds of >>> cryptocurrency)? >>> >>> >>> >>> On Sat, Oct 14, 2017 at 1:16 PM, R0b0t1 wrote: >>>> On Sat, Oct 14, 2017 at 12:05 PM, ??(??) wrote: >>>>> Hi Werner, >>>>> >>>>> This is the review request for SM3 hash algorithm. Plz see the commit >>>>> header and patch for more details. >>>>> >>>>> SM3 hash algorithm is already accepted and supported by TPM 2.0 spec. >>>>> So it is necessary to implement this algorithm in a famous open source >>>>> software for checking the digest value computed by TPM. >>>>> >>>>> Plz refer to this PR (https://github.com/gpg/libgcrypt/pull/2) for code >>>>> review. >>>>> >>>>> Thanks, >>>>> Jia >>>>> >>>> >>>> Jia, >>>> >>>> It is my understanding that SM3 was not accepted into any global TPM >>>> specification and is merely mandated for use within China. >>>> >>>> My research on SM3 has turned up only one detailed cryptanalysis of >>>> the function.[1] That cryptanalysis implies that the techniques used >>>> to "strengthen" SM3 do not accomplish what the creators claim, and may >>>> even weaken the hash function when compared to its inspiration, SHA-2. >>>> >>>> Less detailed analysis[3] of the claims presented by the creators >>>> reflect poorly on their work. For starters, none of the techniques >>>> meant to increase the security of SM3 are explained. Their utility is >>>> unknown, and a cursory glance shows that in at least one case a round >>>> operation is simplified. Perhaps more distressing is the selection of >>>> constants with no justification. >>>> >>>> It seems very likely that the algorithm has undisclosed backdoors. >>>> >>>> Also pertinent is the existence of GmSSL,[3] a fork of OpenSSL which >>>> contains various cryptographic standards developed by the Chinese >>>> government that were, presumably, not deemed fit for inclusion in >>>> OpenSSL. >>>> >>>> Inclusion of weak cryptography in gcrypt would be a disservice to >>>> those users which trust gcrypt with their life. I understand I am not >>>> the person to whom you addressed your message, nor am I a gcrypt >>>> developer, but I felt it necessary to reply to this conversation. >>>> >>>> Respectfully, >>>> R0b0t1 >>>> >>>> >>>> [1]: https://eprint.iacr.org/2012/274.pdf, also attached. >>>> [2]: https://tinycrypt.wordpress.com/2017/02/22/asmcodes-sm3/ >>>> [3]: http://gmssl.org/ >>>> >>>> _______________________________________________ >>>> Gcrypt-devel mailing list >>>> Gcrypt-devel at gnupg.org >>>> http://lists.gnupg.org/mailman/listinfo/gcrypt-devel >>>> >>> >>> >>> >>> -- >>> >>> Weikeng Chen @ 795 Soda Hall > > > From wk at gnupg.org Mon Oct 16 11:27:41 2017 From: wk at gnupg.org (Werner Koch) Date: Mon, 16 Oct 2017 11:27:41 +0200 Subject: [PATCH] sm3: implement SM3 hash algorithm In-Reply-To: (Weikeng Chen's message of "Sun, 15 Oct 2017 01:47:02 -0700") References: <59E243F4.3030308@alibaba-inc.com> Message-ID: <87efq3wigi.fsf@wheatstone.g10code.de> On Sun, 15 Oct 2017 10:47, w.k at berkeley.edu said: > gcrypt cannot have all new functions -- otherwise, why not balloon > hashing and scrypt (the latter is used in many kinds of > cryptocurrency)? Libgcrypt features the SCRYPT KDF since 1.6.0. Whether or not a algorithm is added to Libgcrypt does not only depend on the strongness of a algorithm. There are algorithm in Libgcrypt which are either known as weak or somehow suspect (MD5, MD2, Arcfour, RC2, several curves). Reasons to include them are: They used to be considered string, they are used in in protocols or data format (e.g. MD5 in PGP-2), or there are political reasons (e.g. Camellia, Seed). It is up to the application to decide which algorithm to use. Recall that Libgcrypt is not GnuPG. GnuPG it is merely an application using Libgcrypt and its has its own list of algorithms. Some of these algorithm are used in a read-only way and will even print a warning when used. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 357 bytes Desc: not available URL: From gniibe at fsij.org Tue Oct 17 03:03:33 2017 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 17 Oct 2017 10:03:33 +0900 Subject: [PATCH] sm3: implement SM3 hash algorithm In-Reply-To: <59E243F4.3030308@alibaba-inc.com> References: <59E243F4.3030308@alibaba-inc.com> Message-ID: <878tgah9ga.fsf@iwagami.gniibe.org> "??(??)" wrote: > Hi Werner, Sorry, I'm not Werner, but another (old ???) developer of libgcrypt. > This is the review request for SM3 hash algorithm. Plz see the commit > header and patch for more details. To track this, I created a ticket at: https://dev.gnupg.org/T3454 Could you please send the patch to gcrypt-devel? Or, you can upload your patch to: https://dev.gnupg.org/differential/ > SM3 hash algorithm is already accepted and supported by TPM 2.0 spec. > So it is necessary to implement this algorithm in a famous open source > software for checking the digest value computed by TPM. Out of curiosity, is it mandated by the goverment? If so, how about SM2? When I read FIDO U2F document in this April, I learned about optional SM2 and SM3. > Plz refer to this PR (https://github.com/gpg/libgcrypt/pull/2) for code > review. We don't have a practice to use GitHub, which might require non-free JavaScript. Please read libgcrypt/doc/HACKING, the "How to contribute" section, especially the "License policy" subsection. -- From gniibe at fsij.org Tue Oct 17 04:03:58 2017 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 17 Oct 2017 11:03:58 +0900 Subject: [SUGGESTION NEEDED] A request for suggestion on furthering the discussion over ElGamal In-Reply-To: References: Message-ID: <8760beh6nl.fsf@iwagami.gniibe.org> Hello, Weikeng Chen wrote: > I am going to continue my post last month on the ElGamal in gcrypt. I > am sorry to say gcrypt is the beginning of many wrong implementations > of ElGamal. Some Github repo owners use this to show their > implementation is correct. It uses a safe prime but the generator is > still wrong. This makes the ElGamal not semantic secure. Historically speaking, libgcrypt was factored out from GnuPG. So, its ElGamal API and the implementation are primarily intended to be used by GnuPG. In this context, it is perfectly OK. I mean, "semantic security" of the crypto system doesn't matter to the security of the application. > Niibe has mentioned that ElGamal used for hybrid encryption in general > (which would be secure), but we two agree that we should improve. I agreed that it make sense to improve the generator. I don't think it is mandatory. I didn't mean introducing new or drastic change which may impact existing usages. > Some programmers may use ElGamal for homomorphic encryption and > computation over encrypted data. Interesting. In that case, I wonder if current API of libgcrypt is enough or good. (I guess that... I don't think it's enough.) > (1) Showing the current ElGamal implementation is not secure would be > easy, as Wikipedia and some 17 years ago papers have some information. > If we consult expert cryptographers in the field. They can clearly say > the current implementation is insecure. --------- Do you think an > experiment or proof-of-concept will be necessary? If possible, please use careful wording. The API of crypto library which implements crypto system lacking "semantic security" property does not automatically mean "insecure". For a library, its usage by an application matters. > (2) Providing a corrected version is not trivial -- it is not just > making the generator correct. We also need to embed the message (a > binary string) into an element in a specific subgroup (and recovered > later). There are many papers, and many years ago, to say some ideas > about this encoding. One of that is my proposed solution. You are talking about new crypto protocol, using ElGamal crypto system, don't you? > However, there is no official example. Even the original paper by El > Gamal is not secure under this concern. Besides gcrypt, ---------- how > to find a gold standard for ElGamal implementations? OpenSSL > implements DH (also wrong but not a big deal in the real world, > because it is for DH key exchange not ElGamal) ------ and one thing > for sure, how to make it easy to follow in order to persuade a > sufficiently large community to accept this change? It seems for me that you have some confusions among: (1) ElGamal crypto system (2) crypto protocol which uses ElGamal crypto system --- e.g. OpenPGP (3) an implementation, in this case, partial implementation of (1) --- e.g. libcrypt (4) an application of (3) which implements (2) --- e.g. GnuPG I would admit that libgcrypt API is not enough to provide full features of ElGamal crypto system, for example, as you pointed out, it doesn't provide "semantically secure" use case. In other words, I could say, libgcrypt's API for ElGamal just offers things needed for OpenPGP protocol. Actually, I think that "ElGamal crypto system" can refer different crypto systems. I think that your interpretation would be too modern, and I'm afraid we can't find any existing (free software) implementation which offers full features you'd like. > (3) The solution will be incompatible with existing applications > running ElGamal in gcrypt -- their ciphertexts will be undecryptable. > ----- What is your opinion to deal with this? If you are introducing new crypto protocol, old and new protocol can co-exist, if designed carefully. > My doubt on ElGamal encryption is a result of my cryptographic class > CS276 at Berkeley. This page contains some reading > (http://people.eecs.berkeley.edu/~alexch/classes/CS276-F2015.html). > LEC NOTE 14 and PROB SET 4 have further information. I think that you can ask your teacher. That would be better. -- From w.k at berkeley.edu Tue Oct 17 04:46:09 2017 From: w.k at berkeley.edu (Weikeng Chen) Date: Mon, 16 Oct 2017 19:46:09 -0700 Subject: [SUGGESTION NEEDED] A request for suggestion on furthering the discussion over ElGamal In-Reply-To: <8760beh6nl.fsf@iwagami.gniibe.org> References: <8760beh6nl.fsf@iwagami.gniibe.org> Message-ID: Thank Niibe. Actually, my teacher Alessandro (an assistant professor of cryptography and theory) and I (a Ph.D. student on applied cryptography) have a brief discussion after the class. As far as we see, the current ElGamal implementation does not achieve semantic security. Niibe mentions that the high-level application which uses ElGamal in black-box may be okay because it uses for hybrid encryption. I agree because if ElGamal is not used for direct data encryption, but only in the hybrid encryption, then knowing one bit of the encryption key does not help to break the symmetric encryption ---- However, it is annoying for cryptographers. Because we require semantic security on all other cryptographic primitives, and the rest are implemented generally correct. And in non-hybrid encryption cases, it is problematic. So if the scope of using ElGamal only for hybrid encryptions, it should be totally okay. But what I add is: (1) If it is used to load message directly, it significantly leaks information of that message. (2) Due to the usage of ElGamal in homomorphic encryption, there are use cases where we cannot use hybrid encryption, so at this case, the messages are loaded directly. (3) gcrypt as the model of many cryptographic libraries is treated (at least people do) as a standard. It is part of the source of the massive problem in implementing ElGamal. Let me add some words on the semantic security. [Quick Recap of ElGamal] Assume the ElGamal private key is $x$, and the public key is $g^x$ where $g$ is a generator of $Z_p^*$. The encryption of message $m$ where $k$ is selected randomly: - First part of the ciphertext: m g^{xk} - Second part of the ciphertext: g^k [Semantic Security] This is the general security requirement for all symmetric and asymmetric ciphers. The scheme can ensure that a computer run under a polynomial function of the security parameter cannot learn anything information from the ciphertexts except the length with a non-negligible possibility in respect to the security parameter. Or, tweaking a sufficiently large security parameter (like 2048 bit for RSA today), nobody except supermen can learn anything except the length. The non-textbook version of RSA (with random padding) achieves semantic security. The symmetric ciphers under some encryption modes [Test Example] Assume we have $m_0$ and $m_1$. They are different. [Are They Quadratic Residues?] Half of the all possible $m$ accepted by ElGamal are Quadratic Residues, and those remaining are not Quadratic Residues. (So it leaks information worth of 1 bit). A number $m$ is QR. Then there is a value $x$ so that $m=x^2 mod p$. If a number $m$ is not QR, then such $x$ does not exist. [Possibility that $m_0$ and $m_1$ different in QR] The possibility that $m_0$ and $m_1$ are, not both QR and not both non-QR, are 1/2. In this case, we can distinguish $m_0$ and $m_1$ by whether or not QR. [What happens after encryption?] Let us play a game: assume I know whether or not your private key $x$ is odd or even (this is a reasonable assumption because the same asymmetric key is used repeatedly). Without loss of generality, I assume $x$ is odd, and $g^x$ is non-QR. You encrypt a message $m$. The ciphertexts are $c=(m g^{xk}, g^k)$. If $g^k$ is QR, then $g^{xk}$ is also a QR. If $g^k$ is non-QR, then $g^{xk}$ is also a non-QR. If $m g^{xk}$ is a QR, $g^k$ is QR => $m$ is a QR If $m g^{xk}$ is a non-QR, $g^k$ is QR => $m$ is a non-QR If $m g^{xk}$ is a QR, $g^k$ is non-QR => $m$ is a non-QR If $m g^{xk}$ is a non-QR, $g^k$ is non-QR => $m$ is a QR You see. I can distinguish whether $m$ is QR or not even if it is encrypted -- the ciphertext leaks one-bit information about the underlying message. Another case. Let us assume $x$ is even and $g^x$ is QR. You encrypt a message $m$. The ciphertexts are $c=(m g^{xk}, g^k)$. Then if $m g^{xk}$ is QR, $m$ is QR. If $m g^{xk}$ is non-QR, $m$ is non-QR. It is even easier to guess this one-bit information of the plaintext from the ciphertext. [Summary] The implementation that uses $g$ as the generator of $Z_p^*$ and uses no specific encoding of $m$, the ciphertext leaks one bit about the underlying plaintext. ================ First part ended. Next email will continue. On Mon, Oct 16, 2017 at 7:03 PM, NIIBE Yutaka wrote: > Hello, > > Weikeng Chen wrote: >> I am going to continue my post last month on the ElGamal in gcrypt. I >> am sorry to say gcrypt is the beginning of many wrong implementations >> of ElGamal. Some Github repo owners use this to show their >> implementation is correct. It uses a safe prime but the generator is >> still wrong. This makes the ElGamal not semantic secure. > > Historically speaking, libgcrypt was factored out from GnuPG. So, its > ElGamal API and the implementation are primarily intended to be used by > GnuPG. In this context, it is perfectly OK. I mean, "semantic > security" of the crypto system doesn't matter to the security of the > application. > >> Niibe has mentioned that ElGamal used for hybrid encryption in general >> (which would be secure), but we two agree that we should improve. > > I agreed that it make sense to improve the generator. I don't think it > is mandatory. I didn't mean introducing new or drastic change which may > impact existing usages. > >> Some programmers may use ElGamal for homomorphic encryption and >> computation over encrypted data. > > Interesting. In that case, I wonder if current API of libgcrypt is > enough or good. (I guess that... I don't think it's enough.) > >> (1) Showing the current ElGamal implementation is not secure would be >> easy, as Wikipedia and some 17 years ago papers have some information. >> If we consult expert cryptographers in the field. They can clearly say >> the current implementation is insecure. --------- Do you think an >> experiment or proof-of-concept will be necessary? > > If possible, please use careful wording. > > The API of crypto library which implements crypto system lacking > "semantic security" property does not automatically mean "insecure". > For a library, its usage by an application matters. > >> (2) Providing a corrected version is not trivial -- it is not just >> making the generator correct. We also need to embed the message (a >> binary string) into an element in a specific subgroup (and recovered >> later). There are many papers, and many years ago, to say some ideas >> about this encoding. One of that is my proposed solution. > > You are talking about new crypto protocol, using ElGamal crypto system, > don't you? > >> However, there is no official example. Even the original paper by El >> Gamal is not secure under this concern. Besides gcrypt, ---------- how >> to find a gold standard for ElGamal implementations? OpenSSL >> implements DH (also wrong but not a big deal in the real world, >> because it is for DH key exchange not ElGamal) ------ and one thing >> for sure, how to make it easy to follow in order to persuade a >> sufficiently large community to accept this change? > > It seems for me that you have some confusions among: > > (1) ElGamal crypto system > (2) crypto protocol which uses ElGamal crypto system > --- e.g. OpenPGP > (3) an implementation, in this case, partial implementation of (1) > --- e.g. libcrypt > (4) an application of (3) which implements (2) > --- e.g. GnuPG > > I would admit that libgcrypt API is not enough to provide full features > of ElGamal crypto system, for example, as you pointed out, it doesn't > provide "semantically secure" use case. In other words, I could say, > libgcrypt's API for ElGamal just offers things needed for OpenPGP > protocol. > > Actually, I think that "ElGamal crypto system" can refer different > crypto systems. I think that your interpretation would be too modern, > and I'm afraid we can't find any existing (free software) implementation > which offers full features you'd like. > >> (3) The solution will be incompatible with existing applications >> running ElGamal in gcrypt -- their ciphertexts will be undecryptable. >> ----- What is your opinion to deal with this? > > If you are introducing new crypto protocol, old and new protocol can > co-exist, if designed carefully. > > >> My doubt on ElGamal encryption is a result of my cryptographic class >> CS276 at Berkeley. This page contains some reading >> (http://people.eecs.berkeley.edu/~alexch/classes/CS276-F2015.html). >> LEC NOTE 14 and PROB SET 4 have further information. > > I think that you can ask your teacher. That would be better. > -- -- Weikeng Chen @ 795 Soda Hall From w.k at berkeley.edu Tue Oct 17 05:42:33 2017 From: w.k at berkeley.edu (Weikeng Chen) Date: Mon, 16 Oct 2017 20:42:33 -0700 Subject: [SUGGESTION NEEDED] A request for suggestion on furthering the discussion over ElGamal In-Reply-To: References: <8760beh6nl.fsf@iwagami.gniibe.org> Message-ID: [Discussion of this problem] The original paper of El Gamal does not mention this problem. (Same does the first paper for RSA) In 1998, Professor Dan Boneh (IACR fellow, Stanford) published a paper "The Decisional Diffie-Hellman Problem" http://crypto.stanford.edu/~dabo/pubs/papers/DDH.pdf on the page 9-10, it mentions the necessity of using DDH for ElGamal. The leakage mentioned above is from that paper. The Wikipedia (https://en.wikipedia.org/wiki/ElGamal_encryption) talked about the DDH assumption and CDH assumption. DDH assumptions (https://en.wikipedia.org/wiki/Decisional_Diffie%E2%80%93Hellman_assumption) does not hold for $Z_p^*$ because it is not prime-order (the order is $p-1$). The formal treatment for DDH is to: (1) Generate a safe prime $p=2q+1$. (2) Find a generator $g$ for $Z_p^*$. (3) Compute $h=g^2$. This is a QR. Use this as the generator for ElGamal. This makes sure that $g^{xk}$ and $g^k$ are always QR, removing the first part of the leakage. To ensure the message leaks nothing, we need to make $m$ as a QR. This is not trivial. Because $m$ is generally binary string. They are free and not controlled. It might not be a QR or be a QR. In CRYPTO'98, the highest conference of cryptography, Ronald Cramer and Victor Shoup (IACR fellow) proposed a solution (http://people.csail.mit.edu/alinush/6.857-spring-2015/papers/cramer-shoup.pdf): (1) Given the message $m$ in $Z_p^*$. (2) Compute the encoding $e=m^2$. (3) Decoding is done by computing the unique square root of $e$ (by powering $(q+1)/2$) Then the ciphertexts under ElGamal now are all QR. The leakage from that is fixed. More than that, such a construction of ElGamal is proved to be semantic secure if the DDH assumption holds. [Other materials] Lecture note of Public Key Encryption at UC Berkeley on Graduate Cryptography (CS276). Instructor Alessandro Chiesa, one of the inventors of zerocash and then zCash. (Page 2-3) https://128.32.189.73/~alexch/docs/CS276-F2015/lecture-14.pdf Lecture note of CS276 at UC Berkeley. Instructor Luca Trevisan, a professor in theory computer science. (Page 3-4) https://people.eecs.berkeley.edu/~luca/cs276/lecture17.pdf Lecture note of CSE207 in UCSD. Instructor Mihir Bellare, an inventor or RSA-OAEP and HMAC. (last paper) http://cseweb.ucsd.edu/~mihir/cse207/w-asym.pdf Lecture note of CS4380 in Cornell, Instructor Rafeal Pass. (Page 105-106) http://www.cs.cornell.edu/courses/cs4830/2010fa/lecnotes.pdf These materials all support the idea above. [Proposed Solution] This is totally not invented by me. But the idea merged of these notes and papers. But as I said, there is no standard on how to fix ElGamal, because cryptography world originally has no so-called standard-making organization. [1] We choose the generator as a QR. $h=g^2$ [2] We encode the message by squaring it, and decode it back by finding the unique square root (i.e. powering (q+1)/2). $m2=m^2$. $m=(m_2)^((q+1)/2)$. [Not Compatible] I agree with Niibe that we may be able to make it coexisting. But it turns out that we need to make it clear in the "key". Because a ciphertext generated by the old version cannot be decoded back (the unique square root is nonsense). And new ciphertexts cannot be recovered by the old system because of the lack of decoding. [My Suggestion] - Add ElGamal-DDH independent to ElGamal. - Add a comment in original ElGamal that "it is not semantic secure so cannot be used for applications besides hybrid encryption". The hybrid encryption use case is okay because CDH can hold. This is proved by Dan Boneh in that year 2000 paper. =========== END. Should I make a slide? On Mon, Oct 16, 2017 at 7:46 PM, Weikeng Chen wrote: > Thank Niibe. > > Actually, my teacher Alessandro (an assistant professor of > cryptography and theory) and I (a Ph.D. student on applied > cryptography) have a brief discussion after the class. As far as we > see, the current ElGamal implementation does not achieve semantic > security. Niibe mentions that the high-level application which uses > ElGamal in black-box may be okay because it uses for hybrid > encryption. > > I agree because if ElGamal is not used for direct data encryption, but > only in the hybrid encryption, then knowing one bit of the encryption > key does not help to break the symmetric encryption ---- However, it > is annoying for cryptographers. Because we require semantic security > on all other cryptographic primitives, and the rest are implemented > generally correct. And in non-hybrid encryption cases, it is > problematic. > > So if the scope of using ElGamal only for hybrid encryptions, it > should be totally okay. But what I add is: > (1) If it is used to load message directly, it significantly leaks > information of that message. > (2) Due to the usage of ElGamal in homomorphic encryption, there are > use cases where we cannot use hybrid encryption, so at this case, the > messages are loaded directly. > (3) gcrypt as the model of many cryptographic libraries is treated (at > least people do) as a standard. It is part of the source of the > massive problem in implementing ElGamal. > > Let me add some words on the semantic security. > > > [Quick Recap of ElGamal] Assume the ElGamal private key is $x$, and > the public key is $g^x$ where $g$ is a generator of $Z_p^*$. > > The encryption of message $m$ where $k$ is selected randomly: > - First part of the ciphertext: m g^{xk} > - Second part of the ciphertext: g^k > > > [Semantic Security] This is the general security requirement for all > symmetric and asymmetric ciphers. The scheme can ensure that a > computer run under a polynomial function of the security parameter > cannot learn anything information from the ciphertexts except the > length with a non-negligible possibility in respect to the security > parameter. > > Or, tweaking a sufficiently large security parameter (like 2048 bit > for RSA today), nobody except supermen can learn anything except the > length. > > The non-textbook version of RSA (with random padding) achieves > semantic security. The symmetric ciphers under some encryption modes > > > [Test Example] Assume we have $m_0$ and $m_1$. They are different. > > > [Are They Quadratic Residues?] Half of the all possible $m$ accepted > by ElGamal are Quadratic Residues, and those remaining are not > Quadratic Residues. (So it leaks information worth of 1 bit). A number > $m$ is QR. Then there is a value $x$ so that $m=x^2 mod p$. If a > number $m$ is not QR, then such $x$ does not exist. > > > [Possibility that $m_0$ and $m_1$ different in QR] The possibility > that $m_0$ and $m_1$ are, not both QR and not both non-QR, are 1/2. In > this case, we can distinguish $m_0$ and $m_1$ by whether or not QR. > > > [What happens after encryption?] Let us play a game: assume I know > whether or not your private key $x$ is odd or even (this is a > reasonable assumption because the same asymmetric key is used > repeatedly). Without loss of generality, I assume $x$ is odd, and > $g^x$ is non-QR. > > You encrypt a message $m$. The ciphertexts are $c=(m g^{xk}, g^k)$. > > If $g^k$ is QR, then $g^{xk}$ is also a QR. If $g^k$ is non-QR, then > $g^{xk}$ is also a non-QR. > > If $m g^{xk}$ is a QR, $g^k$ is QR => $m$ is a QR > If $m g^{xk}$ is a non-QR, $g^k$ is QR => $m$ is a non-QR > If $m g^{xk}$ is a QR, $g^k$ is non-QR => $m$ is a non-QR > If $m g^{xk}$ is a non-QR, $g^k$ is non-QR => $m$ is a QR > > You see. I can distinguish whether $m$ is QR or not even if it is > encrypted -- the ciphertext leaks one-bit information about the > underlying message. > > Another case. Let us assume $x$ is even and $g^x$ is QR. You encrypt a > message $m$. The ciphertexts are $c=(m g^{xk}, g^k)$. > > Then if $m g^{xk}$ is QR, $m$ is QR. > If $m g^{xk}$ is non-QR, $m$ is non-QR. > > It is even easier to guess this one-bit information of the plaintext > from the ciphertext. > > > [Summary] The implementation that uses $g$ as the generator of $Z_p^*$ > and uses no specific encoding of $m$, the ciphertext leaks one bit > about the underlying plaintext. > > > ================ First part ended. Next email will continue. > > On Mon, Oct 16, 2017 at 7:03 PM, NIIBE Yutaka wrote: >> Hello, >> >> Weikeng Chen wrote: >>> I am going to continue my post last month on the ElGamal in gcrypt. I >>> am sorry to say gcrypt is the beginning of many wrong implementations >>> of ElGamal. Some Github repo owners use this to show their >>> implementation is correct. It uses a safe prime but the generator is >>> still wrong. This makes the ElGamal not semantic secure. >> >> Historically speaking, libgcrypt was factored out from GnuPG. So, its >> ElGamal API and the implementation are primarily intended to be used by >> GnuPG. In this context, it is perfectly OK. I mean, "semantic >> security" of the crypto system doesn't matter to the security of the >> application. >> >>> Niibe has mentioned that ElGamal used for hybrid encryption in general >>> (which would be secure), but we two agree that we should improve. >> >> I agreed that it make sense to improve the generator. I don't think it >> is mandatory. I didn't mean introducing new or drastic change which may >> impact existing usages. >> >>> Some programmers may use ElGamal for homomorphic encryption and >>> computation over encrypted data. >> >> Interesting. In that case, I wonder if current API of libgcrypt is >> enough or good. (I guess that... I don't think it's enough.) >> >>> (1) Showing the current ElGamal implementation is not secure would be >>> easy, as Wikipedia and some 17 years ago papers have some information. >>> If we consult expert cryptographers in the field. They can clearly say >>> the current implementation is insecure. --------- Do you think an >>> experiment or proof-of-concept will be necessary? >> >> If possible, please use careful wording. >> >> The API of crypto library which implements crypto system lacking >> "semantic security" property does not automatically mean "insecure". >> For a library, its usage by an application matters. >> >>> (2) Providing a corrected version is not trivial -- it is not just >>> making the generator correct. We also need to embed the message (a >>> binary string) into an element in a specific subgroup (and recovered >>> later). There are many papers, and many years ago, to say some ideas >>> about this encoding. One of that is my proposed solution. >> >> You are talking about new crypto protocol, using ElGamal crypto system, >> don't you? >> >>> However, there is no official example. Even the original paper by El >>> Gamal is not secure under this concern. Besides gcrypt, ---------- how >>> to find a gold standard for ElGamal implementations? OpenSSL >>> implements DH (also wrong but not a big deal in the real world, >>> because it is for DH key exchange not ElGamal) ------ and one thing >>> for sure, how to make it easy to follow in order to persuade a >>> sufficiently large community to accept this change? >> >> It seems for me that you have some confusions among: >> >> (1) ElGamal crypto system >> (2) crypto protocol which uses ElGamal crypto system >> --- e.g. OpenPGP >> (3) an implementation, in this case, partial implementation of (1) >> --- e.g. libcrypt >> (4) an application of (3) which implements (2) >> --- e.g. GnuPG >> >> I would admit that libgcrypt API is not enough to provide full features >> of ElGamal crypto system, for example, as you pointed out, it doesn't >> provide "semantically secure" use case. In other words, I could say, >> libgcrypt's API for ElGamal just offers things needed for OpenPGP >> protocol. >> >> Actually, I think that "ElGamal crypto system" can refer different >> crypto systems. I think that your interpretation would be too modern, >> and I'm afraid we can't find any existing (free software) implementation >> which offers full features you'd like. >> >>> (3) The solution will be incompatible with existing applications >>> running ElGamal in gcrypt -- their ciphertexts will be undecryptable. >>> ----- What is your opinion to deal with this? >> >> If you are introducing new crypto protocol, old and new protocol can >> co-exist, if designed carefully. >> >> >>> My doubt on ElGamal encryption is a result of my cryptographic class >>> CS276 at Berkeley. This page contains some reading >>> (http://people.eecs.berkeley.edu/~alexch/classes/CS276-F2015.html). >>> LEC NOTE 14 and PROB SET 4 have further information. >> >> I think that you can ask your teacher. That would be better. >> -- > > > > -- > > Weikeng Chen @ 795 Soda Hall -- Weikeng Chen @ 795 Soda Hall From w.k at berkeley.edu Tue Oct 17 05:58:47 2017 From: w.k at berkeley.edu (Weikeng Chen) Date: Mon, 16 Oct 2017 20:58:47 -0700 Subject: [SUGGESTION NEEDED] A request for suggestion on furthering the discussion over ElGamal In-Reply-To: References: <8760beh6nl.fsf@iwagami.gniibe.org>

Message-ID: And thank everybody who spends time reading these two long emails. Also a question for confirmation. Upper applications in GNUPG only use ElGamal for hybrid encryptions? Then it would be totally fine at this moment. The reason I came here is the PyCrypto. https://github.com/Legrandin/pycryptodome/issues/90 The author seems to misunderstand the code (which passed from the previous PyCrypto). Part of the reason is that they use libgcrypt to SELF-TEST the implementation of ElGamal... That is why I came here -- gcrypt is the mother of many things, and this is the crucial first step. https://github.com/Legrandin/pycryptodome/blob/master/lib/Crypto/SelfTest/PublicKey/test_ElGamal.py Almost all ElGamal implementations in Github have a gap with the cryptography's perspective. (But yes, they are consistent with the original paper of El Gamal...) If El Gamal is as famous as RSA, I think we will consider Encoding, as we do in RSA -- the original paper version of RSA is also not semantic secure. On Mon, Oct 16, 2017 at 8:42 PM, Weikeng Chen wrote: > [Discussion of this problem] The original paper of El Gamal does not > mention this problem. (Same does the first paper for RSA) > > In 1998, Professor Dan Boneh (IACR fellow, Stanford) published a paper > "The Decisional Diffie-Hellman Problem" > http://crypto.stanford.edu/~dabo/pubs/papers/DDH.pdf on the page > 9-10, it mentions the necessity of using DDH for ElGamal. The leakage > mentioned above is from that paper. > > The Wikipedia (https://en.wikipedia.org/wiki/ElGamal_encryption) > talked about the DDH assumption and CDH assumption. DDH assumptions > (https://en.wikipedia.org/wiki/Decisional_Diffie%E2%80%93Hellman_assumption) > does not hold for $Z_p^*$ because it is not prime-order (the order is > $p-1$). > > The formal treatment for DDH is to: > (1) Generate a safe prime $p=2q+1$. > (2) Find a generator $g$ for $Z_p^*$. > (3) Compute $h=g^2$. This is a QR. Use this as the generator for ElGamal. > > This makes sure that $g^{xk}$ and $g^k$ are always QR, removing the > first part of the leakage. > > > To ensure the message leaks nothing, we need to make $m$ as a QR. This > is not trivial. Because $m$ is generally binary string. They are free > and not controlled. It might not be a QR or be a QR. > > In CRYPTO'98, the highest conference of cryptography, Ronald Cramer > and Victor Shoup (IACR fellow) proposed a solution > (http://people.csail.mit.edu/alinush/6.857-spring-2015/papers/cramer-shoup.pdf): > (1) Given the message $m$ in $Z_p^*$. > (2) Compute the encoding $e=m^2$. > (3) Decoding is done by computing the unique square root of $e$ (by > powering $(q+1)/2$) > > Then the ciphertexts under ElGamal now are all QR. The leakage from > that is fixed. > > More than that, such a construction of ElGamal is proved to be > semantic secure if the DDH assumption holds. > > > [Other materials] > > Lecture note of Public Key Encryption at UC Berkeley on Graduate > Cryptography (CS276). Instructor Alessandro Chiesa, one of the > inventors of zerocash and then zCash. (Page 2-3) > https://128.32.189.73/~alexch/docs/CS276-F2015/lecture-14.pdf > > Lecture note of CS276 at UC Berkeley. Instructor Luca Trevisan, a > professor in theory computer science. (Page 3-4) > https://people.eecs.berkeley.edu/~luca/cs276/lecture17.pdf > > Lecture note of CSE207 in UCSD. Instructor Mihir Bellare, an inventor > or RSA-OAEP and HMAC. (last paper) > http://cseweb.ucsd.edu/~mihir/cse207/w-asym.pdf > > Lecture note of CS4380 in Cornell, Instructor Rafeal Pass. (Page 105-106) > http://www.cs.cornell.edu/courses/cs4830/2010fa/lecnotes.pdf > > These materials all support the idea above. > > > [Proposed Solution] This is totally not invented by me. But the idea > merged of these notes and papers. But as I said, there is no standard > on how to fix ElGamal, because cryptography world originally has no > so-called standard-making organization. > > [1] We choose the generator as a QR. $h=g^2$ > [2] We encode the message by squaring it, and decode it back by > finding the unique square root (i.e. powering (q+1)/2). $m2=m^2$. > $m=(m_2)^((q+1)/2)$. > > > > [Not Compatible] I agree with Niibe that we may be able to make it > coexisting. But it turns out that we need to make it clear in the > "key". > > Because a ciphertext generated by the old version cannot be decoded > back (the unique square root is nonsense). And new ciphertexts cannot > be recovered by the old system because of the lack of decoding. > > > [My Suggestion] > - Add ElGamal-DDH independent to ElGamal. > - Add a comment in original ElGamal that "it is not semantic secure > so cannot be used for applications besides hybrid encryption". > > The hybrid encryption use case is okay because CDH can hold. This is > proved by Dan Boneh in that year 2000 paper. > > > =========== END. Should I make a slide? > > > > On Mon, Oct 16, 2017 at 7:46 PM, Weikeng Chen wrote: >> Thank Niibe. >> >> Actually, my teacher Alessandro (an assistant professor of >> cryptography and theory) and I (a Ph.D. student on applied >> cryptography) have a brief discussion after the class. As far as we >> see, the current ElGamal implementation does not achieve semantic >> security. Niibe mentions that the high-level application which uses >> ElGamal in black-box may be okay because it uses for hybrid >> encryption. >> >> I agree because if ElGamal is not used for direct data encryption, but >> only in the hybrid encryption, then knowing one bit of the encryption >> key does not help to break the symmetric encryption ---- However, it >> is annoying for cryptographers. Because we require semantic security >> on all other cryptographic primitives, and the rest are implemented >> generally correct. And in non-hybrid encryption cases, it is >> problematic. >> >> So if the scope of using ElGamal only for hybrid encryptions, it >> should be totally okay. But what I add is: >> (1) If it is used to load message directly, it significantly leaks >> information of that message. >> (2) Due to the usage of ElGamal in homomorphic encryption, there are >> use cases where we cannot use hybrid encryption, so at this case, the >> messages are loaded directly. >> (3) gcrypt as the model of many cryptographic libraries is treated (at >> least people do) as a standard. It is part of the source of the >> massive problem in implementing ElGamal. >> >> Let me add some words on the semantic security. >> >> >> [Quick Recap of ElGamal] Assume the ElGamal private key is $x$, and >> the public key is $g^x$ where $g$ is a generator of $Z_p^*$. >> >> The encryption of message $m$ where $k$ is selected randomly: >> - First part of the ciphertext: m g^{xk} >> - Second part of the ciphertext: g^k >> >> >> [Semantic Security] This is the general security requirement for all >> symmetric and asymmetric ciphers. The scheme can ensure that a >> computer run under a polynomial function of the security parameter >> cannot learn anything information from the ciphertexts except the >> length with a non-negligible possibility in respect to the security >> parameter. >> >> Or, tweaking a sufficiently large security parameter (like 2048 bit >> for RSA today), nobody except supermen can learn anything except the >> length. >> >> The non-textbook version of RSA (with random padding) achieves >> semantic security. The symmetric ciphers under some encryption modes >> >> >> [Test Example] Assume we have $m_0$ and $m_1$. They are different. >> >> >> [Are They Quadratic Residues?] Half of the all possible $m$ accepted >> by ElGamal are Quadratic Residues, and those remaining are not >> Quadratic Residues. (So it leaks information worth of 1 bit). A number >> $m$ is QR. Then there is a value $x$ so that $m=x^2 mod p$. If a >> number $m$ is not QR, then such $x$ does not exist. >> >> >> [Possibility that $m_0$ and $m_1$ different in QR] The possibility >> that $m_0$ and $m_1$ are, not both QR and not both non-QR, are 1/2. In >> this case, we can distinguish $m_0$ and $m_1$ by whether or not QR. >> >> >> [What happens after encryption?] Let us play a game: assume I know >> whether or not your private key $x$ is odd or even (this is a >> reasonable assumption because the same asymmetric key is used >> repeatedly). Without loss of generality, I assume $x$ is odd, and >> $g^x$ is non-QR. >> >> You encrypt a message $m$. The ciphertexts are $c=(m g^{xk}, g^k)$. >> >> If $g^k$ is QR, then $g^{xk}$ is also a QR. If $g^k$ is non-QR, then >> $g^{xk}$ is also a non-QR. >> >> If $m g^{xk}$ is a QR, $g^k$ is QR => $m$ is a QR >> If $m g^{xk}$ is a non-QR, $g^k$ is QR => $m$ is a non-QR >> If $m g^{xk}$ is a QR, $g^k$ is non-QR => $m$ is a non-QR >> If $m g^{xk}$ is a non-QR, $g^k$ is non-QR => $m$ is a QR >> >> You see. I can distinguish whether $m$ is QR or not even if it is >> encrypted -- the ciphertext leaks one-bit information about the >> underlying message. >> >> Another case. Let us assume $x$ is even and $g^x$ is QR. You encrypt a >> message $m$. The ciphertexts are $c=(m g^{xk}, g^k)$. >> >> Then if $m g^{xk}$ is QR, $m$ is QR. >> If $m g^{xk}$ is non-QR, $m$ is non-QR. >> >> It is even easier to guess this one-bit information of the plaintext >> from the ciphertext. >> >> >> [Summary] The implementation that uses $g$ as the generator of $Z_p^*$ >> and uses no specific encoding of $m$, the ciphertext leaks one bit >> about the underlying plaintext. >> >> >> ================ First part ended. Next email will continue. >> >> On Mon, Oct 16, 2017 at 7:03 PM, NIIBE Yutaka wrote: >>> Hello, >>> >>> Weikeng Chen wrote: >>>> I am going to continue my post last month on the ElGamal in gcrypt. I >>>> am sorry to say gcrypt is the beginning of many wrong implementations >>>> of ElGamal. Some Github repo owners use this to show their >>>> implementation is correct. It uses a safe prime but the generator is >>>> still wrong. This makes the ElGamal not semantic secure. >>> >>> Historically speaking, libgcrypt was factored out from GnuPG. So, its >>> ElGamal API and the implementation are primarily intended to be used by >>> GnuPG. In this context, it is perfectly OK. I mean, "semantic >>> security" of the crypto system doesn't matter to the security of the >>> application. >>> >>>> Niibe has mentioned that ElGamal used for hybrid encryption in general >>>> (which would be secure), but we two agree that we should improve. >>> >>> I agreed that it make sense to improve the generator. I don't think it >>> is mandatory. I didn't mean introducing new or drastic change which may >>> impact existing usages. >>> >>>> Some programmers may use ElGamal for homomorphic encryption and >>>> computation over encrypted data. >>> >>> Interesting. In that case, I wonder if current API of libgcrypt is >>> enough or good. (I guess that... I don't think it's enough.) >>> >>>> (1) Showing the current ElGamal implementation is not secure would be >>>> easy, as Wikipedia and some 17 years ago papers have some information. >>>> If we consult expert cryptographers in the field. They can clearly say >>>> the current implementation is insecure. --------- Do you think an >>>> experiment or proof-of-concept will be necessary? >>> >>> If possible, please use careful wording. >>> >>> The API of crypto library which implements crypto system lacking >>> "semantic security" property does not automatically mean "insecure". >>> For a library, its usage by an application matters. >>> >>>> (2) Providing a corrected version is not trivial -- it is not just >>>> making the generator correct. We also need to embed the message (a >>>> binary string) into an element in a specific subgroup (and recovered >>>> later). There are many papers, and many years ago, to say some ideas >>>> about this encoding. One of that is my proposed solution. >>> >>> You are talking about new crypto protocol, using ElGamal crypto system, >>> don't you? >>> >>>> However, there is no official example. Even the original paper by El >>>> Gamal is not secure under this concern. Besides gcrypt, ---------- how >>>> to find a gold standard for ElGamal implementations? OpenSSL >>>> implements DH (also wrong but not a big deal in the real world, >>>> because it is for DH key exchange not ElGamal) ------ and one thing >>>> for sure, how to make it easy to follow in order to persuade a >>>> sufficiently large community to accept this change? >>> >>> It seems for me that you have some confusions among: >>> >>> (1) ElGamal crypto system >>> (2) crypto protocol which uses ElGamal crypto system >>> --- e.g. OpenPGP >>> (3) an implementation, in this case, partial implementation of (1) >>> --- e.g. libcrypt >>> (4) an application of (3) which implements (2) >>> --- e.g. GnuPG >>> >>> I would admit that libgcrypt API is not enough to provide full features >>> of ElGamal crypto system, for example, as you pointed out, it doesn't >>> provide "semantically secure" use case. In other words, I could say, >>> libgcrypt's API for ElGamal just offers things needed for OpenPGP >>> protocol. >>> >>> Actually, I think that "ElGamal crypto system" can refer different >>> crypto systems. I think that your interpretation would be too modern, >>> and I'm afraid we can't find any existing (free software) implementation >>> which offers full features you'd like. >>> >>>> (3) The solution will be incompatible with existing applications >>>> running ElGamal in gcrypt -- their ciphertexts will be undecryptable. >>>> ----- What is your opinion to deal with this? >>> >>> If you are introducing new crypto protocol, old and new protocol can >>> co-exist, if designed carefully. >>> >>> >>>> My doubt on ElGamal encryption is a result of my cryptographic class >>>> CS276 at Berkeley. This page contains some reading >>>> (http://people.eecs.berkeley.edu/~alexch/classes/CS276-F2015.html). >>>> LEC NOTE 14 and PROB SET 4 have further information. >>> >>> I think that you can ask your teacher. That would be better. >>> -- >> >> >> >> -- >> >> Weikeng Chen @ 795 Soda Hall > > > > -- > > Weikeng Chen @ 795 Soda Hall -- Weikeng Chen @ 795 Soda Hall From qianyue.zj at alibaba-inc.com Tue Oct 17 04:24:22 2017 From: qianyue.zj at alibaba-inc.com (Jia Zhang) Date: Tue, 17 Oct 2017 10:24:22 +0800 Subject: [PATCH] sm3: implement SM3 hash algorithm In-Reply-To: <878tgah9ga.fsf@iwagami.gniibe.org> References: <59E243F4.3030308@alibaba-inc.com> <878tgah9ga.fsf@iwagami.gniibe.org> Message-ID: <59E569D6.8010703@alibaba-inc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 ? 2017/10/17 ??9:03, NIIBE Yutaka ??: > "??(??)" wrote: >> Hi Werner, > > Sorry, I'm not Werner, but another (old ???) developer of > libgcrypt. Thanks for your great comments! > >> This is the review request for SM3 hash algorithm. Plz see the >> commit header and patch for more details. > > To track this, I created a ticket at: https://dev.gnupg.org/T3454 > > > Could you please send the patch to gcrypt-devel? Or, you can > upload your patch to: > > https://dev.gnupg.org/differential/ I just created it. See https://dev.gnupg.org/D449. > >> SM3 hash algorithm is already accepted and supported by TPM 2.0 >> spec. So it is necessary to implement this algorithm in a famous >> open source software for checking the digest value computed by >> TPM. > > Out of curiosity, is it mandated by the goverment? If so, how > about SM2? > > When I read FIDO U2F document in this April, I learned about > optional SM2 and SM3. To be honest, I'm not quite sure it. But at least we are seeing it is also for civil use. I don't want to see the thing gets complicated, cause my original intention is quite simple. I see my TPM supports SM3 but there is no sm3sum program in coreutils to verify the hash value. Just contribute SM3 hash function to the famous open source community and make it easy to use. I'm not familiar with SM2, but I confirm I will submit it if SM3 is approved. > >> Plz refer to this PR (https://github.com/gpg/libgcrypt/pull/2) >> for code review. > > We don't have a practice to use GitHub, which might require > non-free JavaScript. > > Please read libgcrypt/doc/HACKING, the "How to contribute" > section, especially the "License policy" subsection. I'm doing this. Copyright assignment is fine to me. Jia > -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEoCC9pk5gdr326JdrPMRi5TbAeCkFAlnladYACgkQPMRi5TbA eCmnnQ//fmPvCtzNOSaUSX3i87rvWz9fbk6OhvFNz4xKKryHbe2wsEXAiuhTtFxo KQrRgrKBC1cKq5VN6MgCE59i5jYn2sCBOST/KeQr8esVwR1QyZBs8hlVi0lGn9Gr mC8C/GSKcqLVNuoHjfYk6iFkEx3Zh7oA5xEfC1Yq1bbAmnlIbkEQWaUJA85ZeADJ 4BFsb1bUvZzc0YhBKtmV0FdxN5pOpzZaww81mXhNdxaTH8yAc1nJ6rpo4VQgFs5d 0xkmB5qeFRtToA7HKK8zUsyT1FlOJ3KYnL3bHoGIN5rJafKUcS17HziHS2onb42c RUgzdbvtRThBC/yE6sc95qGXrmM4dRJn5AdNFpXCUmHTK29V7gmp5t3DjJgtoSV+ Es/nPps2WTI+2Zp+i5chwPGGrljq73LcuCPE9sijEVfqmTV1rgsFmqy13Qk0vdQX MrkRGvG6M6dRAi4MJx6HFIgtcONlgByaFBvdamfpRHso4rdFzKA4Cy/S6+fHEngl uitJmxnqHQYCXG0dDzUJfvrCtkaxKPWDgd+KmdDN9lVtMlEkeVVA6Zbay2tjB6f8 FjHataRSyj+zy+cp9vLAz8jIzI+EN6/yvDr6JOz/w2fCI1pLwQSAtsepoLuawAMz ogHPXvC0jnh8483eHIjcSva0aRAKAH/b9P1FVChd4Sx/hQ3VzpA= =xk8n -----END PGP SIGNATURE----- From qianyue.zj at alibaba-inc.com Tue Oct 17 04:42:56 2017 From: qianyue.zj at alibaba-inc.com (Jia Zhang) Date: Tue, 17 Oct 2017 10:42:56 +0800 Subject: Sign DCO from Jia Zhang Message-ID: <59E56E30.9060503@alibaba-inc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Libgcrypt Developer's Certificate of Origin. Version 1.0 ========================================================= By making a contribution to the Libgcrypt project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the free software license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate free software license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same free software license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the free software license(s) involved. Signed-off-by: Jia Zhang -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEoCC9pk5gdr326JdrPMRi5TbAeCkFAlnlbi8ACgkQPMRi5TbA eClMHBAAtG9b2ME5+3JmOq2x311616f8/et9PXSvNW8+8tDcIhc1a0HfDCDRGCnW cMW1GBDwpWEvqUOUIrcc32EzKdRRDqNFniQX4ZReuuS0dLvlw6UWb6nocMfxKGc+ mjmfQvVyAjam5rflIx4MJH/FK+94D25yUvH0EilrXDz2q8Ucz/7eeck/5dssSew6 2YPrc1TSSRrVM+BNYiRN4kFgCDEWX/Y0oJ+SMfTl9MaGEuKwPyHM3FIj6isBBstx 5WGghWLL3284Wek8QU6Jibd2V8ZYzqYmadG+QLtZL3wMrybA8V3xvC+IwH1V/G8a GXVU8f04EWEdglrmfANIcQfFBL2S3zRwvRd1bLX6z0mHOOrezKyYxlhLS9RXoxmv 0ZBBCYB2ar2uZOy7EOIZ4/1s/GtsJG9QaFXHEnPTDSVYIVa5guauZ+4fq9omyp5Z 2z1TZuHqGRS8EEpzIbPW9BMIB5Z4ramgy6oaM27NMDU8CAX6w5QFdD2KhShyR/nL 6UD0PQ9vlla1TfigM13blW6vVniqw6eQMcwVKwjf2ZAqCyH4besuIdKT9sh6Il8J 3J7yvSviVCWXYmY1aR4vMMxpE/EnsvDT2V8TDz4AbJWS4TbAcuWrJd86OJeY/djG fBGmZVPUIq5cet6kDPweyFZkPQYuDszp+t2EKk2tEvVXW0/7JNg= =nR1Q -----END PGP SIGNATURE----- From cvs at cvs.gnupg.org Tue Oct 17 15:08:53 2017 From: cvs at cvs.gnupg.org (by Werner Koch) Date: Tue, 17 Oct 2017 15:08:53 +0200 Subject: [git] GCRYPT - branch, master, updated. libgcrypt-1.8.1-15-gc6e42e7 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 c6e42e7ec3d1046969d783c443c13aad7cb61bb8 (commit) from e4dc458b0b7dc9b8417a2177ef17822d9b9064ec (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 c6e42e7ec3d1046969d783c443c13aad7cb61bb8 Author: Werner Koch Date: Tue Oct 17 15:00:08 2017 +0200 api: New function gcry_mpi_get_ui. * src/gcrypt.h.in (gcry_mpi_get_ui): New. (mpi_get_ui): New macro. * src/libgcrypt.def, src/libgcrypt.vers: Add new function. * src/visibility.c (gcry_mpi_get_ui): New. * src/visibility.h: Mark that function. (gcry_mpi_get_ui): New. * mpi/mpiutil.c (MY_UINT_MAX): New macro. (_gcry_mpi_get_ui): Re-implemented. This function existed but was never imported or used. * tests/mpitests.c (test_maxsize): Add some test for this function. -- Note that in libgcrypt.def the cardinal 91 is used which was never used in the past. Signed-off-by: Werner Koch diff --git a/NEWS b/NEWS index 3e07a94..3b49350 100644 --- a/NEWS +++ b/NEWS @@ -2,6 +2,11 @@ Noteworthy changes in version 1.9.0 (unreleased) [C22/A3/R0] ------------------------------------------------ + * Interface changes relative to the 1.8.0 release: + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + gcry_mpi_get_ui NEW function. + + Noteworthy changes in version 1.8.1 (2017-08-27) [C22/A2/R1] ------------------------------------------------ diff --git a/doc/gcrypt.texi b/doc/gcrypt.texi index 2bf23a5..a684134 100644 --- a/doc/gcrypt.texi +++ b/doc/gcrypt.texi @@ -4578,6 +4578,18 @@ int} as type for @var{u} and thus it is only possible to set @var{w} to small values (usually up to the word size of the CPU). @end deftypefun + at deftypefun gcry_error_t gcry_mpi_get_ui (@w{unsigned int *@var{w}}, @w{gcry_mpi_t @var{u}}) + +If @var{u} is not negative and small enough to be stored in an + at code{unsigned int} variable, store its value at @var{w}. If the +value does not fit or is negative return GPG_ERR_ERANGE and do not +change the value stored at @var{w}. Note that this function returns +an @code{unsigned int} so that this value can immediately be used with +the bit test functions. This is in contrast to the other "_ui" +functions which allow for values up to an @code{unsigned long}. + at end deftypefun + + @deftypefun void gcry_mpi_swap (@w{gcry_mpi_t @var{a}}, @w{gcry_mpi_t @var{b}}) Swap the values of @var{a} and @var{b}. @@ -5122,7 +5134,7 @@ currently defined flags are: Setting this flag converts @var{a} into an MPI stored in "secure memory". Clearing this flag is not allowed. @item GCRYMPI_FLAG_OPAQUE -This is an interanl flag, indicating the an opaque valuue and not an +This is an internal flag, indicating the an opaque valuue and not an integer is stored. This is an read-only flag; it may not be set or cleared. @item GCRYMPI_FLAG_IMMUTABLE diff --git a/mpi/mpiutil.c b/mpi/mpiutil.c index 3ae84c3..9dde37f 100644 --- a/mpi/mpiutil.c +++ b/mpi/mpiutil.c @@ -28,6 +28,21 @@ #include "mpi-internal.h" #include "mod-source-info.h" + +#if SIZEOF_UNSIGNED_INT == 2 +# define MY_UINT_MAX 0xffff +/* (visual check: 0123 ) */ +#elif SIZEOF_UNSIGNED_INT == 4 +# define MY_UINT_MAX 0xffffffff +/* (visual check: 01234567 ) */ +#elif SIZEOF_UNSIGNED_INT == 8 +# define MY_UINT_MAX 0xffffffffffffffff +/* (visual check: 0123456789abcdef ) */ +#else +# error Need MY_UINT_MAX for this limb size +#endif + + /* Constants allocated right away at startup. */ static gcry_mpi_t constants[MPI_NUMBER_OF_CONSTANTS]; @@ -539,23 +554,27 @@ _gcry_mpi_set_ui (gcry_mpi_t w, unsigned long u) return w; } +/* If U is non-negative and small enough store it as an unsigned int + * at W. If the value does not fit into an unsigned int or is + * negative return GPG_ERR_ERANGE. Note that we return an unsigned + * int so that the value can be used with the bit test functions; in + * contrast the other _ui functions take an unsigned long so that on + * some platforms they may accept a larger value. On error the value + * at U is not changed. */ gcry_err_code_t -_gcry_mpi_get_ui (gcry_mpi_t w, unsigned long *u) +_gcry_mpi_get_ui (unsigned int *w, gcry_mpi_t u) { - gcry_err_code_t err = GPG_ERR_NO_ERROR; - unsigned long x = 0; + mpi_limb_t x; - if (w->nlimbs > 1) - err = GPG_ERR_TOO_LARGE; - else if (w->nlimbs == 1) - x = w->d[0]; - else - x = 0; + if (u->nlimbs > 1 || u->sign) + return GPG_ERR_ERANGE; - if (! err) - *u = x; + x = (u->nlimbs == 1) ? u->d[0] : 0; + if (sizeof (x) > sizeof (unsigned int) && x > MY_UINT_MAX) + return GPG_ERR_ERANGE; - return err; + *w = x; + return 0; } diff --git a/src/gcrypt-int.h b/src/gcrypt-int.h index ad719be..e88f868 100644 --- a/src/gcrypt-int.h +++ b/src/gcrypt-int.h @@ -362,7 +362,7 @@ gcry_mpi_t _gcry_mpi_copy (const gcry_mpi_t a); void _gcry_mpi_snatch (gcry_mpi_t w, gcry_mpi_t u); gcry_mpi_t _gcry_mpi_set (gcry_mpi_t w, const gcry_mpi_t u); gcry_mpi_t _gcry_mpi_set_ui (gcry_mpi_t w, unsigned long u); -gcry_err_code_t _gcry_mpi_get_ui (gcry_mpi_t w, ulong *u); +gcry_err_code_t _gcry_mpi_get_ui (unsigned int *w, gcry_mpi_t u); void _gcry_mpi_swap (gcry_mpi_t a, gcry_mpi_t b); int _gcry_mpi_is_neg (gcry_mpi_t a); void _gcry_mpi_neg (gcry_mpi_t w, gcry_mpi_t u); @@ -464,7 +464,7 @@ int _gcry_mpi_get_flag (gcry_mpi_t a, enum gcry_mpi_flag flag); #define mpi_snatch( w, u) _gcry_mpi_snatch( (w), (u) ) #define mpi_set( w, u) _gcry_mpi_set( (w), (u) ) #define mpi_set_ui( w, u) _gcry_mpi_set_ui( (w), (u) ) -#define mpi_get_ui(a,b) _gcry_mpi_get_ui( (a), (b) ) +#define mpi_get_ui(w,u) _gcry_mpi_get_ui( (w), (u) ) #define mpi_swap(a,b) _gcry_mpi_swap ((a),(b)) #define mpi_abs( w ) _gcry_mpi_abs( (w) ) #define mpi_neg( w, u) _gcry_mpi_neg( (w), (u) ) diff --git a/src/gcrypt.h.in b/src/gcrypt.h.in index 89b1303..76d9b1d 100644 --- a/src/gcrypt.h.in +++ b/src/gcrypt.h.in @@ -587,6 +587,9 @@ gcry_mpi_t gcry_mpi_set (gcry_mpi_t w, const gcry_mpi_t u); /* Store the unsigned integer value U in W. */ gcry_mpi_t gcry_mpi_set_ui (gcry_mpi_t w, unsigned long u); +/* Store U as an unsigned int at W or return GPG_ERR_ERANGE. */ +gpg_error_t gcry_mpi_get_ui (unsigned int *w, gcry_mpi_t u); + /* Swap the values of A and B. */ void gcry_mpi_swap (gcry_mpi_t a, gcry_mpi_t b); @@ -840,6 +843,7 @@ gcry_mpi_t _gcry_mpi_get_const (int no); #define mpi_snatch( w, u) gcry_mpi_snatch( (w), (u) ) #define mpi_set( w, u) gcry_mpi_set( (w), (u) ) #define mpi_set_ui( w, u) gcry_mpi_set_ui( (w), (u) ) +#define mpi_get_ui( w, u) gcry_mpi_get_ui( (w), (u) ) #define mpi_abs( w ) gcry_mpi_abs( (w) ) #define mpi_neg( w, u) gcry_mpi_neg( (w), (u) ) #define mpi_cmp( u, v ) gcry_mpi_cmp( (u), (v) ) diff --git a/src/libgcrypt.def b/src/libgcrypt.def index a76b377..6239a95 100644 --- a/src/libgcrypt.def +++ b/src/libgcrypt.def @@ -118,7 +118,7 @@ EXPORTS gcry_mpi_set_flag @88 gcry_mpi_clear_flag @89 gcry_mpi_get_flag @90 - + gcry_mpi_get_ui @91 gcry_cipher_open @92 gcry_cipher_close @93 diff --git a/src/libgcrypt.vers b/src/libgcrypt.vers index 1aa830f..edf8a76 100644 --- a/src/libgcrypt.vers +++ b/src/libgcrypt.vers @@ -108,6 +108,7 @@ GCRYPT_1.6 { gcry_mpi_ec_dup; gcry_mpi_ec_add; gcry_mpi_ec_sub; gcry_mpi_ec_mul; gcry_mpi_ec_curve_point; gcry_mpi_ec_decode_point; gcry_mpi_point_copy; + gcry_mpi_get_ui; gcry_log_debug; gcry_log_debughex; gcry_log_debugmpi; gcry_log_debugpnt; gcry_log_debugsxp; diff --git a/src/visibility.c b/src/visibility.c index 104c70d..44972a1 100644 --- a/src/visibility.c +++ b/src/visibility.c @@ -308,7 +308,7 @@ gcry_mpi_set_ui (gcry_mpi_t w, unsigned long u) } gcry_error_t -gcry_mpi_get_ui (gcry_mpi_t w, unsigned long *u) +gcry_mpi_get_ui (unsigned int *w, gcry_mpi_t u) { return gpg_error (_gcry_mpi_get_ui (w, u)); } diff --git a/src/visibility.h b/src/visibility.h index df2caf6..9c9fa87 100644 --- a/src/visibility.h +++ b/src/visibility.h @@ -265,6 +265,7 @@ MARK_VISIBLEX (gcry_mpi_set_highbit) MARK_VISIBLEX (gcry_mpi_set_opaque) MARK_VISIBLEX (gcry_mpi_set_opaque_copy) MARK_VISIBLEX (gcry_mpi_set_ui) +MARK_VISIBLEX (gcry_mpi_get_ui) MARK_VISIBLEX (gcry_mpi_snew) MARK_VISIBLEX (gcry_mpi_sub) MARK_VISIBLEX (gcry_mpi_sub_ui) @@ -484,6 +485,7 @@ MARK_VISIBLEX (_gcry_mpi_get_const) #define gcry_mpi_set_highbit _gcry_USE_THE_UNDERSCORED_FUNCTION #define gcry_mpi_set_opaque _gcry_USE_THE_UNDERSCORED_FUNCTION #define gcry_mpi_set_ui _gcry_USE_THE_UNDERSCORED_FUNCTION +#define gcry_mpi_get_ui _gcry_USE_THE_UNDERSCORED_FUNCTION #define gcry_mpi_snatch _gcry_USE_THE_UNDERSCORED_FUNCTION #define gcry_mpi_snew _gcry_USE_THE_UNDERSCORED_FUNCTION #define gcry_mpi_sub _gcry_USE_THE_UNDERSCORED_FUNCTION diff --git a/tests/mpitests.c b/tests/mpitests.c index 18156d1..9b4a66c 100644 --- a/tests/mpitests.c +++ b/tests/mpitests.c @@ -205,6 +205,7 @@ test_maxsize (void) { gpg_error_t err; gcry_mpi_t a; + unsigned int val; char buffer[2+2048]; /* For PGP: 2 length bytes and 16384 bits. */ memset (buffer, 0x55, sizeof buffer); @@ -232,7 +233,36 @@ test_maxsize (void) 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)); + + /* Let's also test get_ui. */ + gcry_mpi_set_ui (a, 0); + val = 4711; + err = gcry_mpi_get_ui (&val, a); + if (err || val != 0) + die ("gcry_mpi_get_ui failed at %d: %s\n", __LINE__, gpg_strerror (err)); + + gcry_mpi_sub_ui (a, a, 1); + val = 4711; + err = gcry_mpi_get_ui (&val, a); + if (gpg_err_code (err) != GPG_ERR_ERANGE || val != 4711) + die ("gcry_mpi_get_ui failed at %d: %s\n", __LINE__, gpg_strerror (err)); + + gcry_mpi_set_ui (a, 0xffffffff); + val = 4711; + err = gcry_mpi_get_ui (&val, a); + if (err || val != 0xffffffff) + die ("gcry_mpi_get_ui failed at %d: %s\n", __LINE__, gpg_strerror (err)); + + if (sizeof (val) == 4) + { + gcry_mpi_add_ui (a, a, 1); + err = gcry_mpi_get_ui (&val, a); + if (gpg_err_code (err) != GPG_ERR_ERANGE) + die ("gcry_mpi_get_ui failed at %d: %s\n", __LINE__,gpg_strerror (err)); + } + gcry_mpi_release (a); + } ----------------------------------------------------------------------- Summary of changes: NEWS | 5 +++++ doc/gcrypt.texi | 14 +++++++++++++- mpi/mpiutil.c | 43 +++++++++++++++++++++++++++++++------------ src/gcrypt-int.h | 4 ++-- src/gcrypt.h.in | 4 ++++ src/libgcrypt.def | 2 +- src/libgcrypt.vers | 1 + src/visibility.c | 2 +- src/visibility.h | 2 ++ tests/mpitests.c | 30 ++++++++++++++++++++++++++++++ 10 files changed, 90 insertions(+), 17 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 r030t1 at gmail.com Tue Oct 17 20:48:20 2017 From: r030t1 at gmail.com (R0b0t1) Date: Tue, 17 Oct 2017 13:48:20 -0500 Subject: [PATCH] sm3: implement SM3 hash algorithm In-Reply-To: <59E40666.7090104@alibaba-inc.com> References: <59E243F4.3030308@alibaba-inc.com> <59E40666.7090104@alibaba-inc.com> Message-ID: On Sunday, October 15, 2017, Jia Zhang wrote: > Everyone has different expection with gcript, and personally I respect the established fact: > > - TCG approved > - Not broke > - Known weak algorithms still exist in gcrypt > > gcrypt is not arrogant. It helps to extend the use of cryptography usage. > > I think it is time to end up talking about all non-engineering discussion. Until now there is no people talking about the code itself. > If the algorithm is so weak or suspicious as to preclude inclusion in gcrypt then there is no point in discussing the details of your patch. However, to my dismay, the priorities of gcrypt lie elsewhere and it seems as is your patch will be accepted. Most of the weak algorithms are included for historical reasons. This one need not be included. Besides SM3's technical deficiencies, it should be obvious it fails a test of notability. Outside of the Chinese speaking internet no one seems to care about it, save for situations like the one happening now where people are trying to argue to others who have no reason to care that SM3 is notable. This is not xenophobia. The algorithm is suspicious and looks like it is backdoored. Respectfully, R0b0t1 > > ? 2017/10/16 ??8:01, Weikeng Chen ??: >> >> [1] Understood your concern that SM3 does not release the reason for >> picking constants. This is somehow not solvable. >> >> I think this is a sufficient reason not to include it in the gpupg. >> Because including it would be regarded as an endorsement from open >> source community. If one day something is wrong, it would be >> problematic. >> >> >> [2] off-topic issues. Please believe that people in China visiting >> Google, Facebook, and Youtube are already experts in censorship >> circumvention (but it is not that easy) -- we are not that stupid >> after all and not that controlled by the government. >> >> I think you misunderstand the usage of SM1-4. It is only used for >> government-relevant or critical circles (that would be another reason >> that it is not needed to include today). It is impossible to be used >> to alternate the HTTPS or anything in today's Internet. So, the >> government using SM1-4 everywhere does not make it an advantage in >> breaking our RSA/ECDSA/SHA2/SHA3 based Internet communication that the >> major public is using (I think we should partly attribute this to the >> development of gpupg). >> >> The political concern now goes a little bit far. >> >> >> [3] Independent of this, I think it is crucial that we have a general >> rule to discuss to accept or not accept a cipher into gcrypt. Although >> it is unlikely that in recent years, new standards to replace AES and >> SHA3 are needed. >> >> "Just because you personally can not imagine some weakness in SM3 does >> not mean there are no weaknesses in SM3." >> >> This is not a gold standard that we can use in the future. >> Cryptography is based on problems that we believe hard today. If P=NP, >> then theoretically, we have rightly zero cryptographic primitives that >> can be long-term secure. Many reasons to dispute SM3 can also be used >> to criticize SHA3, SHA2. No need to say MD2, MD4. There are a bunch of >> papers on the reduced-round attack in many mainstream ciphers in >> CRYPTO. But "attack-paper-less" cryptographic algorithms are also not >> good because of few discussions. >> >> >> [4] Unlike asymmetric encryption, the evaluation of symmetric >> encryption is really hard. >> >> >> Weikeng >> >> On Sun, Oct 15, 2017 at 4:21 PM, R0b0t1 wrote: >>> >>> On Sun, Oct 15, 2017 at 3:47 AM, Weikeng Chen wrote: >>>> >>>> I think it is unlikely that SM3 contains a backdoor. >>>> >>> >>> This is giving the authors of SM3 a dangerous amount of credit where >>> it is not due. Their algorithm fails a very basic test: >>> https://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number. >>> >>> At best, they don't know what they are doing and made changes >>> randomly. At worst, they made changes to make the algorithm >>> susceptible to an undisclosed attack and could find no justification >>> to use as a lie. >>> >>> Just because you personally can not imagine some weakness in SM3 does >>> not mean there are no weaknesses in SM3. >>> >>>> It is intended to be used in governments and mission-critical devices. >>>> There is no reason to use something dangerous (then U.S. can break?). >>>> And it is generally not that easy to add a backdoor in a symmetric >>>> algorithm if we obtain randomness from a physical source. >>>> >>> >>> The problem with proving a negative in this context; that is, proving >>> there are no back doors to the algorithm, is that it takes a huge >>> amount of work. The "Limitations" section of the Wikipedia article >>> above explains it well: the problem space is so large that any number >>> of design constraints could have been engineered to provide a weakness >>> that is only accessible to a party with special knowledge. In this >>> sense a weakness can be made "safe" and turned into a back door. >>> >>> This is one of the major reasons that lack of cryptanalysis for an >>> algorithm is suspicious: other researchers could consider it a waste >>> of time to investigate a plausibly backdoored algorithm. >>> >>> Even if, however, other nation states were already aware of and could >>> exploit the weakness, I expect that China would use a weak algorithm. >>> China may not have the capabilities that other actors do, and may need >>> to rely on algorithms that would be considered weak to other actors if >>> China wants to monitor communication within its borders. >>> >>> As a good example, look at Russian certificate authorities and content >>> hosts. Many of them use very weak cryptographic keys. I have seen many >>> 512 bit RSA keys that are nowhere close to expiring. Seeing as the >>> Russian intelligence services are apparently not capable of factoring >>> extremely large primes, they "recommend" weak keys to their citizens >>> (or for some other reason many businesses use weak keys). The intent >>> behind this is to protect communication from civilian espionage but >>> not from their own state or other states. >>> >>> Respectfully, >>> R0b0t1 >>> >>> >>>> >>>> gcrypt cannot have all new functions -- otherwise, why not balloon >>>> hashing and scrypt (the latter is used in many kinds of >>>> cryptocurrency)? >>>> >>>> >>>> >>>> On Sat, Oct 14, 2017 at 1:16 PM, R0b0t1 wrote: >>>>> >>>>> On Sat, Oct 14, 2017 at 12:05 PM, ??(??) wrote: >>>>>> >>>>>> Hi Werner, >>>>>> >>>>>> This is the review request for SM3 hash algorithm. Plz see the commit >>>>>> header and patch for more details. >>>>>> >>>>>> SM3 hash algorithm is already accepted and supported by TPM 2.0 spec. >>>>>> So it is necessary to implement this algorithm in a famous open source >>>>>> software for checking the digest value computed by TPM. >>>>>> >>>>>> Plz refer to this PR (https://github.com/gpg/libgcrypt/pull/2) for code >>>>>> review. >>>>>> >>>>>> Thanks, >>>>>> Jia >>>>>> >>>>> >>>>> Jia, >>>>> >>>>> It is my understanding that SM3 was not accepted into any global TPM >>>>> specification and is merely mandated for use within China. >>>>> >>>>> My research on SM3 has turned up only one detailed cryptanalysis of >>>>> the function.[1] That cryptanalysis implies that the techniques used >>>>> to "strengthen" SM3 do not accomplish what the creators claim, and may >>>>> even weaken the hash function when compared to its inspiration, SHA-2. >>>>> >>>>> Less detailed analysis[3] of the claims presented by the creators >>>>> reflect poorly on their work. For starters, none of the techniques >>>>> meant to increase the security of SM3 are explained. Their utility is >>>>> unknown, and a cursory glance shows that in at least one case a round >>>>> operation is simplified. Perhaps more distressing is the selection of >>>>> constants with no justification. >>>>> >>>>> It seems very likely that the algorithm has undisclosed backdoors. >>>>> >>>>> Also pertinent is the existence of GmSSL,[3] a fork of OpenSSL which >>>>> contains various cryptographic standards developed by the Chinese >>>>> government that were, presumably, not deemed fit for inclusion in >>>>> OpenSSL. >>>>> >>>>> Inclusion of weak cryptography in gcrypt would be a disservice to >>>>> those users which trust gcrypt with their life. I understand I am not >>>>> the person to whom you addressed your message, nor am I a gcrypt >>>>> developer, but I felt it necessary to reply to this conversation. >>>>> >>>>> Respectfully, >>>>> R0b0t1 >>>>> >>>>> >>>>> [1]: https://eprint.iacr.org/2012/274.pdf, also attached. >>>>> [2]: https://tinycrypt.wordpress.com/2017/02/22/asmcodes-sm3/ >>>>> [3]: http://gmssl.org/ >>>>> >>>>> _______________________________________________ >>>>> Gcrypt-devel mailing list >>>>> Gcrypt-devel at gnupg.org >>>>> http://lists.gnupg.org/mailman/listinfo/gcrypt-devel >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Weikeng Chen @ 795 Soda Hall >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From w.k at berkeley.edu Tue Oct 17 21:11:56 2017 From: w.k at berkeley.edu (Weikeng Chen) Date: Tue, 17 Oct 2017 12:11:56 -0700 Subject: [PATCH] sm3: implement SM3 hash algorithm In-Reply-To: References: <59E243F4.3030308@alibaba-inc.com> <59E40666.7090104@alibaba-inc.com> Message-ID: R0b0t1, I have sent an email to ask the authors of SM3 about the selection of parameters. If there is an update, will post here. But after all, putting a code of an algorithm, if you don't call it, it cannot do harm. Weikeng On Tue, Oct 17, 2017 at 11:48 AM, R0b0t1 wrote: > On Sunday, October 15, 2017, Jia Zhang wrote: >> Everyone has different expection with gcript, and personally I respect the >> established fact: >> >> - TCG approved >> - Not broke >> - Known weak algorithms still exist in gcrypt >> >> gcrypt is not arrogant. It helps to extend the use of cryptography usage. >> >> I think it is time to end up talking about all non-engineering discussion. >> Until now there is no people talking about the code itself. >> > > If the algorithm is so weak or suspicious as to preclude inclusion in gcrypt > then there is no point in discussing the details of your patch. > > However, to my dismay, the priorities of gcrypt lie elsewhere and it seems > as is your patch will be accepted. > > Most of the weak algorithms are included for historical reasons. This one > need not be included. > > Besides SM3's technical deficiencies, it should be obvious it fails a test > of notability. Outside of the Chinese speaking internet no one seems to care > about it, save for situations like the one happening now where people are > trying to argue to others who have no reason to care that SM3 is notable. > > This is not xenophobia. The algorithm is suspicious and looks like it is > backdoored. > > Respectfully, > R0b0t1 > > >> >> ? 2017/10/16 ??8:01, Weikeng Chen ??: >>> >>> [1] Understood your concern that SM3 does not release the reason for >>> picking constants. This is somehow not solvable. >>> >>> I think this is a sufficient reason not to include it in the gpupg. >>> Because including it would be regarded as an endorsement from open >>> source community. If one day something is wrong, it would be >>> problematic. >>> >>> >>> [2] off-topic issues. Please believe that people in China visiting >>> Google, Facebook, and Youtube are already experts in censorship >>> circumvention (but it is not that easy) -- we are not that stupid >>> after all and not that controlled by the government. >>> >>> I think you misunderstand the usage of SM1-4. It is only used for >>> government-relevant or critical circles (that would be another reason >>> that it is not needed to include today). It is impossible to be used >>> to alternate the HTTPS or anything in today's Internet. So, the >>> government using SM1-4 everywhere does not make it an advantage in >>> breaking our RSA/ECDSA/SHA2/SHA3 based Internet communication that the >>> major public is using (I think we should partly attribute this to the >>> development of gpupg). >>> >>> The political concern now goes a little bit far. >>> >>> >>> [3] Independent of this, I think it is crucial that we have a general >>> rule to discuss to accept or not accept a cipher into gcrypt. Although >>> it is unlikely that in recent years, new standards to replace AES and >>> SHA3 are needed. >>> >>> "Just because you personally can not imagine some weakness in SM3 does >>> not mean there are no weaknesses in SM3." >>> >>> This is not a gold standard that we can use in the future. >>> Cryptography is based on problems that we believe hard today. If P=NP, >>> then theoretically, we have rightly zero cryptographic primitives that >>> can be long-term secure. Many reasons to dispute SM3 can also be used >>> to criticize SHA3, SHA2. No need to say MD2, MD4. There are a bunch of >>> papers on the reduced-round attack in many mainstream ciphers in >>> CRYPTO. But "attack-paper-less" cryptographic algorithms are also not >>> good because of few discussions. >>> >>> >>> [4] Unlike asymmetric encryption, the evaluation of symmetric >>> encryption is really hard. >>> >>> >>> Weikeng >>> >>> On Sun, Oct 15, 2017 at 4:21 PM, R0b0t1 wrote: >>>> >>>> On Sun, Oct 15, 2017 at 3:47 AM, Weikeng Chen wrote: >>>>> >>>>> I think it is unlikely that SM3 contains a backdoor. >>>>> >>>> >>>> This is giving the authors of SM3 a dangerous amount of credit where >>>> it is not due. Their algorithm fails a very basic test: >>>> https://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number. >>>> >>>> At best, they don't know what they are doing and made changes >>>> randomly. At worst, they made changes to make the algorithm >>>> susceptible to an undisclosed attack and could find no justification >>>> to use as a lie. >>>> >>>> Just because you personally can not imagine some weakness in SM3 does >>>> not mean there are no weaknesses in SM3. >>>> >>>>> It is intended to be used in governments and mission-critical devices. >>>>> There is no reason to use something dangerous (then U.S. can break?). >>>>> And it is generally not that easy to add a backdoor in a symmetric >>>>> algorithm if we obtain randomness from a physical source. >>>>> >>>> >>>> The problem with proving a negative in this context; that is, proving >>>> there are no back doors to the algorithm, is that it takes a huge >>>> amount of work. The "Limitations" section of the Wikipedia article >>>> above explains it well: the problem space is so large that any number >>>> of design constraints could have been engineered to provide a weakness >>>> that is only accessible to a party with special knowledge. In this >>>> sense a weakness can be made "safe" and turned into a back door. >>>> >>>> This is one of the major reasons that lack of cryptanalysis for an >>>> algorithm is suspicious: other researchers could consider it a waste >>>> of time to investigate a plausibly backdoored algorithm. >>>> >>>> Even if, however, other nation states were already aware of and could >>>> exploit the weakness, I expect that China would use a weak algorithm. >>>> China may not have the capabilities that other actors do, and may need >>>> to rely on algorithms that would be considered weak to other actors if >>>> China wants to monitor communication within its borders. >>>> >>>> As a good example, look at Russian certificate authorities and content >>>> hosts. Many of them use very weak cryptographic keys. I have seen many >>>> 512 bit RSA keys that are nowhere close to expiring. Seeing as the >>>> Russian intelligence services are apparently not capable of factoring >>>> extremely large primes, they "recommend" weak keys to their citizens >>>> (or for some other reason many businesses use weak keys). The intent >>>> behind this is to protect communication from civilian espionage but >>>> not from their own state or other states. >>>> >>>> Respectfully, >>>> R0b0t1 >>>> >>>> >>>>> >>>>> gcrypt cannot have all new functions -- otherwise, why not balloon >>>>> hashing and scrypt (the latter is used in many kinds of >>>>> cryptocurrency)? >>>>> >>>>> >>>>> >>>>> On Sat, Oct 14, 2017 at 1:16 PM, R0b0t1 wrote: >>>>>> >>>>>> On Sat, Oct 14, 2017 at 12:05 PM, ??(??) >>>>>> wrote: >>>>>>> >>>>>>> Hi Werner, >>>>>>> >>>>>>> This is the review request for SM3 hash algorithm. Plz see the commit >>>>>>> header and patch for more details. >>>>>>> >>>>>>> SM3 hash algorithm is already accepted and supported by TPM 2.0 spec. >>>>>>> So it is necessary to implement this algorithm in a famous open >>>>>>> source >>>>>>> software for checking the digest value computed by TPM. >>>>>>> >>>>>>> Plz refer to this PR (https://github.com/gpg/libgcrypt/pull/2) for >>>>>>> code >>>>>>> review. >>>>>>> >>>>>>> Thanks, >>>>>>> Jia >>>>>>> >>>>>> >>>>>> Jia, >>>>>> >>>>>> It is my understanding that SM3 was not accepted into any global TPM >>>>>> specification and is merely mandated for use within China. >>>>>> >>>>>> My research on SM3 has turned up only one detailed cryptanalysis of >>>>>> the function.[1] That cryptanalysis implies that the techniques used >>>>>> to "strengthen" SM3 do not accomplish what the creators claim, and may >>>>>> even weaken the hash function when compared to its inspiration, SHA-2. >>>>>> >>>>>> Less detailed analysis[3] of the claims presented by the creators >>>>>> reflect poorly on their work. For starters, none of the techniques >>>>>> meant to increase the security of SM3 are explained. Their utility is >>>>>> unknown, and a cursory glance shows that in at least one case a round >>>>>> operation is simplified. Perhaps more distressing is the selection of >>>>>> constants with no justification. >>>>>> >>>>>> It seems very likely that the algorithm has undisclosed backdoors. >>>>>> >>>>>> Also pertinent is the existence of GmSSL,[3] a fork of OpenSSL which >>>>>> contains various cryptographic standards developed by the Chinese >>>>>> government that were, presumably, not deemed fit for inclusion in >>>>>> OpenSSL. >>>>>> >>>>>> Inclusion of weak cryptography in gcrypt would be a disservice to >>>>>> those users which trust gcrypt with their life. I understand I am not >>>>>> the person to whom you addressed your message, nor am I a gcrypt >>>>>> developer, but I felt it necessary to reply to this conversation. >>>>>> >>>>>> Respectfully, >>>>>> R0b0t1 >>>>>> >>>>>> >>>>>> [1]: https://eprint.iacr.org/2012/274.pdf, also attached. >>>>>> [2]: https://tinycrypt.wordpress.com/2017/02/22/asmcodes-sm3/ >>>>>> [3]: http://gmssl.org/ >>>>>> >>>>>> _______________________________________________ >>>>>> Gcrypt-devel mailing list >>>>>> Gcrypt-devel at gnupg.org >>>>>> http://lists.gnupg.org/mailman/listinfo/gcrypt-devel >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Weikeng Chen @ 795 Soda Hall >>> >>> >>> >> -- Weikeng Chen @ 795 Soda Hall From r030t1 at gmail.com Tue Oct 17 22:36:27 2017 From: r030t1 at gmail.com (R0b0t1) Date: Tue, 17 Oct 2017 15:36:27 -0500 Subject: [PATCH] sm3: implement SM3 hash algorithm In-Reply-To: References: <59E243F4.3030308@alibaba-inc.com> Message-ID: On Sun, Oct 15, 2017 at 6:59 PM, Weikeng Chen wrote: > [1] Understood your concern that SM3 does not release the reason for > picking constants. This is somehow not solvable. > > I think this is a sufficient reason not to include it in the gpupg. > Because including it would be regarded as an endorsement from open > source community. If one day something is wrong, it would be > problematic. > Thank you for your understanding. > > [2] off-topic issues. Please believe that people in China visiting > Google, Facebook, and Youtube are already experts in censorship > circumvention (but it is not that easy) -- we are not that stupid > after all and not that controlled by the government. > I am not sure what this has to do with anything I said. Is the entire population of China expert cryptographers? No? Then what I said holds, and isn't an insult. I feel like I should point out for the rest of the list that finding insults where there are none is a propaganda tactic that the Chinese state media employs liberally. > I think you misunderstand the usage of SM1-4. It is only used for > government-relevant or critical circles (that would be another reason > that it is not needed to include today). It is impossible to be used > to alternate the HTTPS or anything in today's Internet. So, the > government using SM1-4 everywhere does not make it an advantage in > breaking our RSA/ECDSA/SHA2/SHA3 based Internet communication that the > major public is using (I think we should partly attribute this to the > development of gpupg). > > The political concern now goes a little bit far. > I think you misunderstand the desires of a nation state. The government mandates the use of these algorithms likely because they are broken in a hard to recover way. This means that the government can "secure" its internal communication, but still leave it accessible to eavesdropping by itself. I am not sure why you commented on the security of those other algorithms. I never implied SM3 had any relation to them or their security. If the above sounds too paranoid for you, then I am not sure what to say. > > [3] Independent of this, I think it is crucial that we have a general > rule to discuss to accept or not accept a cipher into gcrypt. Although > it is unlikely that in recent years, new standards to replace AES and > SHA3 are needed. > > "Just because you personally can not imagine some weakness in SM3 does > not mean there are no weaknesses in SM3." > > This is not a gold standard that we can use in the future. > Cryptography is based on problems that we believe hard today. If P=NP, > then theoretically, we have rightly zero cryptographic primitives that > can be long-term secure. Many reasons to dispute SM3 can also be used > to criticize SHA3, SHA2. No need to say MD2, MD4. There are a bunch of > papers on the reduced-round attack in many mainstream ciphers in > CRYPTO. But "attack-paper-less" cryptographic algorithms are also not > good because of few discussions. > You also need to consider the other evidence presented. It seems like you have, and you understand why the things I mentioned (special constants, unjustified changes) reflect poorly on the algorithm. Those points are important enough but also understandable enough that any other discussion on the matter is pointless. See also my previous post, where I note that those other algorithms are included for historical reasons. This algorithm has no historical reason for inclusion. > > [4] Unlike asymmetric encryption, the evaluation of symmetric > encryption is really hard. > In this case, it isn't. The authors of SM3 made huge mistakes that discredit the algorithm in its entirety. > Weikeng > > On Sun, Oct 15, 2017 at 4:21 PM, R0b0t1 wrote: >> On Sun, Oct 15, 2017 at 3:47 AM, Weikeng Chen wrote: >>> I think it is unlikely that SM3 contains a backdoor. >>> >> >> This is giving the authors of SM3 a dangerous amount of credit where >> it is not due. Their algorithm fails a very basic test: >> https://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number. >> >> At best, they don't know what they are doing and made changes >> randomly. At worst, they made changes to make the algorithm >> susceptible to an undisclosed attack and could find no justification >> to use as a lie. >> >> Just because you personally can not imagine some weakness in SM3 does >> not mean there are no weaknesses in SM3. >> >>> It is intended to be used in governments and mission-critical devices. >>> There is no reason to use something dangerous (then U.S. can break?). >>> And it is generally not that easy to add a backdoor in a symmetric >>> algorithm if we obtain randomness from a physical source. >>> >> >> The problem with proving a negative in this context; that is, proving >> there are no back doors to the algorithm, is that it takes a huge >> amount of work. The "Limitations" section of the Wikipedia article >> above explains it well: the problem space is so large that any number >> of design constraints could have been engineered to provide a weakness >> that is only accessible to a party with special knowledge. In this >> sense a weakness can be made "safe" and turned into a back door. >> >> This is one of the major reasons that lack of cryptanalysis for an >> algorithm is suspicious: other researchers could consider it a waste >> of time to investigate a plausibly backdoored algorithm. >> >> Even if, however, other nation states were already aware of and could >> exploit the weakness, I expect that China would use a weak algorithm. >> China may not have the capabilities that other actors do, and may need >> to rely on algorithms that would be considered weak to other actors if >> China wants to monitor communication within its borders. >> >> As a good example, look at Russian certificate authorities and content >> hosts. Many of them use very weak cryptographic keys. I have seen many >> 512 bit RSA keys that are nowhere close to expiring. Seeing as the >> Russian intelligence services are apparently not capable of factoring >> extremely large primes, they "recommend" weak keys to their citizens >> (or for some other reason many businesses use weak keys). The intent >> behind this is to protect communication from civilian espionage but >> not from their own state or other states. >> >> Respectfully, >> R0b0t1 >> >> >>> >>> gcrypt cannot have all new functions -- otherwise, why not balloon >>> hashing and scrypt (the latter is used in many kinds of >>> cryptocurrency)? >>> >>> >>> >>> On Sat, Oct 14, 2017 at 1:16 PM, R0b0t1 wrote: >>>> On Sat, Oct 14, 2017 at 12:05 PM, ??(??) wrote: >>>>> Hi Werner, >>>>> >>>>> This is the review request for SM3 hash algorithm. Plz see the commit >>>>> header and patch for more details. >>>>> >>>>> SM3 hash algorithm is already accepted and supported by TPM 2.0 spec. >>>>> So it is necessary to implement this algorithm in a famous open source >>>>> software for checking the digest value computed by TPM. >>>>> >>>>> Plz refer to this PR (https://github.com/gpg/libgcrypt/pull/2) for code >>>>> review. >>>>> >>>>> Thanks, >>>>> Jia >>>>> >>>> >>>> Jia, >>>> >>>> It is my understanding that SM3 was not accepted into any global TPM >>>> specification and is merely mandated for use within China. >>>> >>>> My research on SM3 has turned up only one detailed cryptanalysis of >>>> the function.[1] That cryptanalysis implies that the techniques used >>>> to "strengthen" SM3 do not accomplish what the creators claim, and may >>>> even weaken the hash function when compared to its inspiration, SHA-2. >>>> >>>> Less detailed analysis[3] of the claims presented by the creators >>>> reflect poorly on their work. For starters, none of the techniques >>>> meant to increase the security of SM3 are explained. Their utility is >>>> unknown, and a cursory glance shows that in at least one case a round >>>> operation is simplified. Perhaps more distressing is the selection of >>>> constants with no justification. >>>> >>>> It seems very likely that the algorithm has undisclosed backdoors. >>>> >>>> Also pertinent is the existence of GmSSL,[3] a fork of OpenSSL which >>>> contains various cryptographic standards developed by the Chinese >>>> government that were, presumably, not deemed fit for inclusion in >>>> OpenSSL. >>>> >>>> Inclusion of weak cryptography in gcrypt would be a disservice to >>>> those users which trust gcrypt with their life. I understand I am not >>>> the person to whom you addressed your message, nor am I a gcrypt >>>> developer, but I felt it necessary to reply to this conversation. >>>> >>>> Respectfully, >>>> R0b0t1 >>>> >>>> >>>> [1]: https://eprint.iacr.org/2012/274.pdf, also attached. >>>> [2]: https://tinycrypt.wordpress.com/2017/02/22/asmcodes-sm3/ >>>> [3]: http://gmssl.org/ >>>> >>>> _______________________________________________ >>>> Gcrypt-devel mailing list >>>> Gcrypt-devel at gnupg.org >>>> http://lists.gnupg.org/mailman/listinfo/gcrypt-devel >>>> >>> >>> >>> >>> -- >>> >>> Weikeng Chen @ 795 Soda Hall > > > > -- > > Weikeng Chen @ 795 Soda Hall From andre at amorim.me Wed Oct 18 02:57:24 2017 From: andre at amorim.me (Andre Amorim) Date: Wed, 18 Oct 2017 01:57:24 +0100 Subject: [PATCH] sm3: implement SM3 hash algorithm In-Reply-To: <59E569D6.8010703@alibaba-inc.com> References: <59E243F4.3030308@alibaba-inc.com> <878tgah9ga.fsf@iwagami.gniibe.org> <59E569D6.8010703@alibaba-inc.com> Message-ID: Thanks Genghis Khan On 17 October 2017 at 03:24, Jia Zhang wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > > > ? 2017/10/17 ??9:03, NIIBE Yutaka ??: > > "??(??)" wrote: > >> Hi Werner, > > > > Sorry, I'm not Werner, but another (old ???) developer of > > libgcrypt. > > Thanks for your great comments! > > > > >> This is the review request for SM3 hash algorithm. Plz see the > >> commit header and patch for more details. > > > > To track this, I created a ticket at: https://dev.gnupg.org/T3454 > > > > > > Could you please send the patch to gcrypt-devel? Or, you can > > upload your patch to: > > > > https://dev.gnupg.org/differential/ > > I just created it. See https://dev.gnupg.org/D449. > > > > >> SM3 hash algorithm is already accepted and supported by TPM 2.0 > >> spec. So it is necessary to implement this algorithm in a famous > >> open source software for checking the digest value computed by > >> TPM. > > > > Out of curiosity, is it mandated by the goverment? If so, how > > about SM2? > > > > When I read FIDO U2F document in this April, I learned about > > optional SM2 and SM3. > > To be honest, I'm not quite sure it. But at least we are seeing it is > also for civil use. I don't want to see the thing gets complicated, > cause my original intention is quite simple. I see my TPM supports SM3 > but there is no sm3sum program in coreutils to verify the hash value. > Just contribute SM3 hash function to the famous open source community > and make it easy to use. > > I'm not familiar with SM2, but I confirm I will submit it if SM3 is > approved. > > > > >> Plz refer to this PR (https://github.com/gpg/libgcrypt/pull/2) > >> for code review. > > > > We don't have a practice to use GitHub, which might require > > non-free JavaScript. > > > > Please read libgcrypt/doc/HACKING, the "How to contribute" > > section, especially the "License policy" subsection. > > I'm doing this. Copyright assignment is fine to me. > > Jia > > > > -----BEGIN PGP SIGNATURE----- > > iQIzBAEBCAAdFiEEoCC9pk5gdr326JdrPMRi5TbAeCkFAlnladYACgkQPMRi5TbA > eCmnnQ//fmPvCtzNOSaUSX3i87rvWz9fbk6OhvFNz4xKKryHbe2wsEXAiuhTtFxo > KQrRgrKBC1cKq5VN6MgCE59i5jYn2sCBOST/KeQr8esVwR1QyZBs8hlVi0lGn9Gr > mC8C/GSKcqLVNuoHjfYk6iFkEx3Zh7oA5xEfC1Yq1bbAmnlIbkEQWaUJA85ZeADJ > 4BFsb1bUvZzc0YhBKtmV0FdxN5pOpzZaww81mXhNdxaTH8yAc1nJ6rpo4VQgFs5d > 0xkmB5qeFRtToA7HKK8zUsyT1FlOJ3KYnL3bHoGIN5rJafKUcS17HziHS2onb42c > RUgzdbvtRThBC/yE6sc95qGXrmM4dRJn5AdNFpXCUmHTK29V7gmp5t3DjJgtoSV+ > Es/nPps2WTI+2Zp+i5chwPGGrljq73LcuCPE9sijEVfqmTV1rgsFmqy13Qk0vdQX > MrkRGvG6M6dRAi4MJx6HFIgtcONlgByaFBvdamfpRHso4rdFzKA4Cy/S6+fHEngl > uitJmxnqHQYCXG0dDzUJfvrCtkaxKPWDgd+KmdDN9lVtMlEkeVVA6Zbay2tjB6f8 > FjHataRSyj+zy+cp9vLAz8jIzI+EN6/yvDr6JOz/w2fCI1pLwQSAtsepoLuawAMz > ogHPXvC0jnh8483eHIjcSva0aRAKAH/b9P1FVChd4Sx/hQ3VzpA= > =xk8n > -----END PGP SIGNATURE----- > > _______________________________________________ > 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 gniibe at fsij.org Wed Oct 18 06:35:08 2017 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 18 Oct 2017 13:35:08 +0900 Subject: [SUGGESTION NEEDED] A request for suggestion on furthering the discussion over ElGamal In-Reply-To: References: <8760beh6nl.fsf@iwagami.gniibe.org> Message-ID: <87infdxedf.fsf@iwagami.gniibe.org> Hello, This message is to gcrypt-devel, Cc-ed to Weikeng Chen and Werner Koch. Weikeng Chen wrote: > Actually, my teacher Alessandro (an assistant professor of > cryptography and theory) and I (a Ph.D. student on applied > cryptography) have a brief discussion after the class. I think that... possibly, you and your teacher are so young, well, it means that I am too old. If you find some difficulty to communicate to one of maintainers of crypto implementation with long history, I think that it's normal. Don't worry. Well, I tried to answer your questions, but it seemed it didn't work and it won't work, perhaps. From this world, what I see is: you keep using your language and keep insisting your points. That's good of youth. As a Zen Buddhist, I would say: When you ask, ask yourself how and where your questions come (recursively). ElGamal is here in GnuPG, due to the patent of RSA, in the last century. GnuPG Project started in Europe. I remember Debian had non-US part [0]. Admitting some sort of dis-communication, or different terms and languages, I should write my own explanation. Here we go. I wrote: > Actually, I think that "ElGamal crypto system" can refer different > crypto systems. In the original paper of Taher Elgamal, "THE PUBLIC KEY SYSTEM" is explaind as a crypto system in Multiplicative Group of Integers modulo p $Z_p^*$, where p is large prime. In the OpenPGP standard [1], we have ElGamal encryption. In this context, "ElGamal Crypto system" specifically refers to the ElGamal Crypto system in Multiplicative Group of Integers modulo p $Z_p^*$. (For your reference, the input message into the ElGamal encryption is a session key for symmetric cipher, and it is encoded by PKCS#1 v1.5.) In the OpenPGP standard, it refers the Handbook of Applied Cryptography by Alfred Menezes, Paul van Oorschot, and Scott Vanstone [2]. In that book, probably it's too old for you, we can find a subsubsection 8.4.1 "Basic ElGamal encryption", and it describes encryption and decryption (in Multiplicative Group of Integers modulo p $Z_p^*$). The routines for ElGamal in libgcrypt, specifically implements the one in Multiplicative Group of Integers modulo p $Z_p^*$. GnuPG implements OpenPGP by using libgcrypt. You can find a concrete example how the routines of libgcrypt is used to implement the crypto protocol of OpenPGP. * * * Having written that... I don't know if it's worth or not, but it make sense to modify/enhance libgcrypt so that it can support ElGamal crypto system on Schnorr group. When it will be done, it can be used for other crypto protocol(s). If someone misunderstands as if current version of libgcrypt's ElGamal were on Schnorr group, I'm afraid it would be due to some historical revisionism or something. [0] https://wiki.debian.org/non-US [1] https://tools.ietf.org/html/rfc4880 [2] http://cacr.uwaterloo.ca/hac/ -- From w.k at berkeley.edu Wed Oct 18 07:06:11 2017 From: w.k at berkeley.edu (Weikeng Chen) Date: Tue, 17 Oct 2017 22:06:11 -0700 Subject: [SUGGESTION NEEDED] A request for suggestion on furthering the discussion over ElGamal In-Reply-To: <87infdxedf.fsf@iwagami.gniibe.org> References: <8760beh6nl.fsf@iwagami.gniibe.org> <87infdxedf.fsf@iwagami.gniibe.org> Message-ID: Thank Niibe. I will try to adjust my language -- I think that is totally normal. Don't worry! I think I got your points: (1) ElGamal is included in GnuPG and OpenPGP, one reason is the patent of RSA (Sorry! I didn't know this part of the history.) (2) At that time, OpenPGP has selected the original version of ElGamal. The RFC 4880 and the obsoleted version RFC 2440 mentions ElGamal, both follows this practice. This means that the ElGamal in libGcrypt, which has a responsibility to meet the standard, cannot have unstable changes (however, my proposal is not compatible and not aligned with the standard). I want to note again that: If used in the way you mention, then it is secure :) but also may not be good for some applications. What would be the next step you suggest? Implementing an independent elgamal-schnorr.c? Because in my proposed variant, $g$ is no longer a generator for $Z_p^*$, this is not consistent with the OpenPGP document for ElGamal configuration. Weikeng On Tue, Oct 17, 2017 at 9:35 PM, NIIBE Yutaka wrote: > Hello, > > This message is to gcrypt-devel, Cc-ed to Weikeng Chen and Werner Koch. > > Weikeng Chen wrote: >> Actually, my teacher Alessandro (an assistant professor of >> cryptography and theory) and I (a Ph.D. student on applied >> cryptography) have a brief discussion after the class. > > I think that... possibly, you and your teacher are so young, well, it > means that I am too old. If you find some difficulty to communicate to > one of maintainers of crypto implementation with long history, I think > that it's normal. Don't worry. > > > Well, I tried to answer your questions, but it seemed it didn't work and > it won't work, perhaps. From this world, what I see is: you keep using > your language and keep insisting your points. That's good of youth. > > > As a Zen Buddhist, I would say: > > When you ask, ask yourself how and where your questions come > (recursively). > > ElGamal is here in GnuPG, due to the patent of RSA, in the last century. > GnuPG Project started in Europe. I remember Debian had non-US part [0]. > > > Admitting some sort of dis-communication, or different terms and > languages, I should write my own explanation. Here we go. > > I wrote: >> Actually, I think that "ElGamal crypto system" can refer different >> crypto systems. > > In the original paper of Taher Elgamal, "THE PUBLIC KEY SYSTEM" is > explaind as a crypto system in Multiplicative Group of Integers modulo p > $Z_p^*$, where p is large prime. > > In the OpenPGP standard [1], we have ElGamal encryption. In this > context, "ElGamal Crypto system" specifically refers to the ElGamal > Crypto system in Multiplicative Group of Integers modulo p $Z_p^*$. > (For your reference, the input message into the ElGamal encryption is a > session key for symmetric cipher, and it is encoded by PKCS#1 v1.5.) > > In the OpenPGP standard, it refers the Handbook of Applied Cryptography > by Alfred Menezes, Paul van Oorschot, and Scott Vanstone [2]. In that > book, probably it's too old for you, we can find a subsubsection 8.4.1 > "Basic ElGamal encryption", and it describes encryption and decryption > (in Multiplicative Group of Integers modulo p $Z_p^*$). > > The routines for ElGamal in libgcrypt, specifically implements the one > in Multiplicative Group of Integers modulo p $Z_p^*$. > > GnuPG implements OpenPGP by using libgcrypt. You can find a concrete > example how the routines of libgcrypt is used to implement the crypto > protocol of OpenPGP. > > > * * * > > Having written that... > > I don't know if it's worth or not, but it make sense to modify/enhance > libgcrypt so that it can support ElGamal crypto system on Schnorr group. > When it will be done, it can be used for other crypto protocol(s). > > > If someone misunderstands as if current version of libgcrypt's ElGamal > were on Schnorr group, I'm afraid it would be due to some historical > revisionism or something. > > > [0] https://wiki.debian.org/non-US > [1] https://tools.ietf.org/html/rfc4880 > [2] http://cacr.uwaterloo.ca/hac/ > -- -- Weikeng Chen @ 795 Soda Hall From qianyue.zj at alibaba-inc.com Wed Oct 18 03:09:31 2017 From: qianyue.zj at alibaba-inc.com (Jia Zhang) Date: Wed, 18 Oct 2017 09:09:31 +0800 Subject: [PATCH] sm3: implement SM3 hash algorithm In-Reply-To: References: <59E243F4.3030308@alibaba-inc.com> <59E40666.7090104@alibaba-inc.com> Message-ID: <59E6A9CB.4010100@alibaba-inc.com> ? 2017/10/18 ??2:48, R0b0t1 ??: > On Sunday, October 15, 2017, Jia Zhang > wrote: >> Everyone has different expection with gcript, and personally I >> respect > the established fact: >> >> - TCG approved - Not broke - Known weak algorithms still exist >> in gcrypt >> >> gcrypt is not arrogant. It helps to extend the use of >> cryptography usage. >> >> I think it is time to end up talking about all non-engineering > discussion. Until now there is no people talking about the code > itself. >> > > If the algorithm is so weak or suspicious as to preclude inclusion > in gcrypt then there is no point in discussing the details of your > patch. > > However, to my dismay, the priorities of gcrypt lie elsewhere and > it seems as is your patch will be accepted. > > Most of the weak algorithms are included for historical reasons. > This one need not be included. > > Besides SM3's technical deficiencies, it should be obvious it > fails a test of notability. Outside of the Chinese speaking > internet no one seems to care about it, save for situations like > the one happening now where people are trying to argue to others > who have no reason to care that SM3 is notable. > > This is not xenophobia. The algorithm is suspicious and looks like > it is backdoored. It is good to have a connection with TCG committee member and ask for why. I believe they made a careful assessment of accepting SM3 into TPM 2.0 spec and have the answers you are concerning about. Jia > > Respectfully, R0b0t1 > >> >> ? 2017/10/16 ??8:01, Weikeng Chen ??: >>> >>> [1] Understood your concern that SM3 does not release the >>> reason for picking constants. This is somehow not solvable. >>> >>> I think this is a sufficient reason not to include it in the >>> gpupg. Because including it would be regarded as an >>> endorsement from open source community. If one day something is >>> wrong, it would be problematic. >>> >>> >>> [2] off-topic issues. Please believe that people in China >>> visiting Google, Facebook, and Youtube are already experts in >>> censorship circumvention (but it is not that easy) -- we are >>> not that stupid after all and not that controlled by the >>> government. >>> >>> I think you misunderstand the usage of SM1-4. It is only used >>> for government-relevant or critical circles (that would be >>> another reason that it is not needed to include today). It is >>> impossible to be used to alternate the HTTPS or anything in >>> today's Internet. So, the government using SM1-4 everywhere >>> does not make it an advantage in breaking our >>> RSA/ECDSA/SHA2/SHA3 based Internet communication that the >>> major public is using (I think we should partly attribute this >>> to the development of gpupg). >>> >>> The political concern now goes a little bit far. >>> >>> >>> [3] Independent of this, I think it is crucial that we have a >>> general rule to discuss to accept or not accept a cipher into >>> gcrypt. Although it is unlikely that in recent years, new >>> standards to replace AES and SHA3 are needed. >>> >>> "Just because you personally can not imagine some weakness in >>> SM3 does not mean there are no weaknesses in SM3." >>> >>> This is not a gold standard that we can use in the future. >>> Cryptography is based on problems that we believe hard today. >>> If P=NP, then theoretically, we have rightly zero >>> cryptographic primitives that can be long-term secure. Many >>> reasons to dispute SM3 can also be used to criticize SHA3, >>> SHA2. No need to say MD2, MD4. There are a bunch of papers on >>> the reduced-round attack in many mainstream ciphers in CRYPTO. >>> But "attack-paper-less" cryptographic algorithms are also not >>> good because of few discussions. >>> >>> >>> [4] Unlike asymmetric encryption, the evaluation of symmetric >>> encryption is really hard. >>> >>> >>> Weikeng >>> >>> On Sun, Oct 15, 2017 at 4:21 PM, R0b0t1 >>> wrote: >>>> >>>> On Sun, Oct 15, 2017 at 3:47 AM, Weikeng Chen >>>> wrote: >>>>> >>>>> I think it is unlikely that SM3 contains a backdoor. >>>>> >>>> >>>> This is giving the authors of SM3 a dangerous amount of >>>> credit where it is not due. Their algorithm fails a very >>>> basic test: >>>> https://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number. >>>> >>>> At best, they don't know what they are doing and made changes >>>> randomly. At worst, they made changes to make the algorithm >>>> susceptible to an undisclosed attack and could find no >>>> justification to use as a lie. >>>> >>>> Just because you personally can not imagine some weakness in >>>> SM3 does not mean there are no weaknesses in SM3. >>>> >>>>> It is intended to be used in governments and >>>>> mission-critical devices. There is no reason to use >>>>> something dangerous (then U.S. can break?). And it is >>>>> generally not that easy to add a backdoor in a symmetric >>>>> algorithm if we obtain randomness from a physical source. >>>>> >>>> >>>> The problem with proving a negative in this context; that >>>> is, proving there are no back doors to the algorithm, is that >>>> it takes a huge amount of work. The "Limitations" section of >>>> the Wikipedia article above explains it well: the problem >>>> space is so large that any number of design constraints could >>>> have been engineered to provide a weakness that is only >>>> accessible to a party with special knowledge. In this sense a >>>> weakness can be made "safe" and turned into a back door. >>>> >>>> This is one of the major reasons that lack of cryptanalysis >>>> for an algorithm is suspicious: other researchers could >>>> consider it a waste of time to investigate a plausibly >>>> backdoored algorithm. >>>> >>>> Even if, however, other nation states were already aware of >>>> and could exploit the weakness, I expect that China would >>>> use a weak algorithm. China may not have the capabilities >>>> that other actors do, and may need to rely on algorithms >>>> that would be considered weak to other actors if China wants >>>> to monitor communication within its borders. >>>> >>>> As a good example, look at Russian certificate authorities >>>> and content hosts. Many of them use very weak cryptographic >>>> keys. I have seen many 512 bit RSA keys that are nowhere >>>> close to expiring. Seeing as the Russian intelligence >>>> services are apparently not capable of factoring extremely >>>> large primes, they "recommend" weak keys to their citizens >>>> (or for some other reason many businesses use weak keys). >>>> The intent behind this is to protect communication from >>>> civilian espionage but not from their own state or other >>>> states. >>>> >>>> Respectfully, R0b0t1 >>>> >>>> >>>>> >>>>> gcrypt cannot have all new functions -- otherwise, why not >>>>> balloon hashing and scrypt (the latter is used in many >>>>> kinds of cryptocurrency)? >>>>> >>>>> >>>>> >>>>> On Sat, Oct 14, 2017 at 1:16 PM, R0b0t1 >>>>> wrote: >>>>>> >>>>>> On Sat, Oct 14, 2017 at 12:05 PM, ??(??) >>>>>> > wrote: >>>>>>> >>>>>>> Hi Werner, >>>>>>> >>>>>>> This is the review request for SM3 hash algorithm. Plz >>>>>>> see the commit header and patch for more details. >>>>>>> >>>>>>> SM3 hash algorithm is already accepted and supported >>>>>>> by TPM 2.0 spec. So it is necessary to implement this >>>>>>> algorithm in a famous open > source >>>>>>> software for checking the digest value computed by >>>>>>> TPM. >>>>>>> >>>>>>> Plz refer to this PR >>>>>>> (https://github.com/gpg/libgcrypt/pull/2) for > code >>>>>>> review. >>>>>>> >>>>>>> Thanks, Jia >>>>>>> >>>>>> >>>>>> Jia, >>>>>> >>>>>> It is my understanding that SM3 was not accepted into >>>>>> any global TPM specification and is merely mandated for >>>>>> use within China. >>>>>> >>>>>> My research on SM3 has turned up only one detailed >>>>>> cryptanalysis of the function.[1] That cryptanalysis >>>>>> implies that the techniques used to "strengthen" SM3 do >>>>>> not accomplish what the creators claim, and may even >>>>>> weaken the hash function when compared to its >>>>>> inspiration, SHA-2. >>>>>> >>>>>> Less detailed analysis[3] of the claims presented by the >>>>>> creators reflect poorly on their work. For starters, >>>>>> none of the techniques meant to increase the security of >>>>>> SM3 are explained. Their utility is unknown, and a >>>>>> cursory glance shows that in at least one case a round >>>>>> operation is simplified. Perhaps more distressing is the >>>>>> selection of constants with no justification. >>>>>> >>>>>> It seems very likely that the algorithm has undisclosed >>>>>> backdoors. >>>>>> >>>>>> Also pertinent is the existence of GmSSL,[3] a fork of >>>>>> OpenSSL which contains various cryptographic standards >>>>>> developed by the Chinese government that were, >>>>>> presumably, not deemed fit for inclusion in OpenSSL. >>>>>> >>>>>> Inclusion of weak cryptography in gcrypt would be a >>>>>> disservice to those users which trust gcrypt with their >>>>>> life. I understand I am not the person to whom you >>>>>> addressed your message, nor am I a gcrypt developer, but >>>>>> I felt it necessary to reply to this conversation. >>>>>> >>>>>> Respectfully, R0b0t1 >>>>>> >>>>>> >>>>>> [1]: https://eprint.iacr.org/2012/274.pdf, also attached. >>>>>> [2]: >>>>>> https://tinycrypt.wordpress.com/2017/02/22/asmcodes-sm3/ >>>>>> [3]: http://gmssl.org/ >>>>>> >>>>>> _______________________________________________ >>>>>> Gcrypt-devel mailing list Gcrypt-devel at gnupg.org >>>>>> http://lists.gnupg.org/mailman/listinfo/gcrypt-devel >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Weikeng Chen @ 795 Soda Hall >>> >>> >>> >> > From gniibe at fsij.org Thu Oct 19 03:35:12 2017 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 19 Oct 2017 10:35:12 +0900 Subject: [SUGGESTION NEEDED] A request for suggestion on furthering the discussion over ElGamal In-Reply-To: References: <8760beh6nl.fsf@iwagami.gniibe.org> <87infdxedf.fsf@iwagami.gniibe.org> Message-ID: <87k1zr2a3z.fsf@iwagami.gniibe.org> Weikeng Chen wrote: > I want to note again that: If used in the way you mention, then it is > secure :) but also may not be good for some applications. In my opinion, if "ElGamal" can be understood as "the ElGamal crypto system in Multiplicative Group of Integers modulo p $Z_p^*$", as we do, application writer should know its limitation. Well, by your posts, I learned that a sort of "revisionism", in the entry of "ElGamal encryption" in English verion of Wikipedia (BTW, Japanese version is worse. It simply denies the use of $Z_p^*$). There, it is stretched to... more general version, i.e., the one on a cyclic group. While this sort of generalization and revision by generalization are useful for academies, I am concerned in some matter of misunderstanding between school and some fields in industry. > What would be the next step you suggest? Implementing an independent > elgamal-schnorr.c? Because in my proposed variant, $g$ is no longer a > generator for $Z_p^*$, this is not consistent with the OpenPGP > document for ElGamal configuration. >From OpenPGP perspective, there is no need for change. For an exercise of programming, I think that you can write elgamal-schnorr.c based on libgcrypt/cipher/elgamal.c, only changing key generation. Well, another change is needed for elg_names, too. It would be good to have elgamal-schnorr.c in libgcrypt, but I don't know if it's worth or not. Which application uses that? Is that ElGamal so important, now, for what? I wonder. What's your purpose? Do you intend to implement some crypto protocol on top of that? Some tool with homomorphic encryption? If we design new a tool for homomorphic encryption, it seems for me that there are other crypto system which is better than ElGamal. If we design new crypto protocol on ElGamal, for some reason, it seems for me that we have better choice on a cyclic group other than Schnorr Group. Say, Elliptic curve? -- From w.k at berkeley.edu Thu Oct 19 04:28:34 2017 From: w.k at berkeley.edu (Weikeng Chen) Date: Wed, 18 Oct 2017 19:28:34 -0700 Subject: [SUGGESTION NEEDED] A request for suggestion on furthering the discussion over ElGamal Message-ID: HI Niibe, Actually, I feel the discussion enjoying. Hope I am not that annoying :) Do you have FaceBook? > In my opinion, if "ElGamal" can be understood as "the ElGamal crypto > system in Multiplicative Group of Integers modulo p $Z_p^*$", as we do, > application writer should know its limitation. No. We should accept some modification. Otherwise, today, we should say the RSA implemented in libgcrypt as 'RSA-Modified-Padded-Random', not 'RSA'. In some modern cryptography books used for school, we call the original RSA as 'textbook RSA' and show that it is not semantic secure, If semantic security is not that important, we can use the original RSA -- but today we are revisionism! > Well, by your posts, I learned that a sort of "revisionism", in the > entry of "ElGamal encryption" in English version of Wikipedia (BTW, > Japanese version is worse. It simply denies the use of $Z_p^*$). > There, it is stretched to... more general version, i.e., the one on a > cyclic group. While this sort of generalization and revision by > generalization are useful for academies, I am concerned in some matter > of misunderstanding between school and some fields in industry. They are extended to the prime-order cyclic group where DDH assumption holds (and semantic secure). There are reasons: (1) Z_p^* ElGamal cannot achieve semantic security. We want to make it easy for the numerical message. People discover Schnorr group which is not difficult to find and achieves the security. (2) ElGamal on curves. Because we have some curves that form a prime group. People prefer curves: (1) the security assumption is stronger than RSA, generally believed. (2) due to the previous reason, smaller parameters can be chosen. ciphertexts and later signatures can be small. It is used for short signature -- part of the reason why it is popular in website HTTPS certificates. I think there is always misunderstanding between school and industry. Semantic security is something real I think. > From OpenPGP perspective, there is no need for change. I agree. > For an exercise of programming, I think that you can write > elgamal-schnorr.c based on libgcrypt/cipher/elgamal.c, only changing key > generation. Well, another change is needed for elg_names, too. No. I need to both change primegen.c and create that. Maybe make a new function. > It would be good to have elgamal-schnorr.c in libgcrypt, but I don't > know if it's worth or not. Which application uses that? > Is that ElGamal so important, now, for what? I wonder. I agree that ElGamal seems no that useful today. But I think this is the problem of the industry. RSA is definitely not better then ElGamal. The assumption, the fast growth, and complicated requirement for a secure composite... padding is needed. But ElGamal is easier. You have elegantly all good properties. The security guarantee of such a Schnorr group is quite easy to follow and sum up. The ElGamal is not that mainstream because THE CORRECT VERSION IS NOT SUPPORTED BY YOUR GENERATION OF DEVELOPERS 15 YEARS AGO. And sorry... honestly speaking, is the rise of ECC/ECDSA, which can be treated as the ElGamal over curves. And also, we exchange key by DH, we sign with ECDSA, but we rarely use hybrid encryption in SSL/HTTPS -- because we have the concept of a session, and we want to reduce the use of public-key encryption as much as possible to boost the efficiency. And in homomorphic encryption, it is important. Let me explain > What's your purpose? Do you intend to implement some crypto protocol > on top of that? Some tool with homomorphic encryption? That is my loved example for an application, which ElGamal is almost the only option for some operations. > If we design new a tool for homomorphic encryption, it seems for me that > there are other crypto system which is better than ElGamal. No. There are some public-key cryptosystems with homomorphic encryption. Let me try to classify. Additive where you can get Enc(3) from Enc(1) and Enc(2): Paillier (We didn't implement it!) Multiplicative where you can get Enc(16) from Enc(8) and Enc(2): ElGamal, ***textbook*** RSA XOR where you can get E(1) from E(1) and E(0) GM (very not useful) Both with some limitations: BGN system (using bilinear mapping and pairing-based cryptography -- they are not industry at all so not GNU-thing totally) Both with no restriction but slow: Fully Homomorphic Encryption BGV system Here, there are two for multiplicative encryptions, ElGamal and textbook RSA. But textbook RSA is definitely not secure (everybody tries to pad with random thing to meet some standard). However, the padded version, which is semantic secure, loses the homomorphism. But ElGamal is totally okay. After all the encoding things I mention, it is both semantic secure and multiplicative homomorphism. If I can add some more jargon things -- ElGamal supports ciphertext anonymity (which can be used to build secure messaging systems). It can be multiple layers. It can support rerandomization. It can support rerandomization without the public key (called universal rerandomization). These are known in the small (maybe large) academic circle but I think you can never find it in Wikipedia. > If we design new crypto protocol on ElGamal, for some reason, it seems > for me that we have better choice on a cyclic group other than Schnorr > Group. Say, Elliptic curve? We need to encode the messages to a point before making it to the curve. The general way is to try to hash the data into $x$ and then find a $y$ -- so it becomes a point. Such technique removes the homomorphism. On Wed, Oct 18, 2017 at 6:35 PM, NIIBE Yutaka wrote: > Weikeng Chen wrote: >> I want to note again that: If used in the way you mention, then it is >> secure :) but also may not be good for some applications. > > In my opinion, if "ElGamal" can be understood as "the ElGamal crypto > system in Multiplicative Group of Integers modulo p $Z_p^*$", as we do, > application writer should know its limitation. > > Well, by your posts, I learned that a sort of "revisionism", in the > entry of "ElGamal encryption" in English verion of Wikipedia (BTW, > Japanese version is worse. It simply denies the use of $Z_p^*$). > There, it is stretched to... more general version, i.e., the one on a > cyclic group. While this sort of generalization and revision by > generalization are useful for academies, I am concerned in some matter > of misunderstanding between school and some fields in industry. > >> What would be the next step you suggest? Implementing an independent >> elgamal-schnorr.c? Because in my proposed variant, $g$ is no longer a >> generator for $Z_p^*$, this is not consistent with the OpenPGP >> document for ElGamal configuration. > > From OpenPGP perspective, there is no need for change. > > For an exercise of programming, I think that you can write > elgamal-schnorr.c based on libgcrypt/cipher/elgamal.c, only changing key > generation. Well, another change is needed for elg_names, too. > > > It would be good to have elgamal-schnorr.c in libgcrypt, but I don't > know if it's worth or not. Which application uses that? > > Is that ElGamal so important, now, for what? I wonder. > > What's your purpose? Do you intend to implement some crypto protocol > on top of that? Some tool with homomorphic encryption? > > If we design new a tool for homomorphic encryption, it seems for me that > there are other crypto system which is better than ElGamal. > > If we design new crypto protocol on ElGamal, for some reason, it seems > for me that we have better choice on a cyclic group other than Schnorr > Group. Say, Elliptic curve? > -- -- Weikeng Chen @ 795 Soda Hall -- Weikeng Chen @ 795 Soda Hall From cvs at cvs.gnupg.org Thu Oct 19 04:36:26 2017 From: cvs at cvs.gnupg.org (by NIIBE Yutaka) Date: Thu, 19 Oct 2017 04:36:26 +0200 Subject: [git] GCRYPT - branch, master, updated. libgcrypt-1.8.1-16-g72d0ca1 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 72d0ca10c884e09e8f28f084c385743c0796f09c (commit) from c6e42e7ec3d1046969d783c443c13aad7cb61bb8 (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 72d0ca10c884e09e8f28f084c385743c0796f09c Author: NIIBE Yutaka Date: Thu Oct 19 11:35:00 2017 +0900 Register DCO for Jia Zhang. -- Signed-off-by: NIIBE Yutaka diff --git a/AUTHORS b/AUTHORS index 0d1da12..8c553e6 100644 --- a/AUTHORS +++ b/AUTHORS @@ -157,6 +157,9 @@ Dmitry Eremin-Solenikov Dmitry Kasatkin 2012-12-14:50CAE2DB.80302 at intel.com: +Jia Zhang +2017-10-17:59E56E30.9060503 at alibaba-inc.com: + J?r?mie Courr?ges-Anglas 2016-05-26:87bn3ssqg0.fsf at ritchie.wxcvbn.org: ----------------------------------------------------------------------- Summary of changes: AUTHORS | 3 +++ 1 file changed, 3 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 r030t1 at gmail.com Thu Oct 19 05:44:43 2017 From: r030t1 at gmail.com (R0b0t1) Date: Wed, 18 Oct 2017 22:44:43 -0500 Subject: [PATCH] sm3: implement SM3 hash algorithm In-Reply-To: <59E6A9CB.4010100@alibaba-inc.com> References: <59E243F4.3030308@alibaba-inc.com> <59E40666.7090104@alibaba-inc.com> <59E6A9CB.4010100@alibaba-inc.com> Message-ID: On Tue, Oct 17, 2017 at 8:09 PM, Jia Zhang wrote: > > > ? 2017/10/18 ??2:48, R0b0t1 ??: >> On Sunday, October 15, 2017, Jia Zhang >> wrote: >>> Everyone has different expection with gcript, and personally I >>> respect >> the established fact: >>> >>> - TCG approved - Not broke - Known weak algorithms still exist >>> in gcrypt >>> >>> gcrypt is not arrogant. It helps to extend the use of >>> cryptography usage. >>> >>> I think it is time to end up talking about all non-engineering >> discussion. Until now there is no people talking about the code >> itself. >>> >> >> If the algorithm is so weak or suspicious as to preclude inclusion >> in gcrypt then there is no point in discussing the details of your >> patch. >> >> However, to my dismay, the priorities of gcrypt lie elsewhere and >> it seems as is your patch will be accepted. >> >> Most of the weak algorithms are included for historical reasons. >> This one need not be included. >> >> Besides SM3's technical deficiencies, it should be obvious it >> fails a test of notability. Outside of the Chinese speaking >> internet no one seems to care about it, save for situations like >> the one happening now where people are trying to argue to others >> who have no reason to care that SM3 is notable. >> >> This is not xenophobia. The algorithm is suspicious and looks like >> it is backdoored. > > It is good to have a connection with TCG committee member and ask for > why. I believe they made a careful assessment of accepting SM3 into > TPM 2.0 spec and have the answers you are concerning about. > > Jia > Standards bodies will often do what governments request regardless of reason. In this case, having compliant products sold in China was enough of a carrot that I expect no true assessment took place. If SM3 was not included, the Chinese government would have simply created their own standard and fragmented the market. Respectfully, R0b0t1 >> >> Respectfully, R0b0t1 >> >>> >>> ? 2017/10/16 ??8:01, Weikeng Chen ??: >>>> >>>> [1] Understood your concern that SM3 does not release the >>>> reason for picking constants. This is somehow not solvable. >>>> >>>> I think this is a sufficient reason not to include it in the >>>> gpupg. Because including it would be regarded as an >>>> endorsement from open source community. If one day something is >>>> wrong, it would be problematic. >>>> >>>> >>>> [2] off-topic issues. Please believe that people in China >>>> visiting Google, Facebook, and Youtube are already experts in >>>> censorship circumvention (but it is not that easy) -- we are >>>> not that stupid after all and not that controlled by the >>>> government. >>>> >>>> I think you misunderstand the usage of SM1-4. It is only used >>>> for government-relevant or critical circles (that would be >>>> another reason that it is not needed to include today). It is >>>> impossible to be used to alternate the HTTPS or anything in >>>> today's Internet. So, the government using SM1-4 everywhere >>>> does not make it an advantage in breaking our >>>> RSA/ECDSA/SHA2/SHA3 based Internet communication that the >>>> major public is using (I think we should partly attribute this >>>> to the development of gpupg). >>>> >>>> The political concern now goes a little bit far. >>>> >>>> >>>> [3] Independent of this, I think it is crucial that we have a >>>> general rule to discuss to accept or not accept a cipher into >>>> gcrypt. Although it is unlikely that in recent years, new >>>> standards to replace AES and SHA3 are needed. >>>> >>>> "Just because you personally can not imagine some weakness in >>>> SM3 does not mean there are no weaknesses in SM3." >>>> >>>> This is not a gold standard that we can use in the future. >>>> Cryptography is based on problems that we believe hard today. >>>> If P=NP, then theoretically, we have rightly zero >>>> cryptographic primitives that can be long-term secure. Many >>>> reasons to dispute SM3 can also be used to criticize SHA3, >>>> SHA2. No need to say MD2, MD4. There are a bunch of papers on >>>> the reduced-round attack in many mainstream ciphers in CRYPTO. >>>> But "attack-paper-less" cryptographic algorithms are also not >>>> good because of few discussions. >>>> >>>> >>>> [4] Unlike asymmetric encryption, the evaluation of symmetric >>>> encryption is really hard. >>>> >>>> >>>> Weikeng >>>> >>>> On Sun, Oct 15, 2017 at 4:21 PM, R0b0t1 >>>> wrote: >>>>> >>>>> On Sun, Oct 15, 2017 at 3:47 AM, Weikeng Chen >>>>> wrote: >>>>>> >>>>>> I think it is unlikely that SM3 contains a backdoor. >>>>>> >>>>> >>>>> This is giving the authors of SM3 a dangerous amount of >>>>> credit where it is not due. Their algorithm fails a very >>>>> basic test: >>>>> https://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number. >>>>> >>>>> At best, they don't know what they are doing and made changes >>>>> randomly. At worst, they made changes to make the algorithm >>>>> susceptible to an undisclosed attack and could find no >>>>> justification to use as a lie. >>>>> >>>>> Just because you personally can not imagine some weakness in >>>>> SM3 does not mean there are no weaknesses in SM3. >>>>> >>>>>> It is intended to be used in governments and >>>>>> mission-critical devices. There is no reason to use >>>>>> something dangerous (then U.S. can break?). And it is >>>>>> generally not that easy to add a backdoor in a symmetric >>>>>> algorithm if we obtain randomness from a physical source. >>>>>> >>>>> >>>>> The problem with proving a negative in this context; that >>>>> is, proving there are no back doors to the algorithm, is that >>>>> it takes a huge amount of work. The "Limitations" section of >>>>> the Wikipedia article above explains it well: the problem >>>>> space is so large that any number of design constraints could >>>>> have been engineered to provide a weakness that is only >>>>> accessible to a party with special knowledge. In this sense a >>>>> weakness can be made "safe" and turned into a back door. >>>>> >>>>> This is one of the major reasons that lack of cryptanalysis >>>>> for an algorithm is suspicious: other researchers could >>>>> consider it a waste of time to investigate a plausibly >>>>> backdoored algorithm. >>>>> >>>>> Even if, however, other nation states were already aware of >>>>> and could exploit the weakness, I expect that China would >>>>> use a weak algorithm. China may not have the capabilities >>>>> that other actors do, and may need to rely on algorithms >>>>> that would be considered weak to other actors if China wants >>>>> to monitor communication within its borders. >>>>> >>>>> As a good example, look at Russian certificate authorities >>>>> and content hosts. Many of them use very weak cryptographic >>>>> keys. I have seen many 512 bit RSA keys that are nowhere >>>>> close to expiring. Seeing as the Russian intelligence >>>>> services are apparently not capable of factoring extremely >>>>> large primes, they "recommend" weak keys to their citizens >>>>> (or for some other reason many businesses use weak keys). >>>>> The intent behind this is to protect communication from >>>>> civilian espionage but not from their own state or other >>>>> states. >>>>> >>>>> Respectfully, R0b0t1 >>>>> >>>>> >>>>>> >>>>>> gcrypt cannot have all new functions -- otherwise, why not >>>>>> balloon hashing and scrypt (the latter is used in many >>>>>> kinds of cryptocurrency)? >>>>>> >>>>>> >>>>>> >>>>>> On Sat, Oct 14, 2017 at 1:16 PM, R0b0t1 >>>>>> wrote: >>>>>>> >>>>>>> On Sat, Oct 14, 2017 at 12:05 PM, ??(??) >>>>>>> >> wrote: >>>>>>>> >>>>>>>> Hi Werner, >>>>>>>> >>>>>>>> This is the review request for SM3 hash algorithm. Plz >>>>>>>> see the commit header and patch for more details. >>>>>>>> >>>>>>>> SM3 hash algorithm is already accepted and supported >>>>>>>> by TPM 2.0 spec. So it is necessary to implement this >>>>>>>> algorithm in a famous open >> source >>>>>>>> software for checking the digest value computed by >>>>>>>> TPM. >>>>>>>> >>>>>>>> Plz refer to this PR >>>>>>>> (https://github.com/gpg/libgcrypt/pull/2) for >> code >>>>>>>> review. >>>>>>>> >>>>>>>> Thanks, Jia >>>>>>>> >>>>>>> >>>>>>> Jia, >>>>>>> >>>>>>> It is my understanding that SM3 was not accepted into >>>>>>> any global TPM specification and is merely mandated for >>>>>>> use within China. >>>>>>> >>>>>>> My research on SM3 has turned up only one detailed >>>>>>> cryptanalysis of the function.[1] That cryptanalysis >>>>>>> implies that the techniques used to "strengthen" SM3 do >>>>>>> not accomplish what the creators claim, and may even >>>>>>> weaken the hash function when compared to its >>>>>>> inspiration, SHA-2. >>>>>>> >>>>>>> Less detailed analysis[3] of the claims presented by the >>>>>>> creators reflect poorly on their work. For starters, >>>>>>> none of the techniques meant to increase the security of >>>>>>> SM3 are explained. Their utility is unknown, and a >>>>>>> cursory glance shows that in at least one case a round >>>>>>> operation is simplified. Perhaps more distressing is the >>>>>>> selection of constants with no justification. >>>>>>> >>>>>>> It seems very likely that the algorithm has undisclosed >>>>>>> backdoors. >>>>>>> >>>>>>> Also pertinent is the existence of GmSSL,[3] a fork of >>>>>>> OpenSSL which contains various cryptographic standards >>>>>>> developed by the Chinese government that were, >>>>>>> presumably, not deemed fit for inclusion in OpenSSL. >>>>>>> >>>>>>> Inclusion of weak cryptography in gcrypt would be a >>>>>>> disservice to those users which trust gcrypt with their >>>>>>> life. I understand I am not the person to whom you >>>>>>> addressed your message, nor am I a gcrypt developer, but >>>>>>> I felt it necessary to reply to this conversation. >>>>>>> >>>>>>> Respectfully, R0b0t1 >>>>>>> >>>>>>> >>>>>>> [1]: https://eprint.iacr.org/2012/274.pdf, also attached. >>>>>>> [2]: >>>>>>> https://tinycrypt.wordpress.com/2017/02/22/asmcodes-sm3/ >>>>>>> [3]: http://gmssl.org/ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Gcrypt-devel mailing list Gcrypt-devel at gnupg.org >>>>>>> http://lists.gnupg.org/mailman/listinfo/gcrypt-devel >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Weikeng Chen @ 795 Soda Hall >>>> >>>> >>>> >>> >> From wk at gnupg.org Thu Oct 19 13:43:57 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 19 Oct 2017 13:43:57 +0200 Subject: [PATCH] sm3: implement SM3 hash algorithm In-Reply-To: (R0b0t1's message of "Tue, 17 Oct 2017 13:48:20 -0500") References: <59E243F4.3030308@alibaba-inc.com> <59E40666.7090104@alibaba-inc.com> Message-ID: <87tvyvmkg2.fsf@wheatstone.g10code.de> On Tue, 17 Oct 2017 20:48, r030t1 at gmail.com said: > This is not xenophobia. The algorithm is suspicious and looks like it is > backdoored. May I suggest that you take your concerns to cryptography [1] so that we have a public record of them? In contrast to gcrypt-devel many cryptographers are reading cryptography at . Shalom-Salam, Werner [1] This is cryptography at metzdowd com (formerly known as the coderpunks list) -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Thu Oct 19 13:57:04 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 19 Oct 2017 13:57:04 +0200 Subject: [SUGGESTION NEEDED] A request for suggestion on furthering the discussion over ElGamal In-Reply-To: <87k1zr2a3z.fsf@iwagami.gniibe.org> (NIIBE Yutaka's message of "Thu, 19 Oct 2017 10:35:12 +0900") References: <8760beh6nl.fsf@iwagami.gniibe.org> <87infdxedf.fsf@iwagami.gniibe.org> <87k1zr2a3z.fsf@iwagami.gniibe.org> Message-ID: <87po9jmju7.fsf@wheatstone.g10code.de> On Thu, 19 Oct 2017 03:35, gniibe at fsij.org said: > It would be good to have elgamal-schnorr.c in libgcrypt, but I don't > know if it's worth or not. Which application uses that? I can't tell either. Let me note that for example GNUnet uses and used modified versions of standard algorithms and they have not yet made it into Libgcrypt as a "high-level" API. Thus they need to use lower level functions of Libgcrypt to implement that - which of course works. When we are getting to the point that those algorithms are in widespread use, it will indeed make sense to implement a dedicated API for such an algorithm. > for me that we have better choice on a cyclic group other than Schnorr > Group. Say, Elliptic curve? GNUnet also moved away from DSA to EC derived algorithms. Regarding the improper use of Elgamal, the Libgcrypt release announcements tell this: Thorough understanding of applied cryptography is required to use Libgcrypt. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From w.k at berkeley.edu Thu Oct 19 18:29:05 2017 From: w.k at berkeley.edu (Weikeng Chen) Date: Thu, 19 Oct 2017 09:29:05 -0700 Subject: [SUGGESTION NEEDED] A request for suggestion on furthering the discussion over ElGamal In-Reply-To: <87po9jmju7.fsf@wheatstone.g10code.de> References: <8760beh6nl.fsf@iwagami.gniibe.org> <87infdxedf.fsf@iwagami.gniibe.org> <87k1zr2a3z.fsf@iwagami.gniibe.org> <87po9jmju7.fsf@wheatstone.g10code.de> Message-ID: Hi Werner But will " Thorough understanding of applied cryptography is required to use Libgcrypt." be an effective warning rather than just a disclaimer? Weikeng On Thu, Oct 19, 2017 at 4:57 AM, Werner Koch wrote: > On Thu, 19 Oct 2017 03:35, gniibe at fsij.org said: > >> It would be good to have elgamal-schnorr.c in libgcrypt, but I don't >> know if it's worth or not. Which application uses that? > > I can't tell either. Let me note that for example GNUnet uses and used > modified versions of standard algorithms and they have not yet made it > into Libgcrypt as a "high-level" API. Thus they need to use lower level > functions of Libgcrypt to implement that - which of course works. When > we are getting to the point that those algorithms are in widespread use, > it will indeed make sense to implement a dedicated API for such an > algorithm. > >> for me that we have better choice on a cyclic group other than Schnorr >> Group. Say, Elliptic curve? > > GNUnet also moved away from DSA to EC derived algorithms. > > Regarding the improper use of Elgamal, the Libgcrypt release > announcements tell this: > > Thorough understanding of applied cryptography is required > to use Libgcrypt. > > > > > Salam-Shalom, > > Werner > > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -- Weikeng Chen @ 795 Soda Hall From andre at amorim.me Fri Oct 20 11:25:17 2017 From: andre at amorim.me (Andre Amorim) Date: Fri, 20 Oct 2017 10:25:17 +0100 Subject: [PATCH] sm3: implement SM3 hash algorithm In-Reply-To: <87tvyvmkg2.fsf@wheatstone.g10code.de> References: <59E243F4.3030308@alibaba-inc.com> <59E40666.7090104@alibaba-inc.com> <87tvyvmkg2.fsf@wheatstone.g10code.de> Message-ID: On Tue, 17 Oct 2017 20:48, r030t1 at gmail.com said: > >This is not xenophobia. The algorithm is suspicious and looks like it is > >backdoored. >May I suggest that you take your concerns to cryptography [1] so that we >have a public record of them? In contrast to gcrypt-devel many >cryptographers are reading cryptography at . >Shalom-Salam, >--Werner Indeed.I will borrow Bruce Schneier's quote on his book "Cryptography Engineering: Design Principles and Practical Applications" In this field, we make a very strict distinction between attacking somebody's work and attacking somebody personally. Any work is fair game. If somebody proposes something, it is an automatic invitation to attack it. If you break one of our systems, we will applaud the attack and tell everybody about it.2 We constantly look for weaknesses in any system because that is the only way to learn how to make more secure systems. This is one thing you will have to learn: an attack on your work is not an attack on you. Also, when you attack a system, always be sure to criticize the system, not the designers. Personal attacks in cryptography will get you the same negative response as anywhere else Shalom-Salam --Andr{`'{e}} [1] This is cryptography at metzdowd com (formerly known as the coderpunks list) On 19 October 2017 at 12:43, Werner Koch wrote: > On Tue, 17 Oct 2017 20:48, r030t1 at gmail.com said: > >> This is not xenophobia. The algorithm is suspicious and looks like it is >> backdoored. > > May I suggest that you take your concerns to cryptography [1] so that we > have a public record of them? In contrast to gcrypt-devel many > cryptographers are reading cryptography at . > > > Shalom-Salam, > > Werner > > > > [1] This is cryptography at metzdowd com (formerly known as the > coderpunks list) > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > _______________________________________________ > Gcrypt-devel mailing list > Gcrypt-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gcrypt-devel > From qianyue.zj at alibaba-inc.com Mon Oct 23 04:06:42 2017 From: qianyue.zj at alibaba-inc.com (Jia Zhang) Date: Mon, 23 Oct 2017 10:06:42 +0800 Subject: [PATCH] sm3: implement SM3 hash algorithm In-Reply-To: <87tvyvmkg2.fsf@wheatstone.g10code.de> References: <59E243F4.3030308@alibaba-inc.com> <59E40666.7090104@alibaba-inc.com> <87tvyvmkg2.fsf@wheatstone.g10code.de> Message-ID: <59ED4EB2.5090201@alibaba-inc.com> Hi Werner & Niibe, Shall we start code review now? Again, r030tl's concern sounds reasonable but the most of parts are not established fact yet. It is not enough to block the code review, correct? The code review has been submitted to https://dev.gnupg.org/D449 for a while. Plz help to review it. Thanks, Jia ? 2017/10/19 ??7:43, Werner Koch ??: > On Tue, 17 Oct 2017 20:48, r030t1 at gmail.com said: > >> This is not xenophobia. The algorithm is suspicious and looks >> like it is backdoored. > > May I suggest that you take your concerns to cryptography [1] so > that we have a public record of them? In contrast to gcrypt-devel > many cryptographers are reading cryptography at . > > > Shalom-Salam, > > Werner > > > > [1] This is cryptography at metzdowd com (formerly known as the > coderpunks list) > From gniibe at fsij.org Tue Oct 24 04:08:11 2017 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 24 Oct 2017 11:08:11 +0900 Subject: [PATCH] sm3: implement SM3 hash algorithm In-Reply-To: <59ED4EB2.5090201@alibaba-inc.com> References: <59E243F4.3030308@alibaba-inc.com> <59E40666.7090104@alibaba-inc.com> <87tvyvmkg2.fsf@wheatstone.g10code.de> <59ED4EB2.5090201@alibaba-inc.com> Message-ID: <87o9oxi9h0.fsf@iwagami.gniibe.org> Jia Zhang wrote: > The code review has been submitted to https://dev.gnupg.org/D449 for a > while. Plz help to review it. I put my comments there. I think that I should have replied here. So, I am replying now. It would be good if I can read the definitive document for the Chinese standard. Even if it's written in Chinese it will work for me. If any other reference, please let me know. Besides, do you know the hash has an OID (object identifier)? -- From qianyue.zj at alibaba-inc.com Tue Oct 24 04:33:47 2017 From: qianyue.zj at alibaba-inc.com (Jia Zhang) Date: Tue, 24 Oct 2017 10:33:47 +0800 Subject: [PATCH] sm3: implement SM3 hash algorithm In-Reply-To: <87o9oxi9h0.fsf@iwagami.gniibe.org> References: <59E243F4.3030308@alibaba-inc.com> <59E40666.7090104@alibaba-inc.com> <87tvyvmkg2.fsf@wheatstone.g10code.de> <59ED4EB2.5090201@alibaba-inc.com> <87o9oxi9h0.fsf@iwagami.gniibe.org> Message-ID: <59EEA68B.6010208@alibaba-inc.com> ? 2017/10/24 ??10:08, NIIBE Yutaka ??: > Jia Zhang wrote: >> The code review has been submitted to https://dev.gnupg.org/D449 >> for a while. Plz help to review it. > > I put my comments there. I think that I should have replied here. > So, I am replying now. Thank you very much! I added my comments to the review. Jia > > It would be good if I can read the definitive document for the > Chinese standard. Even if it's written in Chinese it will work for > me. If any other reference, please let me know. > > Besides, do you know the hash has an OID (object identifier)? > From cvs at cvs.gnupg.org Tue Oct 24 09:04:45 2017 From: cvs at cvs.gnupg.org (by NIIBE Yutaka) Date: Tue, 24 Oct 2017 09:04:45 +0200 Subject: [git] GCRYPT - branch, master, updated. libgcrypt-1.8.1-18-gaa94491 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 aa944910979b52ad4ca2b317b9d551d8b4d48df2 (commit) via 5b31e22d9fc542bdccb1586ef2c83d9794a731d3 (commit) from 72d0ca10c884e09e8f28f084c385743c0796f09c (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 aa944910979b52ad4ca2b317b9d551d8b4d48df2 Author: NIIBE Yutaka Date: Tue Oct 24 15:55:12 2017 +0900 Add crypto hash SM3. * configure.ac (available_digests): Add sm3. * src/cipher.h: Add declarations for SM3. * cipher/Makefile.am (EXTRA_libcipher_la_SOURCES): Add sm3.c. * cipher/md.c [USE_SM3] (digest_list): Add _gcry_digest_spec_sm3. * cipher/pubkey-util.c (hashnames): Add "sm3". * cipher/sm3.c: New. * tests/basic.c (check_digests): Add test vectors for SM3. * tests/hashtest-256g.in (algos): Add SM3. * tests/hashtest.c (testvectors): Add for SM3. -- GnuPG-bug-id: 3454 Signed-off-by: Jia Zhang diff --git a/cipher/Makefile.am b/cipher/Makefile.am index ee99262..bbfab4c 100644 --- a/cipher/Makefile.am +++ b/cipher/Makefile.am @@ -96,6 +96,7 @@ sha256.c sha256-ssse3-amd64.S sha256-avx-amd64.S sha256-avx2-bmi2-amd64.S \ sha256-armv8-aarch32-ce.S sha256-armv8-aarch64-ce.S \ sha512.c sha512-ssse3-amd64.S sha512-avx-amd64.S sha512-avx2-bmi2-amd64.S \ sha512-armv7-neon.S sha512-arm.S \ +sm3.c \ keccak.c keccak_permute_32.h keccak_permute_64.h keccak-armv7-neon.S \ stribog.c \ tiger.c \ diff --git a/cipher/md.c b/cipher/md.c index c1f585f..94f1b5d 100644 --- a/cipher/md.c +++ b/cipher/md.c @@ -95,6 +95,9 @@ static gcry_md_spec_t *digest_list[] = &_gcry_digest_spec_blake2s_160, &_gcry_digest_spec_blake2s_128, #endif +#if USE_SM3 + &_gcry_digest_spec_sm3, +#endif NULL }; diff --git a/cipher/pubkey-util.c b/cipher/pubkey-util.c index c40ef97..ae0e1c4 100644 --- a/cipher/pubkey-util.c +++ b/cipher/pubkey-util.c @@ -221,6 +221,7 @@ get_hash_algo (const char *s, size_t n) { "sha3-256", GCRY_MD_SHA3_256 }, { "sha3-384", GCRY_MD_SHA3_384 }, { "sha3-512", GCRY_MD_SHA3_512 }, + { "sm3", GCRY_MD_SM3 }, { NULL, 0 } }; int algo; diff --git a/cipher/sm3.c b/cipher/sm3.c new file mode 100644 index 0000000..f0c574a --- /dev/null +++ b/cipher/sm3.c @@ -0,0 +1,454 @@ +/* sm3.c - SM3 hash function + * Copyright (C) 2017 Jia Zhang + * + * This file is part of Libgcrypt. + * + * Libgcrypt is free software; you can redistribute it and/or modify + * it under the terms of the GNU Lesser General Public License as + * published by the Free Software Foundation; either version 2.1 of + * the License, or (at your option) any later version. + * + * Libgcrypt is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this program; if not, see . + */ + + +/* Test vectors: + + "abc" + SM3: 66c7f0f4 62eeedd9 d1f2d46b dc10e4e2 4167c487 5cf2f7a2 297da02b 8f4ba8e0 + + "abcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcd" + SM3: debe9ff9 2275b8a1 38604889 c18e5a4d 6fdb70e5 387e5765 293dcba3 9c0c5732 + + "abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq" + SM3: 639b6cc5 e64d9e37 a390b192 df4fa1ea 0720ab74 7ff692b9 f38c4e66 ad7b8c05 + + "a" one million times + SM3: c8aaf894 29554029 e231941a 2acc0ad6 1ff2a5ac d8fadd25 847a3a73 2b3b02c3 + + */ + + +#include +#include +#include +#include + +#include "g10lib.h" +#include "bithelp.h" +#include "bufhelp.h" +#include "cipher.h" +#include "hash-common.h" + + +typedef struct { + gcry_md_block_ctx_t bctx; + u32 h0,h1,h2,h3,h4,h5,h6,h7; +} SM3_CONTEXT; + + +static unsigned int +transform (void *c, const unsigned char *data, size_t nblks); + + +static void +sm3_init (void *context, unsigned int flags) +{ + SM3_CONTEXT *hd = context; + unsigned int features = _gcry_get_hw_features (); + + (void)flags; + + hd->h0 = 0x7380166f; + hd->h1 = 0x4914b2b9; + hd->h2 = 0x172442d7; + hd->h3 = 0xda8a0600; + hd->h4 = 0xa96f30bc; + hd->h5 = 0x163138aa; + hd->h6 = 0xe38dee4d; + hd->h7 = 0xb0fb0e4e; + + hd->bctx.nblocks = 0; + hd->bctx.nblocks_high = 0; + hd->bctx.count = 0; + hd->bctx.blocksize = 64; + hd->bctx.bwrite = transform; + + (void)features; +} + + +/* + Transform the message X which consists of 16 32-bit-words. See + GM/T 004-2012 for details. */ +#define R(i,a,b,c,d,e,f,g,h,t,w1,w2) do \ + { \ + ss1 = rol ((rol ((a), 12) + (e) + (t)), 7); \ + ss2 = ss1 ^ rol ((a), 12); \ + d += FF##i(a,b,c) + ss2 + ((w1) ^ (w2)); \ + h += GG##i(e,f,g) + ss1 + (w1); \ + b = rol ((b), 9); \ + f = rol ((f), 19); \ + h = P0 ((h)); \ + } while (0) + +#define R1(a,b,c,d,e,f,g,h,t,w1,w2) R(1,a,b,c,d,e,f,g,h,t,w1,w2) +#define R2(a,b,c,d,e,f,g,h,t,w1,w2) R(2,a,b,c,d,e,f,g,h,t,w1,w2) + +#define FF1(x, y, z) (x ^ y ^ z) + +#define FF2(x, y, z) ((x & y) | (x & z) | (y & z)) + +#define GG1(x, y, z) (x ^ y ^ z) + +#define GG2(x, y, z) ((x & y) | ( ~x & z)) + +/* Message expansion */ +#define P0(x) ((x) ^ rol ((x), 9) ^ rol ((x), 17)) +#define P1(x) ((x) ^ rol ((x), 15) ^ rol ((x), 23)) +#define I(i) ( w[i] = buf_get_be32(data + i * 4) ) +#define W1(i) ( w[i&0x0f] ) +#define W2(i) ( w[i&0x0f] = P1(w[i &0x0f] \ + ^ w[(i-9)&0x0f] \ + ^ rol (w[(i-3)&0x0f], 15)) \ + ^ rol (w[(i-13)&0x0f], 7) \ + ^ w[(i-6)&0x0f] ) + +static unsigned int +transform_blk (void *ctx, const unsigned char *data) +{ + SM3_CONTEXT *hd = ctx; + static const u32 K[64] = { + 0x79cc4519, 0xf3988a32, 0xe7311465, 0xce6228cb, + 0x9cc45197, 0x3988a32f, 0x7311465e, 0xe6228cbc, + 0xcc451979, 0x988a32f3, 0x311465e7, 0x6228cbce, + 0xc451979c, 0x88a32f39, 0x11465e73, 0x228cbce6, + 0x9d8a7a87, 0x3b14f50f, 0x7629ea1e, 0xec53d43c, + 0xd8a7a879, 0xb14f50f3, 0x629ea1e7, 0xc53d43ce, + 0x8a7a879d, 0x14f50f3b, 0x29ea1e76, 0x53d43cec, + 0xa7a879d8, 0x4f50f3b1, 0x9ea1e762, 0x3d43cec5, + 0x7a879d8a, 0xf50f3b14, 0xea1e7629, 0xd43cec53, + 0xa879d8a7, 0x50f3b14f, 0xa1e7629e, 0x43cec53d, + 0x879d8a7a, 0x0f3b14f5, 0x1e7629ea, 0x3cec53d4, + 0x79d8a7a8, 0xf3b14f50, 0xe7629ea1, 0xcec53d43, + 0x9d8a7a87, 0x3b14f50f, 0x7629ea1e, 0xec53d43c, + 0xd8a7a879, 0xb14f50f3, 0x629ea1e7, 0xc53d43ce, + 0x8a7a879d, 0x14f50f3b, 0x29ea1e76, 0x53d43cec, + 0xa7a879d8, 0x4f50f3b1, 0x9ea1e762, 0x3d43cec5 + }; + + u32 a,b,c,d,e,f,g,h,ss1,ss2; + u32 w[16]; + + a = hd->h0; + b = hd->h1; + c = hd->h2; + d = hd->h3; + e = hd->h4; + f = hd->h5; + g = hd->h6; + h = hd->h7; + + R1(a, b, c, d, e, f, g, h, K[0], I(0), I(4)); + R1(d, a, b, c, h, e, f, g, K[1], I(1), I(5)); + R1(c, d, a, b, g, h, e, f, K[2], I(2), I(6)); + R1(b, c, d, a, f, g, h, e, K[3], I(3), I(7)); + R1(a, b, c, d, e, f, g, h, K[4], W1(4), I(8)); + R1(d, a, b, c, h, e, f, g, K[5], W1(5), I(9)); + R1(c, d, a, b, g, h, e, f, K[6], W1(6), I(10)); + R1(b, c, d, a, f, g, h, e, K[7], W1(7), I(11)); + R1(a, b, c, d, e, f, g, h, K[8], W1(8), I(12)); + R1(d, a, b, c, h, e, f, g, K[9], W1(9), I(13)); + R1(c, d, a, b, g, h, e, f, K[10], W1(10), I(14)); + R1(b, c, d, a, f, g, h, e, K[11], W1(11), I(15)); + R1(a, b, c, d, e, f, g, h, K[12], W1(12), W2(16)); + R1(d, a, b, c, h, e, f, g, K[13], W1(13), W2(17)); + R1(c, d, a, b, g, h, e, f, K[14], W1(14), W2(18)); + R1(b, c, d, a, f, g, h, e, K[15], W1(15), W2(19)); + + R2(a, b, c, d, e, f, g, h, K[16], W1(16), W2(20)); + R2(d, a, b, c, h, e, f, g, K[17], W1(17), W2(21)); + R2(c, d, a, b, g, h, e, f, K[18], W1(18), W2(22)); + R2(b, c, d, a, f, g, h, e, K[19], W1(19), W2(23)); + R2(a, b, c, d, e, f, g, h, K[20], W1(20), W2(24)); + R2(d, a, b, c, h, e, f, g, K[21], W1(21), W2(25)); + R2(c, d, a, b, g, h, e, f, K[22], W1(22), W2(26)); + R2(b, c, d, a, f, g, h, e, K[23], W1(23), W2(27)); + R2(a, b, c, d, e, f, g, h, K[24], W1(24), W2(28)); + R2(d, a, b, c, h, e, f, g, K[25], W1(25), W2(29)); + R2(c, d, a, b, g, h, e, f, K[26], W1(26), W2(30)); + R2(b, c, d, a, f, g, h, e, K[27], W1(27), W2(31)); + R2(a, b, c, d, e, f, g, h, K[28], W1(28), W2(32)); + R2(d, a, b, c, h, e, f, g, K[29], W1(29), W2(33)); + R2(c, d, a, b, g, h, e, f, K[30], W1(30), W2(34)); + R2(b, c, d, a, f, g, h, e, K[31], W1(31), W2(35)); + + R2(a, b, c, d, e, f, g, h, K[32], W1(32), W2(36)); + R2(d, a, b, c, h, e, f, g, K[33], W1(33), W2(37)); + R2(c, d, a, b, g, h, e, f, K[34], W1(34), W2(38)); + R2(b, c, d, a, f, g, h, e, K[35], W1(35), W2(39)); + R2(a, b, c, d, e, f, g, h, K[36], W1(36), W2(40)); + R2(d, a, b, c, h, e, f, g, K[37], W1(37), W2(41)); + R2(c, d, a, b, g, h, e, f, K[38], W1(38), W2(42)); + R2(b, c, d, a, f, g, h, e, K[39], W1(39), W2(43)); + R2(a, b, c, d, e, f, g, h, K[40], W1(40), W2(44)); + R2(d, a, b, c, h, e, f, g, K[41], W1(41), W2(45)); + R2(c, d, a, b, g, h, e, f, K[42], W1(42), W2(46)); + R2(b, c, d, a, f, g, h, e, K[43], W1(43), W2(47)); + R2(a, b, c, d, e, f, g, h, K[44], W1(44), W2(48)); + R2(d, a, b, c, h, e, f, g, K[45], W1(45), W2(49)); + R2(c, d, a, b, g, h, e, f, K[46], W1(46), W2(50)); + R2(b, c, d, a, f, g, h, e, K[47], W1(47), W2(51)); + + R2(a, b, c, d, e, f, g, h, K[48], W1(48), W2(52)); + R2(d, a, b, c, h, e, f, g, K[49], W1(49), W2(53)); + R2(c, d, a, b, g, h, e, f, K[50], W1(50), W2(54)); + R2(b, c, d, a, f, g, h, e, K[51], W1(51), W2(55)); + R2(a, b, c, d, e, f, g, h, K[52], W1(52), W2(56)); + R2(d, a, b, c, h, e, f, g, K[53], W1(53), W2(57)); + R2(c, d, a, b, g, h, e, f, K[54], W1(54), W2(58)); + R2(b, c, d, a, f, g, h, e, K[55], W1(55), W2(59)); + R2(a, b, c, d, e, f, g, h, K[56], W1(56), W2(60)); + R2(d, a, b, c, h, e, f, g, K[57], W1(57), W2(61)); + R2(c, d, a, b, g, h, e, f, K[58], W1(58), W2(62)); + R2(b, c, d, a, f, g, h, e, K[59], W1(59), W2(63)); + R2(a, b, c, d, e, f, g, h, K[60], W1(60), W2(64)); + R2(d, a, b, c, h, e, f, g, K[61], W1(61), W2(65)); + R2(c, d, a, b, g, h, e, f, K[62], W1(62), W2(66)); + R2(b, c, d, a, f, g, h, e, K[63], W1(63), W2(67)); + + hd->h0 ^= a; + hd->h1 ^= b; + hd->h2 ^= c; + hd->h3 ^= d; + hd->h4 ^= e; + hd->h5 ^= f; + hd->h6 ^= g; + hd->h7 ^= h; + + return /*burn_stack*/ 26*4+32; +} +#undef P0 +#undef P1 +#undef R +#undef R1 +#undef R2 + +static unsigned int +transform (void *ctx, const unsigned char *data, size_t nblks) +{ + SM3_CONTEXT *hd = ctx; + unsigned int burn; + + do + { + burn = transform_blk (hd, data); + data += 64; + } + while (--nblks); + + return burn; +} + + +/* + The routine finally terminates the computation and returns the + digest. The handle is prepared for a new cycle, but adding bytes + to the handle will the destroy the returned buffer. Returns: 32 + bytes with the message the digest. */ +static void +sm3_final(void *context) +{ + SM3_CONTEXT *hd = context; + u32 t, th, msb, lsb; + byte *p; + unsigned int burn; + + _gcry_md_block_write (hd, NULL, 0); /* flush */; + + t = hd->bctx.nblocks; + if (sizeof t == sizeof hd->bctx.nblocks) + th = hd->bctx.nblocks_high; + else + th = hd->bctx.nblocks >> 32; + + /* multiply by 64 to make a byte count */ + lsb = t << 6; + msb = (th << 6) | (t >> 26); + /* add the count */ + t = lsb; + if ((lsb += hd->bctx.count) < t) + msb++; + /* multiply by 8 to make a bit count */ + t = lsb; + lsb <<= 3; + msb <<= 3; + msb |= t >> 29; + + if (hd->bctx.count < 56) + { /* enough room */ + hd->bctx.buf[hd->bctx.count++] = 0x80; /* pad */ + while (hd->bctx.count < 56) + hd->bctx.buf[hd->bctx.count++] = 0; /* pad */ + } + else + { /* need one extra block */ + hd->bctx.buf[hd->bctx.count++] = 0x80; /* pad character */ + while (hd->bctx.count < 64) + hd->bctx.buf[hd->bctx.count++] = 0; + _gcry_md_block_write (hd, NULL, 0); /* flush */; + memset (hd->bctx.buf, 0, 56 ); /* fill next block with zeroes */ + } + /* append the 64 bit count */ + buf_put_be32(hd->bctx.buf + 56, msb); + buf_put_be32(hd->bctx.buf + 60, lsb); + burn = transform (hd, hd->bctx.buf, 1); + _gcry_burn_stack (burn); + + p = hd->bctx.buf; +#define X(a) do { buf_put_be32(p, hd->h##a); p += 4; } while(0) + X(0); + X(1); + X(2); + X(3); + X(4); + X(5); + X(6); + X(7); +#undef X +} + +static byte * +sm3_read (void *context) +{ + SM3_CONTEXT *hd = context; + + return hd->bctx.buf; +} + + +/* Shortcut functions which puts the hash value of the supplied buffer + * into outbuf which must have a size of 32 bytes. */ +void +_gcry_sm3_hash_buffer (void *outbuf, const void *buffer, size_t length) +{ + SM3_CONTEXT hd; + + sm3_init (&hd, 0); + _gcry_md_block_write (&hd, buffer, length); + sm3_final (&hd); + memcpy (outbuf, hd.bctx.buf, 32); +} + + +/* Variant of the above shortcut function using multiple buffers. */ +void +_gcry_sm3_hash_buffers (void *outbuf, const gcry_buffer_t *iov, int iovcnt) +{ + SM3_CONTEXT hd; + + sm3_init (&hd, 0); + for (;iovcnt > 0; iov++, iovcnt--) + _gcry_md_block_write (&hd, + (const char*)iov[0].data + iov[0].off, iov[0].len); + sm3_final (&hd); + memcpy (outbuf, hd.bctx.buf, 32); +} + + + +/* + Self-test section. + */ + + +static gpg_err_code_t +selftests_sm3 (int extended, selftest_report_func_t report) +{ + const char *what; + const char *errtxt; + + what = "short string (spec example 1)"; + errtxt = _gcry_hash_selftest_check_one + (GCRY_MD_SM3, 0, + "abc", 3, + "\x66\xc7\xf0\xf4\x62\xee\xed\xd9\xd1\xf2\xd4\x6b\xdc\x10\xe4\xe2" + "\x41\x67\xc4\x87\x5c\xf2\xf7\xa2\x29\x7d\xa0\x2b\x8f\x4b\xa8\xe0", 32); + if (errtxt) + goto failed; + + if (extended) + { + what = "long string (spec example 2)"; + errtxt = _gcry_hash_selftest_check_one + (GCRY_MD_SM3, 0, + "abcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcd", 64, + "\xde\xbe\x9f\xf9\x22\x75\xb8\xa1\x38\x60\x48\x89\xc1\x8e\x5a\x4d" + "\x6f\xdb\x70\xe5\x38\x7e\x57\x65\x29\x3d\xcb\xa3\x9c\x0c\x57\x32", + 32); + if (errtxt) + goto failed; + + what = "long string"; + errtxt = _gcry_hash_selftest_check_one + (GCRY_MD_SM3, 0, + "abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq", 56, + "\x63\x9b\x6c\xc5\xe6\x4d\x9e\x37\xa3\x90\xb1\x92\xdf\x4f\xa1\xea" + "\x07\x20\xab\x74\x7f\xf6\x92\xb9\xf3\x8c\x4e\x66\xad\x7b\x8c\x05", + 32); + if (errtxt) + goto failed; + + what = "one million \"a\""; + errtxt = _gcry_hash_selftest_check_one + (GCRY_MD_SM3, 1, + NULL, 0, + "\xc8\xaa\xf8\x94\x29\x55\x40\x29\xe2\x31\x94\x1a\x2a\xcc\x0a\xd6" + "\x1f\xf2\xa5\xac\xd8\xfa\xdd\x25\x84\x7a\x3a\x73\x2b\x3b\x02\xc3", + 32); + if (errtxt) + goto failed; + } + + return 0; /* Succeeded. */ + + failed: + if (report) + report ("digest", GCRY_MD_SM3, what, errtxt); + return GPG_ERR_SELFTEST_FAILED; +} + + +/* Run a full self-test for ALGO and return 0 on success. */ +static gpg_err_code_t +run_selftests (int algo, int extended, selftest_report_func_t report) +{ + gpg_err_code_t ec; + + switch (algo) + { + case GCRY_MD_SM3: + ec = selftests_sm3 (extended, report); + break; + default: + ec = GPG_ERR_DIGEST_ALGO; + break; + + } + return ec; +} + +gcry_md_spec_t _gcry_digest_spec_sm3 = + { + GCRY_MD_SM3, {0, 1}, + "SM3", NULL, 0, NULL, 32, + sm3_init, _gcry_md_block_write, sm3_final, sm3_read, NULL, + sizeof (SM3_CONTEXT), + run_selftests + }; diff --git a/configure.ac b/configure.ac index a2ac9ce..86035a4 100644 --- a/configure.ac +++ b/configure.ac @@ -198,6 +198,7 @@ enabled_pubkey_ciphers="" # Definitions for message digests. available_digests="crc gostr3411-94 md2 md4 md5 rmd160 sha1 sha256 sha512" available_digests="$available_digests sha3 tiger whirlpool stribog blake2" +available_digests="$available_digests sm3" enabled_digests="" # Definitions for kdfs (optional ones) @@ -2456,6 +2457,12 @@ case "${host}" in ;; esac +LIST_MEMBER(sm3, $enabled_digests) +if test "$found" = "1" ; then + GCRYPT_DIGESTS="$GCRYPT_DIGESTS sm3.lo" + AC_DEFINE(USE_SM3, 1, [Defined if this module should be included]) +fi + LIST_MEMBER(scrypt, $enabled_kdfs) if test "$found" = "1" ; then GCRYPT_KDFS="$GCRYPT_KDFS scrypt.lo" diff --git a/src/cipher.h b/src/cipher.h index f2acb55..a6f257d 100644 --- a/src/cipher.h +++ b/src/cipher.h @@ -133,6 +133,12 @@ void _gcry_sha512_hash_buffer (void *outbuf, void _gcry_sha512_hash_buffers (void *outbuf, const gcry_buffer_t *iov, int iovcnt); +/*-- sm3.c --*/ +void _gcry_sm3_hash_buffer (void *outbuf, + const void *buffer, size_t length); +void _gcry_sm3_hash_buffers (void *outbuf, + const gcry_buffer_t *iov, int iovcnt); + /*-- blake2.c --*/ gcry_err_code_t _gcry_blake2_init_with_key(void *ctx, unsigned int flags, const unsigned char *key, @@ -326,6 +332,7 @@ extern gcry_md_spec_t _gcry_digest_spec_blake2s_256; extern gcry_md_spec_t _gcry_digest_spec_blake2s_224; extern gcry_md_spec_t _gcry_digest_spec_blake2s_160; extern gcry_md_spec_t _gcry_digest_spec_blake2s_128; +extern gcry_md_spec_t _gcry_digest_spec_sm3; /* Declarations for the pubkey cipher specifications. */ extern gcry_pk_spec_t _gcry_pubkey_spec_rsa; diff --git a/tests/basic.c b/tests/basic.c index 89b7917..c2b4208 100644 --- a/tests/basic.c +++ b/tests/basic.c @@ -7770,6 +7770,31 @@ check_digests (void) "\x0e\xfc\x29\xde" }, { GCRY_MD_BLAKE2S_128, "?", "\x70\x0b\x8a\x71\x1d\x34\x0a\xf0\x13\x93\x19\x93\x5e\xd7\x54\x9c" }, + + { GCRY_MD_SM3, "abc", + "\x66\xc7\xf0\xf4\x62\xee\xed\xd9\xd1\xf2\xd4\x6b\xdc\x10\xe4\xe2" + "\x41\x67\xc4\x87\x5c\xf2\xf7\xa2\x29\x7d\xa0\x2b\x8f\x4b\xa8\xe0" }, + { GCRY_MD_SM3, + "abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq", + "\x63\x9b\x6c\xc5\xe6\x4d\x9e\x37\xa3\x90\xb1\x92\xdf\x4f\xa1\xea" + "\x07\x20\xab\x74\x7f\xf6\x92\xb9\xf3\x8c\x4e\x66\xad\x7b\x8c\x05" }, + { GCRY_MD_SM3, "!", + "\xc8\xaa\xf8\x94\x29\x55\x40\x29\xe2\x31\x94\x1a\x2a\xcc\x0a\xd6" + "\x1f\xf2\xa5\xac\xd8\xfa\xdd\x25\x84\x7a\x3a\x73\x2b\x3b\x02\xc3" }, + { GCRY_MD_SM3, "?", + "\x3a\x3f\x53\xfc\x96\xc2\xde\xb2\xd9\x12\x3a\x1b\xd8\x47\x71\x28" + "\xbc\x5d\x5e\x94\xea\x08\x86\x3d\xfb\xe4\x00\x5a\xd9\xed\x79\x26" }, + { GCRY_MD_SM3, + "Libgcrypt is free software; you can redistribute it and/or modif" + "y it under the terms of the GNU Lesser general Public License as" + " published by the Free Software Foundation; either version 2.1 o" + "f the License, or (at your option) any later version.\nLibgcrypt" + " is distributed in the hope that it will be useful, but WITHOUT " + "ANY WARRANTY; without even the implied warranty of MERCHANTABILI" + "TY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser Gene" + "ral Public License for more details.", + "\x8b\x91\x3f\x0e\x85\xae\x43\x25\x6d\x28\x38\x6c\x09\x5c\xc7\x72" + "\xcc\x2e\x78\x89\x7e\x2e\x4e\x5a\x3d\xf6\x55\xfe\x87\xbe\xa6\xbc" }, { 0 } }; gcry_error_t err; diff --git a/tests/hashtest-256g.in b/tests/hashtest-256g.in index 92b1c1b..a52b869 100755 --- a/tests/hashtest-256g.in +++ b/tests/hashtest-256g.in @@ -1,6 +1,6 @@ #!/bin/sh -algos="SHA1 SHA256 SHA512" +algos="SHA1 SHA256 SHA512 SM3" test "@RUN_LARGE_DATA_TESTS@" = yes || exit 77 echo " now running 256 GiB tests for $algos - this takes looong" diff --git a/tests/hashtest.c b/tests/hashtest.c index 2ecbc1f..3394594 100644 --- a/tests/hashtest.c +++ b/tests/hashtest.c @@ -102,6 +102,17 @@ static struct { "0c91b91665ceaf7af5102e0ed31aa4f050668ab3c57b1f4763946d567efe66b3" "ab9a2016cf238dee5b44eae9f0cdfbf7b7a6eb1e759986273243dc35894706b6" }, + { GCRY_MD_SM3, 256, -64, + "4ceb893abeb43965d4cac7626da9a4be895585b5b2f16f302626801308b1c02a" }, + { GCRY_MD_SM3, 256, -1, + "825f01e4f2b6084136abc356fa1b343a9411d844a4dc1474293aad817cd2a48f" }, + { GCRY_MD_SM3, 256, +0, + "d948a4025ac3ea0aa8989f43203411bd22ad17eaa5fd92ebdf9cabf869f1ba1b" }, + { GCRY_MD_SM3, 256, +1, + "4f6d0e260299c1f286ef1dbb4638a0770979f266b6c007c55410ee6849cba2a8" }, + { GCRY_MD_SM3, 256, +64, + "ed34869dbadd62e3bec1f511004d7bbfc9cafa965477cc48843b248293bbe867" }, + { 0 } }; commit 5b31e22d9fc542bdccb1586ef2c83d9794a731d3 Author: NIIBE Yutaka Date: Tue Oct 24 15:43:41 2017 +0900 Add new constant GCRY_MD_SM3 for crypto hash SM3. * src/gcrypt.h.in (GCRY_MD_SM3): New. Signed-off-by: NIIBE Yutaka diff --git a/src/gcrypt.h.in b/src/gcrypt.h.in index 76d9b1d..b55657f 100644 --- a/src/gcrypt.h.in +++ b/src/gcrypt.h.in @@ -1244,7 +1244,8 @@ enum gcry_md_algos GCRY_MD_BLAKE2S_256 = 322, GCRY_MD_BLAKE2S_224 = 323, GCRY_MD_BLAKE2S_160 = 324, - GCRY_MD_BLAKE2S_128 = 325 + GCRY_MD_BLAKE2S_128 = 325, + GCRY_MD_SM3 = 326, }; /* Flags used with the open function. */ ----------------------------------------------------------------------- Summary of changes: cipher/Makefile.am | 1 + cipher/md.c | 3 + cipher/pubkey-util.c | 1 + cipher/sm3.c | 454 +++++++++++++++++++++++++++++++++++++++++++++++++ configure.ac | 7 + src/cipher.h | 7 + src/gcrypt.h.in | 3 +- tests/basic.c | 25 +++ tests/hashtest-256g.in | 2 +- tests/hashtest.c | 11 ++ 10 files changed, 512 insertions(+), 2 deletions(-) create mode 100644 cipher/sm3.c 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 Tue Oct 24 09:19:45 2017 From: cvs at cvs.gnupg.org (by Jia Zhang) Date: Tue, 24 Oct 2017 09:19:45 +0200 Subject: [git] GCRYPT - branch, master, updated. libgcrypt-1.8.1-18-g4423bf3 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 discards aa944910979b52ad4ca2b317b9d551d8b4d48df2 (commit) via 4423bf3cc4432b9bfe801ff74cb05e6f0dd3eccd (commit) This update added new revisions after undoing existing revisions. That is to say, the old revision is not a strict subset of the new revision. This situation occurs when you --force push a change and generate a repository containing something like this: * -- * -- B -- O -- O -- O (aa944910979b52ad4ca2b317b9d551d8b4d48df2) \ N -- N -- N (4423bf3cc4432b9bfe801ff74cb05e6f0dd3eccd) When this happens we assume that you've already had alert emails for all of the O revisions, and so we here report only the revisions in the N branch from the common base, B. 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 4423bf3cc4432b9bfe801ff74cb05e6f0dd3eccd Author: Jia Zhang Date: Tue Oct 24 15:55:12 2017 +0900 Add crypto hash SM3. * configure.ac (available_digests): Add sm3. * src/cipher.h: Add declarations for SM3. * cipher/Makefile.am (EXTRA_libcipher_la_SOURCES): Add sm3.c. * cipher/md.c [USE_SM3] (digest_list): Add _gcry_digest_spec_sm3. * cipher/pubkey-util.c (hashnames): Add "sm3". * cipher/sm3.c: New. * tests/basic.c (check_digests): Add test vectors for SM3. * tests/hashtest-256g.in (algos): Add SM3. * tests/hashtest.c (testvectors): Add for SM3. -- GnuPG-bug-id: 3454 Signed-off-by: Jia Zhang diff --git a/cipher/Makefile.am b/cipher/Makefile.am index ee99262..bbfab4c 100644 --- a/cipher/Makefile.am +++ b/cipher/Makefile.am @@ -96,6 +96,7 @@ sha256.c sha256-ssse3-amd64.S sha256-avx-amd64.S sha256-avx2-bmi2-amd64.S \ sha256-armv8-aarch32-ce.S sha256-armv8-aarch64-ce.S \ sha512.c sha512-ssse3-amd64.S sha512-avx-amd64.S sha512-avx2-bmi2-amd64.S \ sha512-armv7-neon.S sha512-arm.S \ +sm3.c \ keccak.c keccak_permute_32.h keccak_permute_64.h keccak-armv7-neon.S \ stribog.c \ tiger.c \ diff --git a/cipher/md.c b/cipher/md.c index c1f585f..94f1b5d 100644 --- a/cipher/md.c +++ b/cipher/md.c @@ -95,6 +95,9 @@ static gcry_md_spec_t *digest_list[] = &_gcry_digest_spec_blake2s_160, &_gcry_digest_spec_blake2s_128, #endif +#if USE_SM3 + &_gcry_digest_spec_sm3, +#endif NULL }; diff --git a/cipher/pubkey-util.c b/cipher/pubkey-util.c index c40ef97..ae0e1c4 100644 --- a/cipher/pubkey-util.c +++ b/cipher/pubkey-util.c @@ -221,6 +221,7 @@ get_hash_algo (const char *s, size_t n) { "sha3-256", GCRY_MD_SHA3_256 }, { "sha3-384", GCRY_MD_SHA3_384 }, { "sha3-512", GCRY_MD_SHA3_512 }, + { "sm3", GCRY_MD_SM3 }, { NULL, 0 } }; int algo; diff --git a/cipher/sm3.c b/cipher/sm3.c new file mode 100644 index 0000000..f0c574a --- /dev/null +++ b/cipher/sm3.c @@ -0,0 +1,454 @@ +/* sm3.c - SM3 hash function + * Copyright (C) 2017 Jia Zhang + * + * This file is part of Libgcrypt. + * + * Libgcrypt is free software; you can redistribute it and/or modify + * it under the terms of the GNU Lesser General Public License as + * published by the Free Software Foundation; either version 2.1 of + * the License, or (at your option) any later version. + * + * Libgcrypt is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this program; if not, see . + */ + + +/* Test vectors: + + "abc" + SM3: 66c7f0f4 62eeedd9 d1f2d46b dc10e4e2 4167c487 5cf2f7a2 297da02b 8f4ba8e0 + + "abcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcd" + SM3: debe9ff9 2275b8a1 38604889 c18e5a4d 6fdb70e5 387e5765 293dcba3 9c0c5732 + + "abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq" + SM3: 639b6cc5 e64d9e37 a390b192 df4fa1ea 0720ab74 7ff692b9 f38c4e66 ad7b8c05 + + "a" one million times + SM3: c8aaf894 29554029 e231941a 2acc0ad6 1ff2a5ac d8fadd25 847a3a73 2b3b02c3 + + */ + + +#include +#include +#include +#include + +#include "g10lib.h" +#include "bithelp.h" +#include "bufhelp.h" +#include "cipher.h" +#include "hash-common.h" + + +typedef struct { + gcry_md_block_ctx_t bctx; + u32 h0,h1,h2,h3,h4,h5,h6,h7; +} SM3_CONTEXT; + + +static unsigned int +transform (void *c, const unsigned char *data, size_t nblks); + + +static void +sm3_init (void *context, unsigned int flags) +{ + SM3_CONTEXT *hd = context; + unsigned int features = _gcry_get_hw_features (); + + (void)flags; + + hd->h0 = 0x7380166f; + hd->h1 = 0x4914b2b9; + hd->h2 = 0x172442d7; + hd->h3 = 0xda8a0600; + hd->h4 = 0xa96f30bc; + hd->h5 = 0x163138aa; + hd->h6 = 0xe38dee4d; + hd->h7 = 0xb0fb0e4e; + + hd->bctx.nblocks = 0; + hd->bctx.nblocks_high = 0; + hd->bctx.count = 0; + hd->bctx.blocksize = 64; + hd->bctx.bwrite = transform; + + (void)features; +} + + +/* + Transform the message X which consists of 16 32-bit-words. See + GM/T 004-2012 for details. */ +#define R(i,a,b,c,d,e,f,g,h,t,w1,w2) do \ + { \ + ss1 = rol ((rol ((a), 12) + (e) + (t)), 7); \ + ss2 = ss1 ^ rol ((a), 12); \ + d += FF##i(a,b,c) + ss2 + ((w1) ^ (w2)); \ + h += GG##i(e,f,g) + ss1 + (w1); \ + b = rol ((b), 9); \ + f = rol ((f), 19); \ + h = P0 ((h)); \ + } while (0) + +#define R1(a,b,c,d,e,f,g,h,t,w1,w2) R(1,a,b,c,d,e,f,g,h,t,w1,w2) +#define R2(a,b,c,d,e,f,g,h,t,w1,w2) R(2,a,b,c,d,e,f,g,h,t,w1,w2) + +#define FF1(x, y, z) (x ^ y ^ z) + +#define FF2(x, y, z) ((x & y) | (x & z) | (y & z)) + +#define GG1(x, y, z) (x ^ y ^ z) + +#define GG2(x, y, z) ((x & y) | ( ~x & z)) + +/* Message expansion */ +#define P0(x) ((x) ^ rol ((x), 9) ^ rol ((x), 17)) +#define P1(x) ((x) ^ rol ((x), 15) ^ rol ((x), 23)) +#define I(i) ( w[i] = buf_get_be32(data + i * 4) ) +#define W1(i) ( w[i&0x0f] ) +#define W2(i) ( w[i&0x0f] = P1(w[i &0x0f] \ + ^ w[(i-9)&0x0f] \ + ^ rol (w[(i-3)&0x0f], 15)) \ + ^ rol (w[(i-13)&0x0f], 7) \ + ^ w[(i-6)&0x0f] ) + +static unsigned int +transform_blk (void *ctx, const unsigned char *data) +{ + SM3_CONTEXT *hd = ctx; + static const u32 K[64] = { + 0x79cc4519, 0xf3988a32, 0xe7311465, 0xce6228cb, + 0x9cc45197, 0x3988a32f, 0x7311465e, 0xe6228cbc, + 0xcc451979, 0x988a32f3, 0x311465e7, 0x6228cbce, + 0xc451979c, 0x88a32f39, 0x11465e73, 0x228cbce6, + 0x9d8a7a87, 0x3b14f50f, 0x7629ea1e, 0xec53d43c, + 0xd8a7a879, 0xb14f50f3, 0x629ea1e7, 0xc53d43ce, + 0x8a7a879d, 0x14f50f3b, 0x29ea1e76, 0x53d43cec, + 0xa7a879d8, 0x4f50f3b1, 0x9ea1e762, 0x3d43cec5, + 0x7a879d8a, 0xf50f3b14, 0xea1e7629, 0xd43cec53, + 0xa879d8a7, 0x50f3b14f, 0xa1e7629e, 0x43cec53d, + 0x879d8a7a, 0x0f3b14f5, 0x1e7629ea, 0x3cec53d4, + 0x79d8a7a8, 0xf3b14f50, 0xe7629ea1, 0xcec53d43, + 0x9d8a7a87, 0x3b14f50f, 0x7629ea1e, 0xec53d43c, + 0xd8a7a879, 0xb14f50f3, 0x629ea1e7, 0xc53d43ce, + 0x8a7a879d, 0x14f50f3b, 0x29ea1e76, 0x53d43cec, + 0xa7a879d8, 0x4f50f3b1, 0x9ea1e762, 0x3d43cec5 + }; + + u32 a,b,c,d,e,f,g,h,ss1,ss2; + u32 w[16]; + + a = hd->h0; + b = hd->h1; + c = hd->h2; + d = hd->h3; + e = hd->h4; + f = hd->h5; + g = hd->h6; + h = hd->h7; + + R1(a, b, c, d, e, f, g, h, K[0], I(0), I(4)); + R1(d, a, b, c, h, e, f, g, K[1], I(1), I(5)); + R1(c, d, a, b, g, h, e, f, K[2], I(2), I(6)); + R1(b, c, d, a, f, g, h, e, K[3], I(3), I(7)); + R1(a, b, c, d, e, f, g, h, K[4], W1(4), I(8)); + R1(d, a, b, c, h, e, f, g, K[5], W1(5), I(9)); + R1(c, d, a, b, g, h, e, f, K[6], W1(6), I(10)); + R1(b, c, d, a, f, g, h, e, K[7], W1(7), I(11)); + R1(a, b, c, d, e, f, g, h, K[8], W1(8), I(12)); + R1(d, a, b, c, h, e, f, g, K[9], W1(9), I(13)); + R1(c, d, a, b, g, h, e, f, K[10], W1(10), I(14)); + R1(b, c, d, a, f, g, h, e, K[11], W1(11), I(15)); + R1(a, b, c, d, e, f, g, h, K[12], W1(12), W2(16)); + R1(d, a, b, c, h, e, f, g, K[13], W1(13), W2(17)); + R1(c, d, a, b, g, h, e, f, K[14], W1(14), W2(18)); + R1(b, c, d, a, f, g, h, e, K[15], W1(15), W2(19)); + + R2(a, b, c, d, e, f, g, h, K[16], W1(16), W2(20)); + R2(d, a, b, c, h, e, f, g, K[17], W1(17), W2(21)); + R2(c, d, a, b, g, h, e, f, K[18], W1(18), W2(22)); + R2(b, c, d, a, f, g, h, e, K[19], W1(19), W2(23)); + R2(a, b, c, d, e, f, g, h, K[20], W1(20), W2(24)); + R2(d, a, b, c, h, e, f, g, K[21], W1(21), W2(25)); + R2(c, d, a, b, g, h, e, f, K[22], W1(22), W2(26)); + R2(b, c, d, a, f, g, h, e, K[23], W1(23), W2(27)); + R2(a, b, c, d, e, f, g, h, K[24], W1(24), W2(28)); + R2(d, a, b, c, h, e, f, g, K[25], W1(25), W2(29)); + R2(c, d, a, b, g, h, e, f, K[26], W1(26), W2(30)); + R2(b, c, d, a, f, g, h, e, K[27], W1(27), W2(31)); + R2(a, b, c, d, e, f, g, h, K[28], W1(28), W2(32)); + R2(d, a, b, c, h, e, f, g, K[29], W1(29), W2(33)); + R2(c, d, a, b, g, h, e, f, K[30], W1(30), W2(34)); + R2(b, c, d, a, f, g, h, e, K[31], W1(31), W2(35)); + + R2(a, b, c, d, e, f, g, h, K[32], W1(32), W2(36)); + R2(d, a, b, c, h, e, f, g, K[33], W1(33), W2(37)); + R2(c, d, a, b, g, h, e, f, K[34], W1(34), W2(38)); + R2(b, c, d, a, f, g, h, e, K[35], W1(35), W2(39)); + R2(a, b, c, d, e, f, g, h, K[36], W1(36), W2(40)); + R2(d, a, b, c, h, e, f, g, K[37], W1(37), W2(41)); + R2(c, d, a, b, g, h, e, f, K[38], W1(38), W2(42)); + R2(b, c, d, a, f, g, h, e, K[39], W1(39), W2(43)); + R2(a, b, c, d, e, f, g, h, K[40], W1(40), W2(44)); + R2(d, a, b, c, h, e, f, g, K[41], W1(41), W2(45)); + R2(c, d, a, b, g, h, e, f, K[42], W1(42), W2(46)); + R2(b, c, d, a, f, g, h, e, K[43], W1(43), W2(47)); + R2(a, b, c, d, e, f, g, h, K[44], W1(44), W2(48)); + R2(d, a, b, c, h, e, f, g, K[45], W1(45), W2(49)); + R2(c, d, a, b, g, h, e, f, K[46], W1(46), W2(50)); + R2(b, c, d, a, f, g, h, e, K[47], W1(47), W2(51)); + + R2(a, b, c, d, e, f, g, h, K[48], W1(48), W2(52)); + R2(d, a, b, c, h, e, f, g, K[49], W1(49), W2(53)); + R2(c, d, a, b, g, h, e, f, K[50], W1(50), W2(54)); + R2(b, c, d, a, f, g, h, e, K[51], W1(51), W2(55)); + R2(a, b, c, d, e, f, g, h, K[52], W1(52), W2(56)); + R2(d, a, b, c, h, e, f, g, K[53], W1(53), W2(57)); + R2(c, d, a, b, g, h, e, f, K[54], W1(54), W2(58)); + R2(b, c, d, a, f, g, h, e, K[55], W1(55), W2(59)); + R2(a, b, c, d, e, f, g, h, K[56], W1(56), W2(60)); + R2(d, a, b, c, h, e, f, g, K[57], W1(57), W2(61)); + R2(c, d, a, b, g, h, e, f, K[58], W1(58), W2(62)); + R2(b, c, d, a, f, g, h, e, K[59], W1(59), W2(63)); + R2(a, b, c, d, e, f, g, h, K[60], W1(60), W2(64)); + R2(d, a, b, c, h, e, f, g, K[61], W1(61), W2(65)); + R2(c, d, a, b, g, h, e, f, K[62], W1(62), W2(66)); + R2(b, c, d, a, f, g, h, e, K[63], W1(63), W2(67)); + + hd->h0 ^= a; + hd->h1 ^= b; + hd->h2 ^= c; + hd->h3 ^= d; + hd->h4 ^= e; + hd->h5 ^= f; + hd->h6 ^= g; + hd->h7 ^= h; + + return /*burn_stack*/ 26*4+32; +} +#undef P0 +#undef P1 +#undef R +#undef R1 +#undef R2 + +static unsigned int +transform (void *ctx, const unsigned char *data, size_t nblks) +{ + SM3_CONTEXT *hd = ctx; + unsigned int burn; + + do + { + burn = transform_blk (hd, data); + data += 64; + } + while (--nblks); + + return burn; +} + + +/* + The routine finally terminates the computation and returns the + digest. The handle is prepared for a new cycle, but adding bytes + to the handle will the destroy the returned buffer. Returns: 32 + bytes with the message the digest. */ +static void +sm3_final(void *context) +{ + SM3_CONTEXT *hd = context; + u32 t, th, msb, lsb; + byte *p; + unsigned int burn; + + _gcry_md_block_write (hd, NULL, 0); /* flush */; + + t = hd->bctx.nblocks; + if (sizeof t == sizeof hd->bctx.nblocks) + th = hd->bctx.nblocks_high; + else + th = hd->bctx.nblocks >> 32; + + /* multiply by 64 to make a byte count */ + lsb = t << 6; + msb = (th << 6) | (t >> 26); + /* add the count */ + t = lsb; + if ((lsb += hd->bctx.count) < t) + msb++; + /* multiply by 8 to make a bit count */ + t = lsb; + lsb <<= 3; + msb <<= 3; + msb |= t >> 29; + + if (hd->bctx.count < 56) + { /* enough room */ + hd->bctx.buf[hd->bctx.count++] = 0x80; /* pad */ + while (hd->bctx.count < 56) + hd->bctx.buf[hd->bctx.count++] = 0; /* pad */ + } + else + { /* need one extra block */ + hd->bctx.buf[hd->bctx.count++] = 0x80; /* pad character */ + while (hd->bctx.count < 64) + hd->bctx.buf[hd->bctx.count++] = 0; + _gcry_md_block_write (hd, NULL, 0); /* flush */; + memset (hd->bctx.buf, 0, 56 ); /* fill next block with zeroes */ + } + /* append the 64 bit count */ + buf_put_be32(hd->bctx.buf + 56, msb); + buf_put_be32(hd->bctx.buf + 60, lsb); + burn = transform (hd, hd->bctx.buf, 1); + _gcry_burn_stack (burn); + + p = hd->bctx.buf; +#define X(a) do { buf_put_be32(p, hd->h##a); p += 4; } while(0) + X(0); + X(1); + X(2); + X(3); + X(4); + X(5); + X(6); + X(7); +#undef X +} + +static byte * +sm3_read (void *context) +{ + SM3_CONTEXT *hd = context; + + return hd->bctx.buf; +} + + +/* Shortcut functions which puts the hash value of the supplied buffer + * into outbuf which must have a size of 32 bytes. */ +void +_gcry_sm3_hash_buffer (void *outbuf, const void *buffer, size_t length) +{ + SM3_CONTEXT hd; + + sm3_init (&hd, 0); + _gcry_md_block_write (&hd, buffer, length); + sm3_final (&hd); + memcpy (outbuf, hd.bctx.buf, 32); +} + + +/* Variant of the above shortcut function using multiple buffers. */ +void +_gcry_sm3_hash_buffers (void *outbuf, const gcry_buffer_t *iov, int iovcnt) +{ + SM3_CONTEXT hd; + + sm3_init (&hd, 0); + for (;iovcnt > 0; iov++, iovcnt--) + _gcry_md_block_write (&hd, + (const char*)iov[0].data + iov[0].off, iov[0].len); + sm3_final (&hd); + memcpy (outbuf, hd.bctx.buf, 32); +} + + + +/* + Self-test section. + */ + + +static gpg_err_code_t +selftests_sm3 (int extended, selftest_report_func_t report) +{ + const char *what; + const char *errtxt; + + what = "short string (spec example 1)"; + errtxt = _gcry_hash_selftest_check_one + (GCRY_MD_SM3, 0, + "abc", 3, + "\x66\xc7\xf0\xf4\x62\xee\xed\xd9\xd1\xf2\xd4\x6b\xdc\x10\xe4\xe2" + "\x41\x67\xc4\x87\x5c\xf2\xf7\xa2\x29\x7d\xa0\x2b\x8f\x4b\xa8\xe0", 32); + if (errtxt) + goto failed; + + if (extended) + { + what = "long string (spec example 2)"; + errtxt = _gcry_hash_selftest_check_one + (GCRY_MD_SM3, 0, + "abcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcd", 64, + "\xde\xbe\x9f\xf9\x22\x75\xb8\xa1\x38\x60\x48\x89\xc1\x8e\x5a\x4d" + "\x6f\xdb\x70\xe5\x38\x7e\x57\x65\x29\x3d\xcb\xa3\x9c\x0c\x57\x32", + 32); + if (errtxt) + goto failed; + + what = "long string"; + errtxt = _gcry_hash_selftest_check_one + (GCRY_MD_SM3, 0, + "abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq", 56, + "\x63\x9b\x6c\xc5\xe6\x4d\x9e\x37\xa3\x90\xb1\x92\xdf\x4f\xa1\xea" + "\x07\x20\xab\x74\x7f\xf6\x92\xb9\xf3\x8c\x4e\x66\xad\x7b\x8c\x05", + 32); + if (errtxt) + goto failed; + + what = "one million \"a\""; + errtxt = _gcry_hash_selftest_check_one + (GCRY_MD_SM3, 1, + NULL, 0, + "\xc8\xaa\xf8\x94\x29\x55\x40\x29\xe2\x31\x94\x1a\x2a\xcc\x0a\xd6" + "\x1f\xf2\xa5\xac\xd8\xfa\xdd\x25\x84\x7a\x3a\x73\x2b\x3b\x02\xc3", + 32); + if (errtxt) + goto failed; + } + + return 0; /* Succeeded. */ + + failed: + if (report) + report ("digest", GCRY_MD_SM3, what, errtxt); + return GPG_ERR_SELFTEST_FAILED; +} + + +/* Run a full self-test for ALGO and return 0 on success. */ +static gpg_err_code_t +run_selftests (int algo, int extended, selftest_report_func_t report) +{ + gpg_err_code_t ec; + + switch (algo) + { + case GCRY_MD_SM3: + ec = selftests_sm3 (extended, report); + break; + default: + ec = GPG_ERR_DIGEST_ALGO; + break; + + } + return ec; +} + +gcry_md_spec_t _gcry_digest_spec_sm3 = + { + GCRY_MD_SM3, {0, 1}, + "SM3", NULL, 0, NULL, 32, + sm3_init, _gcry_md_block_write, sm3_final, sm3_read, NULL, + sizeof (SM3_CONTEXT), + run_selftests + }; diff --git a/configure.ac b/configure.ac index a2ac9ce..86035a4 100644 --- a/configure.ac +++ b/configure.ac @@ -198,6 +198,7 @@ enabled_pubkey_ciphers="" # Definitions for message digests. available_digests="crc gostr3411-94 md2 md4 md5 rmd160 sha1 sha256 sha512" available_digests="$available_digests sha3 tiger whirlpool stribog blake2" +available_digests="$available_digests sm3" enabled_digests="" # Definitions for kdfs (optional ones) @@ -2456,6 +2457,12 @@ case "${host}" in ;; esac +LIST_MEMBER(sm3, $enabled_digests) +if test "$found" = "1" ; then + GCRYPT_DIGESTS="$GCRYPT_DIGESTS sm3.lo" + AC_DEFINE(USE_SM3, 1, [Defined if this module should be included]) +fi + LIST_MEMBER(scrypt, $enabled_kdfs) if test "$found" = "1" ; then GCRYPT_KDFS="$GCRYPT_KDFS scrypt.lo" diff --git a/src/cipher.h b/src/cipher.h index f2acb55..a6f257d 100644 --- a/src/cipher.h +++ b/src/cipher.h @@ -133,6 +133,12 @@ void _gcry_sha512_hash_buffer (void *outbuf, void _gcry_sha512_hash_buffers (void *outbuf, const gcry_buffer_t *iov, int iovcnt); +/*-- sm3.c --*/ +void _gcry_sm3_hash_buffer (void *outbuf, + const void *buffer, size_t length); +void _gcry_sm3_hash_buffers (void *outbuf, + const gcry_buffer_t *iov, int iovcnt); + /*-- blake2.c --*/ gcry_err_code_t _gcry_blake2_init_with_key(void *ctx, unsigned int flags, const unsigned char *key, @@ -326,6 +332,7 @@ extern gcry_md_spec_t _gcry_digest_spec_blake2s_256; extern gcry_md_spec_t _gcry_digest_spec_blake2s_224; extern gcry_md_spec_t _gcry_digest_spec_blake2s_160; extern gcry_md_spec_t _gcry_digest_spec_blake2s_128; +extern gcry_md_spec_t _gcry_digest_spec_sm3; /* Declarations for the pubkey cipher specifications. */ extern gcry_pk_spec_t _gcry_pubkey_spec_rsa; diff --git a/tests/basic.c b/tests/basic.c index 89b7917..c2b4208 100644 --- a/tests/basic.c +++ b/tests/basic.c @@ -7770,6 +7770,31 @@ check_digests (void) "\x0e\xfc\x29\xde" }, { GCRY_MD_BLAKE2S_128, "?", "\x70\x0b\x8a\x71\x1d\x34\x0a\xf0\x13\x93\x19\x93\x5e\xd7\x54\x9c" }, + + { GCRY_MD_SM3, "abc", + "\x66\xc7\xf0\xf4\x62\xee\xed\xd9\xd1\xf2\xd4\x6b\xdc\x10\xe4\xe2" + "\x41\x67\xc4\x87\x5c\xf2\xf7\xa2\x29\x7d\xa0\x2b\x8f\x4b\xa8\xe0" }, + { GCRY_MD_SM3, + "abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq", + "\x63\x9b\x6c\xc5\xe6\x4d\x9e\x37\xa3\x90\xb1\x92\xdf\x4f\xa1\xea" + "\x07\x20\xab\x74\x7f\xf6\x92\xb9\xf3\x8c\x4e\x66\xad\x7b\x8c\x05" }, + { GCRY_MD_SM3, "!", + "\xc8\xaa\xf8\x94\x29\x55\x40\x29\xe2\x31\x94\x1a\x2a\xcc\x0a\xd6" + "\x1f\xf2\xa5\xac\xd8\xfa\xdd\x25\x84\x7a\x3a\x73\x2b\x3b\x02\xc3" }, + { GCRY_MD_SM3, "?", + "\x3a\x3f\x53\xfc\x96\xc2\xde\xb2\xd9\x12\x3a\x1b\xd8\x47\x71\x28" + "\xbc\x5d\x5e\x94\xea\x08\x86\x3d\xfb\xe4\x00\x5a\xd9\xed\x79\x26" }, + { GCRY_MD_SM3, + "Libgcrypt is free software; you can redistribute it and/or modif" + "y it under the terms of the GNU Lesser general Public License as" + " published by the Free Software Foundation; either version 2.1 o" + "f the License, or (at your option) any later version.\nLibgcrypt" + " is distributed in the hope that it will be useful, but WITHOUT " + "ANY WARRANTY; without even the implied warranty of MERCHANTABILI" + "TY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser Gene" + "ral Public License for more details.", + "\x8b\x91\x3f\x0e\x85\xae\x43\x25\x6d\x28\x38\x6c\x09\x5c\xc7\x72" + "\xcc\x2e\x78\x89\x7e\x2e\x4e\x5a\x3d\xf6\x55\xfe\x87\xbe\xa6\xbc" }, { 0 } }; gcry_error_t err; diff --git a/tests/hashtest-256g.in b/tests/hashtest-256g.in index 92b1c1b..a52b869 100755 --- a/tests/hashtest-256g.in +++ b/tests/hashtest-256g.in @@ -1,6 +1,6 @@ #!/bin/sh -algos="SHA1 SHA256 SHA512" +algos="SHA1 SHA256 SHA512 SM3" test "@RUN_LARGE_DATA_TESTS@" = yes || exit 77 echo " now running 256 GiB tests for $algos - this takes looong" diff --git a/tests/hashtest.c b/tests/hashtest.c index 2ecbc1f..3394594 100644 --- a/tests/hashtest.c +++ b/tests/hashtest.c @@ -102,6 +102,17 @@ static struct { "0c91b91665ceaf7af5102e0ed31aa4f050668ab3c57b1f4763946d567efe66b3" "ab9a2016cf238dee5b44eae9f0cdfbf7b7a6eb1e759986273243dc35894706b6" }, + { GCRY_MD_SM3, 256, -64, + "4ceb893abeb43965d4cac7626da9a4be895585b5b2f16f302626801308b1c02a" }, + { GCRY_MD_SM3, 256, -1, + "825f01e4f2b6084136abc356fa1b343a9411d844a4dc1474293aad817cd2a48f" }, + { GCRY_MD_SM3, 256, +0, + "d948a4025ac3ea0aa8989f43203411bd22ad17eaa5fd92ebdf9cabf869f1ba1b" }, + { GCRY_MD_SM3, 256, +1, + "4f6d0e260299c1f286ef1dbb4638a0770979f266b6c007c55410ee6849cba2a8" }, + { GCRY_MD_SM3, 256, +64, + "ed34869dbadd62e3bec1f511004d7bbfc9cafa965477cc48843b248293bbe867" }, + { 0 } }; ----------------------------------------------------------------------- Summary of changes: 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 Wed Oct 25 05:06:27 2017 From: cvs at cvs.gnupg.org (by NIIBE Yutaka) Date: Wed, 25 Oct 2017 05:06:27 +0200 Subject: [git] GCRYPT - branch, master, updated. libgcrypt-1.8.1-19-g94b8436 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 94b84360ca55c407222a3eb8222d8b1816fc617f (commit) from 4423bf3cc4432b9bfe801ff74cb05e6f0dd3eccd (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 94b84360ca55c407222a3eb8222d8b1816fc617f Author: NIIBE Yutaka Date: Wed Oct 25 12:04:30 2017 +0900 Add OID information for SM3. * cipher/sm3.c (asn_sm3, oid_spec_sm3): New. (_gcry_digest_spec_sm3): Add asn_sm3, oid_spec_sm3. Signed-off-by: NIIBE Yutaka diff --git a/cipher/sm3.c b/cipher/sm3.c index f0c574a..ee5daf2 100644 --- a/cipher/sm3.c +++ b/cipher/sm3.c @@ -444,10 +444,23 @@ run_selftests (int algo, int extended, selftest_report_func_t report) return ec; } +static byte asn_sm3[] = /* Object ID is 1.2.156.10197.401 */ + { 0x30, 0x2F, 0x30, 0x0B, 0x06, 0x07, 0x2A, 0x81, + 0x1C, 0xCF, 0x55, 0x83, 0x11, 0x05, 0x00, 0x04, + 0x20 }; + +static gcry_md_oid_spec_t oid_spec_sm3[] = + { + /* China Electronics Standardization Instutute, + OID White paper (2015), Table 6 */ + { "1.2.156.10197.401" }, + { NULL }, + }; + gcry_md_spec_t _gcry_digest_spec_sm3 = { GCRY_MD_SM3, {0, 1}, - "SM3", NULL, 0, NULL, 32, + "SM3", asn_sm3, DIM (asn_sm3), oid_spec_sm3, 32, sm3_init, _gcry_md_block_write, sm3_final, sm3_read, NULL, sizeof (SM3_CONTEXT), run_selftests ----------------------------------------------------------------------- Summary of changes: cipher/sm3.c | 15 ++++++++++++++- 1 file changed, 14 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 chrisballinger at gmail.com Thu Oct 26 19:24:01 2017 From: chrisballinger at gmail.com (Chris Ballinger) Date: Thu, 26 Oct 2017 10:24:01 -0700 Subject: libgcrypt fails to compile with Xcode 9 against iOS 11 SDK In-Reply-To: <87r2ucpwo5.fsf@wheatstone.g10code.de> References:

<20171007142430.i7ehmsgu7wo4bxr5@adversary.org> <87r2ucpwo5.fsf@wheatstone.g10code.de> Message-ID: @Ben I can't use MacPorts because I am cross-compiling for iOS with my custom build scripts here: https://github.com/ChatSecure/OTRKit/tree/master/scripts Removing the system() calls (or tests entirely) is required for compilation for iOS to succeed, but I can work around this with a simple patch. However, the arm64 mach-o assembly issue is beyond my capabilities. From what I understand using non-asm versions of AES-GCM is not recommended, and we also (beyond libotr) use libgcrypt for AES-GCM functionality for OMEMO, so I'd appreciate assistance in fixing this issue from someone more knowledgable than me. Thanks! On Mon, Oct 9, 2017 at 1:12 AM, Werner Koch wrote: > On Sat, 7 Oct 2017 16:24, ben at adversary.org said: > > > (including gcrypt, gnutls, gmime and all of the gnupg libs), but with > > clang still hanging around for almost everything else. > > All GnuPG components aim to be portable over all Unices and thus the > compiler should never matter. The system(3) call in the test suite is > actually a shortcut to avoid adding a lot of other code and is not a > security problem because we don't use setuid and we control all > parameters. > > I am also sure that there is a way to keep on using system(3) because > this API is part of ISO C. > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > _______________________________________________ > 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 wk at gnupg.org Fri Oct 27 12:22:33 2017 From: wk at gnupg.org (Werner Koch) Date: Fri, 27 Oct 2017 12:22:33 +0200 Subject: libgcrypt fails to compile with Xcode 9 against iOS 11 SDK In-Reply-To: (Chris Ballinger's message of "Thu, 26 Oct 2017 10:24:01 -0700") References:

<20171007142430.i7ehmsgu7wo4bxr5@adversary.org> <87r2ucpwo5.fsf@wheatstone.g10code.de> Message-ID: <87a80c6gba.fsf@wheatstone.g10code.de> On Thu, 26 Oct 2017 19:24, chrisballinger at gmail.com said: > However, the arm64 mach-o assembly issue is beyond my capabilities. From > what I understand using non-asm versions of AES-GCM is not recommended, and --disable-asm should always work. From where did you get the recommendation not to use --disable-asm form arm64? It will be slower but I doubt that this is really an issue for a messaging application. I have a macOS box but no IOS device - can I use it to test your problem? BTW, relying on TLS for checking the authenticity of Libgcrypt et al. downlods is not a good idea. Please check gnupg/tools/getswdb.sh to see how we do it for GnuPG components: There is a signed file with the latest versions and their shaXsums. The gnupg/tools/speedo.mk Makefile uses these checksums to verify the downloads. However, directly verifying a certain tarball signature is also possible. The trusted keys are distributed with GnuPG and their fingerprints are in all release announcements. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From chrisballinger at gmail.com Fri Oct 27 19:24:06 2017 From: chrisballinger at gmail.com (Chris Ballinger) Date: Fri, 27 Oct 2017 10:24:06 -0700 Subject: libgcrypt fails to compile with Xcode 9 against iOS 11 SDK In-Reply-To: <87a80c6gba.fsf@wheatstone.g10code.de> References:

<20171007142430.i7ehmsgu7wo4bxr5@adversary.org> <87r2ucpwo5.fsf@wheatstone.g10code.de> <87a80c6gba.fsf@wheatstone.g10code.de> Message-ID: >From what I understand it's safer to use asm implementations of AES-GCM because of potential timing attacks on pure software implementations. * https://github.com/jedisct1/libsodium/issues/234#issuecomment-70028523 * https://bugzilla.mozilla.org/show_bug.cgi?id=868948#c17 I'm more concerned that the arm64 build is broken for a formerly-working target. If you have a recent macOS device you should be able to run those build scripts (using Xcode 9 command line tools) and see that the arm64 assembly does not compile for mach-o targets. As far as tarball verification, adding a sha256sum verification step to the build scripts is a good idea, thanks for pointing me in the right direction. On Fri, Oct 27, 2017 at 3:22 AM, Werner Koch wrote: > On Thu, 26 Oct 2017 19:24, chrisballinger at gmail.com said: > > > However, the arm64 mach-o assembly issue is beyond my capabilities. From > > what I understand using non-asm versions of AES-GCM is not recommended, > and > > --disable-asm should always work. From where did you get the > recommendation not to use --disable-asm form arm64? It will be slower > but I doubt that this is really an issue for a messaging application. > > I have a macOS box but no IOS device - can I use it to test your > problem? > > BTW, relying on TLS for checking the authenticity of Libgcrypt et > al. downlods is not a good idea. Please check gnupg/tools/getswdb.sh to > see how we do it for GnuPG components: There is a signed file with the > latest versions and their shaXsums. The gnupg/tools/speedo.mk Makefile > uses these checksums to verify the downloads. However, directly > verifying a certain tarball signature is also possible. The trusted > keys are distributed with GnuPG and their fingerprints are in all > release announcements. > > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > -------------- next part -------------- An HTML attachment was scrubbed... URL: