Re: Side-channel leakage in the mpz_powm_sec interface
Hubert Kario writes: > I was able to confirm that the low-level functions, like the mpn_sec_powm() > function have no timing leakage with regards to operands or result > (exactly like section 8.1 of the manual[2] states). And that's for all inputs? Nice. (I think an earlier version used a potentially leaking table lookup on the lowest few modulo bits, as the first step in computing a partial inverse. Which is probably benign in most use-cases, but still undesirable for a function claimed to be side-channel silent). > I wasn't able to do the same with regards to the mpz_powm_sec() function. > > Irrespective of how I initialised the used mpz_t objects, if the operands > don't have high order words set, the timing of the operation is different. > Thus I believe that if mpz_powm_sec() is used for RSA or Diffie-Hellman > it would be vulnerable to the Bleichenbacher or Raccoon attacks > respectively. Is the main problem the normalization of the *output* of mpz_powm_sec? For this class of attacks, my understanding is that the secret exponents are fixed (when doing repeated operations on the secret key under attack), while the modulo is public, and the base is under the control of the attacker and hence already known to them. > Did I miss the methods to ensure that the objects are not clamped, or > should > the mpz_powm_sec() interface be marked as _not_ secure for cryptographic > purposes? It's preferable to use the mpn_powm_sec. When using mpz_t, I see no reasonable to avoid leakage of the normalized size (or number of all-zero limbs at the most significant end). Regarding Nettle (which uses GMP, and is used by GnuTLS): The RSA code dates from the 1990s (it's one of the oldest algorithms in Nettle), and has seen a series of incremental improvements over the years, but aiming to not break api compatibility more than necessary. Most recently side-channel-silent "decoding" in pkcs#1 RAS decryption. The current interface is more complex than I'd like, with several variants of most private key operations, which is a bit confusing. It would be desirable to with a larger rework; it would be better to (i) use byte strings, rather than mpz_t values, for the interface to applications, and (ii) use only mpn-level GMP functions internally. And I would recommend the same approach for any other implementation of RSA on top of GMP. Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance. ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Side-channel leakage in the mpz_powm_sec interface
Hello, While I was researching CVE-2022-4304 in OpenSSL, I looked into some other implementations (specifically to see if there are constant-time implementations of modular arithmetic). I was able to confirm that the low-level functions, like the mpn_sec_powm() function have no timing leakage with regards to operands or result (exactly like section 8.1 of the manual[2] states). I wasn't able to do the same with regards to the mpz_powm_sec() function. Irrespective of how I initialised the used mpz_t objects, if the operands don't have high order words set, the timing of the operation is different. Thus I believe that if mpz_powm_sec() is used for RSA or Diffie-Hellman it would be vulnerable to the Bleichenbacher or Raccoon attacks respectively. This is despite the documentation stating that "This function is intended for cryptographic purposes, where resilience to side-channel attacks is desired."[1] I think this is likely caused by exactly the same issue as in OpenSSL: that the mpz objects are "clamped" or "normalised", where the methods make sure that the returned object doesn't use more memory than necessary to store the number. Did I miss the methods to ensure that the objects are not clamped, or should the mpz_powm_sec() interface be marked as _not_ secure for cryptographic purposes? 1 - https://gmplib.org/manual/Integer-Exponentiation#index-mpz_005fpowm_005fsec 2 - https://gmplib.org/manual/Low_002dlevel-Functions -- Regards, Hubert Kario Principal Quality Engineer, RHEL Crypto team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: [cfarm-announces] New Arm Morello SoC machine: cfarm240
On Thu, 24 Aug 2023, Torbjörn Granlund wrote: Marc Glisse writes: There is, it is called (u)intptr_t, the standard name for an integer type that can hold a pointer. Right! I only naively checked intmax_t, assuming max would mean max. :-) Hmm, for old ABIs gaining a new integer type, I understand why intmax_t cannot increase. But for a new ABI like here, it is surprising. I guess they consider (u)intptr_t as not a true integer type but just a kind of pointer through which they can track memory. That would explain why they don't like non-pointer arithmetic on that type. The failures I get in the testsuite are "Invalid address alignment." during temporary allocation, which is not too surprising. -- Marc Glisse ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: [cfarm-announces] New Arm Morello SoC machine: cfarm240
Marc Glisse writes: There is, it is called (u)intptr_t, the standard name for an integer type that can hold a pointer. Right! I only naively checked intmax_t, assuming max would mean max. :-) There seem to be a problem with arithmetic on uintptr_t, though. The compiler generates a plain "mul" instruction for multiplying two of these fat integers, which is not quite right. Admittedly, the compiler outputs an arm (no pun intended) long warning message: foo.c:7:12: warning: binary expression on capability types 'uintptr_t' (aka 'unsigned __intcap') and 'uintptr_t'; it is not clear which should be used as the source of provenance; currently provenance is inherited from the left-hand side [-Wcheri-provenance] Not sure what that means, though. But it probably means "I generate garbage code from your sources, sorry about that". -- Torbjörn Please encrypt, key id 0xC8601622 ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: [cfarm-announces] New Arm Morello SoC machine: cfarm240
On Thu, 24 Aug 2023, Torbjörn Granlund wrote: Note the size of pointers, 16 bytes. There is no integer type mathing that, so if code tries to cast a pointer through some integer type for, say, aligning it, things will break. There is, it is called (u)intptr_t, the standard name for an integer type that can hold a pointer. -- Marc Glisse ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: [cfarm-announces] New Arm Morello SoC machine: cfarm240
Marc Glisse writes: Hmm, but with that proposed patch, configure later fails with checking size of void *... 16 checking size of unsigned short... 2 checking size of unsigned... 4 checking size of unsigned long... 8 checking size of mp_limb_t... 8 configure: error: Oops, mp_limb_t is 64 bits, but the assembler code in this configuration expects 32 bits. configure --disable-assembly does allow to build the library, but then quite a few tests fail with "bus error": t-toom6h, t-toom8h, t-toom8-sqr, t-div, t-mulmod_bnm1, ..., t-sizeinbase. So more work is needed on the GMP side :-( Note the size of pointers, 16 bytes. There is no integer type mathing that, so if code tries to cast a pointer through some integer type for, say, aligning it, things will break. Apparently, this is some sort of research platform. I have no idea how hard a GMP port might be, I've given up trying to make GMP run well on Arm since it is too hard and too expensive to find hardware for 90% of the Arm cores. There are lots of "Fruit Pi" boards, but they all use a small set of processor cores (essentially A55, A72, and A73) or cost and arm (no pun intended) and a leg. But GMP at least runs on most Arm cores, as long as they follow the standard ABI. -- Torbjörn Please encrypt, key id 0xC8601622 ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: [cfarm-announces] New Arm Morello SoC machine: cfarm240
On Thu, 24 Aug 2023, Marc Glisse wrote: It seems that uname -p returns aarch64c, configfsf.guess uses that, and configfsf.sub gets confused by that, so it should be reported there. Ah, I already see at least https://lists.gnu.org/archive/html/config-patches/2023-08/msg00043.html so hopefully it will get discussed / solved there. Hmm, but with that proposed patch, configure later fails with checking size of void *... 16 checking size of unsigned short... 2 checking size of unsigned... 4 checking size of unsigned long... 8 checking size of mp_limb_t... 8 configure: error: Oops, mp_limb_t is 64 bits, but the assembler code in this configuration expects 32 bits. configure --disable-assembly does allow to build the library, but then quite a few tests fail with "bus error": t-toom6h, t-toom8h, t-toom8-sqr, t-div, t-mulmod_bnm1, ..., t-sizeinbase. So more work is needed on the GMP side :-( I think it is possible to use a more traditional ABI on this computer, but that's not interesting. -- Marc Glisse ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: [cfarm-announces] New Arm Morello SoC machine: cfarm240
It seems that uname -p returns aarch64c, configfsf.guess uses that, and configfsf.sub gets confused by that, so it should be reported there. Ah, I already see at least https://lists.gnu.org/archive/html/config-patches/2023-08/msg00043.html so hopefully it will get discussed / solved there. On Thu, 24 Aug 2023, Paul Zimmermann wrote: Hi, gmp 6.3.0 does not compile on this machine: zimmerma@cfarm240:~/gmp-6.3.0 $ ./configure checking build system type... Invalid configuration 'aarch64c-unknown-freebsd14.0': machine 'aarch64c-unknown' not recognized configure: error: /bin/sh ./config.sub aarch64c-unknown-freebsd14.0 failed Should I try a specific ABI? Paul Date: Wed, 23 Aug 2023 14:14:47 -0500 From: CFarm Annoucements via cfarm-announces Cc: CFarm Annoucements The Compile Farm project is pleased to announce the immediate availability of cfarm240, an Arm Morello SoC [1] prototype board running CheriBSD (a FreeBSD derivative). This system-on-chip research platform [2] features a custom quad-core aarch64 Neoverse N1-based CPU implementing CHERI [3] (a memory protection model), and has 32GB system memory. Disk space is limited (~200GB); be mindful of your resource usage. We are still in the process of transitioning to our new domain name and website; please SSH to cfarm240.cfarm.net. Notes: * Morello boards are the only physical implementation of this ISA; lessons learned will be carried to future Arm extensions, so binary compatibility with Morello is not guaranteed. * You will want to read about packages [4]. * If you need help with CHERI-specific problems (not Compile Farm issues), consider joining their Slack [5]. Thank you to the University of Cambridge for hosting (and developing) this machine! [1]: https://www.arm.com/architecture/cpu/morello [2]: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri-morello.html [3]: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ [4]: https://ctsrd-cheri.github.io/cheribsd-getting-started/packages/index.html [5]: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri-slack.html ___ cfarm-announces mailing list cfarm-announ...@lists.tetaneutral.net https://lists.tetaneutral.net/listinfo/cfarm-announces ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs -- Marc Glisse ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: [cfarm-announces] New Arm Morello SoC machine: cfarm240
Hi, gmp 6.3.0 does not compile on this machine: zimmerma@cfarm240:~/gmp-6.3.0 $ ./configure checking build system type... Invalid configuration 'aarch64c-unknown-freebsd14.0': machine 'aarch64c-unknown' not recognized configure: error: /bin/sh ./config.sub aarch64c-unknown-freebsd14.0 failed Should I try a specific ABI? Paul > Date: Wed, 23 Aug 2023 14:14:47 -0500 > From: CFarm Annoucements via cfarm-announces > > Cc: CFarm Annoucements > > The Compile Farm project is pleased to announce the immediate > availability of cfarm240, an Arm Morello SoC [1] prototype board > running CheriBSD (a FreeBSD derivative). > > This system-on-chip research platform [2] features a custom > quad-core aarch64 Neoverse N1-based CPU implementing CHERI [3] > (a memory protection model), and has 32GB system memory. Disk > space is limited (~200GB); be mindful of your resource usage. > > We are still in the process of transitioning to our new domain > name and website; please SSH to cfarm240.cfarm.net. > > Notes: > > * Morello boards are the only physical implementation of this > ISA; lessons learned will be carried to future Arm extensions, > so binary compatibility with Morello is not guaranteed. > > * You will want to read about packages [4]. > > * If you need help with CHERI-specific problems (not Compile > Farm issues), consider joining their Slack [5]. > > Thank you to the University of Cambridge for hosting > (and developing) this machine! > > > [1]: https://www.arm.com/architecture/cpu/morello > [2]: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri-morello.html > [3]: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ > [4]: > https://ctsrd-cheri.github.io/cheribsd-getting-started/packages/index.html > [5]: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri-slack.html > ___ > cfarm-announces mailing list > cfarm-announ...@lists.tetaneutral.net > https://lists.tetaneutral.net/listinfo/cfarm-announces > ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
