Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. GnuPG>
  3. gcrypt
gcry_mpi_invm succeeds if the inverse does not exist
gcrypt-devel at gnupg
Apr 11, 2020, 1:08 PM
Post #1 of 11 (1776 views)
Permalink
This is not in accordance with the documentation:

Function: int gcry_mpi_invm (gcry_mpi_t x, gcry_mpi_t a, gcry_mpi_t m)
Set x to the multiplicative inverse of a \bmod m. Return true if the
inverse exists.

#include <gcrypt.h>

#define CF_CHECK_EQ(expr, res) if ( (expr) != (res) ) { goto end; }

int main(void)
{
gcry_mpi_t A;
gcry_mpi_t B;
gcry_mpi_t C;
gcry_error_t err;

CF_CHECK_EQ(err = gcry_mpi_scan(&A, GCRYMPI_FMT_HEX, "3", 0, NULL), 0);
CF_CHECK_EQ(err = gcry_mpi_scan(&B, GCRYMPI_FMT_HEX, "66", 0, NULL), 0);
CF_CHECK_EQ(err = gcry_mpi_scan(&C, GCRYMPI_FMT_HEX, "1", 0, NULL), 0);
CF_CHECK_EQ(gcry_mpi_invm(C, A, B), 1);
printf("Inverse exists\n");
end:

return 0;
}
Re: gcry_mpi_invm succeeds if the inverse does not exist [ In reply to ]
gniibe at fsij
Apr 13, 2020, 11:32 PM
Post #2 of 11 (1772 views)
Permalink
Hello,

Thank you for your report with a test case. It helps a lot.

Guido Vranken wrote:
> This is not in accordance with the documentation:
>
> Function: int gcry_mpi_invm (gcry_mpi_t x, gcry_mpi_t a, gcry_mpi_t m)
> Set x to the multiplicative inverse of a \bmod m. Return true if the
> inverse exists.

Indeed. It seems that API was changed to return the result
(success/failure) in libgcrypt 1.3.2 in 2007. Before that, the API was
void (no return value). Since the initial change, it never returns
correct value.

I'll fix for 1.9.
--

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
Re: gcry_mpi_invm succeeds if the inverse does not exist [ In reply to ]
gcrypt-devel at gnupg
May 7, 2020, 3:24 PM
Post #3 of 11 (1755 views)
Permalink
I'm running my crypto library fuzzer on Google OSS-Fuzz and it keeps
finding bugs in gcry_mpi_invm.

jussi kivilinna receives these reports. Would you mind taking a look?

On Tue, Apr 14, 2020 at 8:32 AM NIIBE Yutaka <gniibe@fsij.org> wrote:

> Hello,
>
> Thank you for your report with a test case. It helps a lot.
>
> Guido Vranken wrote:
> > This is not in accordance with the documentation:
> >
> > Function: int gcry_mpi_invm (gcry_mpi_t x, gcry_mpi_t a, gcry_mpi_t m)
> > Set x to the multiplicative inverse of a \bmod m. Return true if the
> > inverse exists.
>
> Indeed. It seems that API was changed to return the result
> (success/failure) in libgcrypt 1.3.2 in 2007. Before that, the API was
> void (no return value). Since the initial change, it never returns
> correct value.
>
> I'll fix for 1.9.
> --
>
Re: gcry_mpi_invm succeeds if the inverse does not exist [ In reply to ]
jussi.kivilinna at iki
May 8, 2020, 9:16 AM
Post #4 of 11 (1755 views)
Permalink
Hello,

On 8.5.2020 1.24, Guido Vranken via Gcrypt-devel wrote:
> I'm running my crypto library fuzzer on Google OSS-Fuzz and it keeps finding bugs in gcry_mpi_invm.
>
> jussi kivilinna receives these reports. Would you mind taking a look?

I did see "Issue 21708 in oss-fuzz: cryptofuzz:cryptofuzz-openssl: ASSERT: Botan-libgcrypt-BignumCalc-(no algorithm)-difference" 2020-04-15 and follow-up discussion and that resulted bug-report to this mailing list. I have not seen any further reports from OSS-Fuzz.

If this keeps causing too much noise as repeated bug reports, cannot you disable the BigNum fuzzing of libgcrypt until this gets fixed?

-Jussi

>
> On Tue, Apr 14, 2020 at 8:32 AM NIIBE Yutaka <gniibe@fsij.org <mailto:gniibe@fsij.org>> wrote:
>
> Hello,
>
> Thank you for your report with a test case.  It helps a lot.
>
> Guido Vranken wrote:
> > This is not in accordance with the documentation:
> >
> > Function: int gcry_mpi_invm (gcry_mpi_t x, gcry_mpi_t a, gcry_mpi_t m)
> > Set x to the multiplicative inverse of a \bmod m. Return true if the
> > inverse exists.
>
> Indeed.  It seems that API was changed to return the result
> (success/failure) in libgcrypt 1.3.2 in 2007.  Before that, the API was
> void (no return value).  Since the initial change, it never returns
> correct value.
>
> I'll fix for 1.9.
> --
>
>
> _______________________________________________
> Gcrypt-devel mailing list
> Gcrypt-devel@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
>


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
Re: gcry_mpi_invm succeeds if the inverse does not exist [ In reply to ]
gcrypt-devel at gnupg
May 9, 2020, 4:14 AM
Post #5 of 11 (1755 views)
Permalink
Here is a reproducer for the bugs. OOB reads and writes on i386:

#include <gcrypt.h>

#define CF_CHECK_EQ(expr, res) if ( (expr) != (res) ) { goto end; }

int main(void)
{
gcry_mpi_t A;
gcry_mpi_t B;
gcry_mpi_t C;
gcry_error_t err;

CF_CHECK_EQ(err = gcry_mpi_scan(&A, GCRYMPI_FMT_HEX,
"2acc66c62cac3db610ce038e38e391", 0, NULL), 0);
CF_CHECK_EQ(err = gcry_mpi_scan(&B, GCRYMPI_FMT_HEX,
"4105f5daf47e2dee608c82bbc02a7e5f4f1e6b205e2d099643ad0101ebd11fd3f1182bda60f00000000",
0, NULL), 0);
CF_CHECK_EQ(err = gcry_mpi_scan(&C, GCRYMPI_FMT_HEX, "1", 0, NULL), 0);
CF_CHECK_EQ(gcry_mpi_invm(C, A, B), 1);
printf("Inverse exists\n");
end:

return 0;
}

Valgrind:

==18960== Invalid read of size 4
==18960== at 0x1875C0: mpih_invm_pow2 (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x187F38: _gcry_mpi_invm (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x10D9C4: gcry_mpi_invm (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x10CBA7: main (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== Address 0x4a512d4 is 0 bytes after a block of size 4 alloc&apos;d
==18960== at 0x483021B: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==18960== by 0x118755: _gcry_private_malloc (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x112692: do_malloc (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x112711: _gcry_malloc (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x112B50: _gcry_xmalloc (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x18E35C: _gcry_mpi_alloc_limb_space (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x18753B: mpih_invm_pow2 (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x187F38: _gcry_mpi_invm (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x10D9C4: gcry_mpi_invm (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x10CBA7: main (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==
==18960== Invalid write of size 4
==18960== at 0x1875E0: mpih_invm_pow2 (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x187F38: _gcry_mpi_invm (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x10D9C4: gcry_mpi_invm (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x10CBA7: main (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== Address 0x4a512d4 is 0 bytes after a block of size 4 alloc&apos;d
==18960== at 0x483021B: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==18960== by 0x118755: _gcry_private_malloc (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x112692: do_malloc (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x112711: _gcry_malloc (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x112B50: _gcry_xmalloc (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x18E35C: _gcry_mpi_alloc_limb_space (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x18753B: mpih_invm_pow2 (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x187F38: _gcry_mpi_invm (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x10D9C4: gcry_mpi_invm (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x10CBA7: main (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==
==18960== Invalid read of size 4
==18960== at 0x187740: mpih_invm_pow2 (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x187F38: _gcry_mpi_invm (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x10D9C4: gcry_mpi_invm (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x10CBA7: main (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== Address 0x4a51344 is 0 bytes after a block of size 4 alloc&apos;d
==18960== at 0x483021B: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==18960== by 0x118755: _gcry_private_malloc (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x112692: do_malloc (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x112711: _gcry_malloc (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x112B50: _gcry_xmalloc (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x18E35C: _gcry_mpi_alloc_limb_space (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x187646: mpih_invm_pow2 (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x187F38: _gcry_mpi_invm (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x10D9C4: gcry_mpi_invm (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x10CBA7: main (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==
==18960== Invalid write of size 4
==18960== at 0x187760: mpih_invm_pow2 (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x187F38: _gcry_mpi_invm (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x10D9C4: gcry_mpi_invm (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x10CBA7: main (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== Address 0x4a51344 is 0 bytes after a block of size 4 alloc&apos;d
==18960== at 0x483021B: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==18960== by 0x118755: _gcry_private_malloc (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x112692: do_malloc (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x112711: _gcry_malloc (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x112B50: _gcry_xmalloc (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x18E35C: _gcry_mpi_alloc_limb_space (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x187646: mpih_invm_pow2 (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x187F38: _gcry_mpi_invm (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x10D9C4: gcry_mpi_invm (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960== by 0x10CBA7: main (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)


On Fri, May 8, 2020 at 6:16 PM Jussi Kivilinna <jussi.kivilinna@iki.fi>
wrote:

> Hello,
>
> On 8.5.2020 1.24, Guido Vranken via Gcrypt-devel wrote:
> > I'm running my crypto library fuzzer on Google OSS-Fuzz and it keeps
> finding bugs in gcry_mpi_invm.
> >
> > jussi kivilinna receives these reports. Would you mind taking a look?
>
> I did see "Issue 21708 in oss-fuzz: cryptofuzz:cryptofuzz-openssl: ASSERT:
> Botan-libgcrypt-BignumCalc-(no algorithm)-difference" 2020-04-15 and
> follow-up discussion and that resulted bug-report to this mailing list. I
> have not seen any further reports from OSS-Fuzz.
>
> If this keeps causing too much noise as repeated bug reports, cannot you
> disable the BigNum fuzzing of libgcrypt until this gets fixed?
>
> -Jussi
>
> >
> > On Tue, Apr 14, 2020 at 8:32 AM NIIBE Yutaka <gniibe@fsij.org <mailto:
> gniibe@fsij.org>> wrote:
> >
> > Hello,
> >
> > Thank you for your report with a test case. It helps a lot.
> >
> > Guido Vranken wrote:
> > > This is not in accordance with the documentation:
> > >
> > > Function: int gcry_mpi_invm (gcry_mpi_t x, gcry_mpi_t a,
> gcry_mpi_t m)
> > > Set x to the multiplicative inverse of a \bmod m. Return true if
> the
> > > inverse exists.
> >
> > Indeed. It seems that API was changed to return the result
> > (success/failure) in libgcrypt 1.3.2 in 2007. Before that, the API
> was
> > void (no return value). Since the initial change, it never returns
> > correct value.
> >
> > I'll fix for 1.9.
> > --
> >
> >
> > _______________________________________________
> > Gcrypt-devel mailing list
> > Gcrypt-devel@gnupg.org
> > http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
> >
>
>
> _______________________________________________
> Gcrypt-devel mailing list
> Gcrypt-devel@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
>
Re: gcry_mpi_invm succeeds if the inverse does not exist [ In reply to ]
gniibe at fsij
May 12, 2020, 11:44 PM
Post #6 of 11 (1753 views)
Permalink
Guido Vranken via Gcrypt-devel wrote:
> Here is a reproducer for the bugs. OOB reads and writes on i386:

Thanks. It was me who embugged. It was just fixed by the commit:

69b55f87053ce2494cd4b38dc600f867bc4355be

By the way, the problem in your original report was also fixed.
Now, it should return correct value (if inverse exists or not).
--

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
Re: gcry_mpi_invm succeeds if the inverse does not exist [ In reply to ]
jussi.kivilinna at iki
May 29, 2020, 12:59 PM
Post #7 of 11 (1721 views)
Permalink
Hello,

Cryptofuzz is reporting another heap-buffer-overflow issue in
_gcry_mpi_invm. I've attached reproducer, original from Guido and
as patch applied to tests/basic.c.

Here's AddressSanitizer output from tests/basic with reproducer,
compiled with CFLAGS="-fsanitize=address -O0 -g":

$ tests/basic
=================================================================
==1665037==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000000388 at pc 0x7f36999058d0 bp 0x7ffdef3a5160 sp 0x7ffdef3a5150
READ of size 8 at 0x603000000388 thread T0
#0 0x7f36999058cf in _gcry_mpi_invm ../../mpi/mpi-inv.c:530
#1 0x7f369970a270 in gcry_mpi_invm ../../src/visibility.c:472
#2 0x5608cc442631 in test_cryptofuzz ../../tests/basic.c:13901
#3 0x5608cc442ffb in main ../../tests/basic.c:14019
#4 0x7f36994d80b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
#5 0x5608cc411f4d in _start (/home/jussi/kernel/libgcrypt/build-amd64-ubsan/tests/basic+0x5bf4d)

0x603000000388 is located 0 bytes to the right of 24-byte region [0x603000000370,0x603000000388)
allocated by thread T0 here:
#0 0x7f3699ad0bc8 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8)
#1 0x7f36997253ab in _gcry_private_malloc ../../src/stdmem.c:113
#2 0x7f36997137af in do_malloc ../../src/global.c:920
#3 0x7f369971395e in _gcry_malloc ../../src/global.c:942
#4 0x7f3699714007 in _gcry_xmalloc ../../src/global.c:1116
#5 0x7f36999142f0 in _gcry_mpi_alloc_limb_space ../../mpi/mpiutil.c:138
#6 0x7f36999057f2 in _gcry_mpi_invm ../../mpi/mpi-inv.c:523
#7 0x7f369970a270 in gcry_mpi_invm ../../src/visibility.c:472
#8 0x5608cc442631 in test_cryptofuzz ../../tests/basic.c:13901
#9 0x5608cc442ffb in main ../../tests/basic.c:14019
#10 0x7f36994d80b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)

SUMMARY: AddressSanitizer: heap-buffer-overflow ../../mpi/mpi-inv.c:530 in _gcry_mpi_invm
Shadow bytes around the buggy address:
0x0c067fff8020: 00 00 00 fa fa fa 00 00 00 fa fa fa 00 00 00 fa
0x0c067fff8030: fa fa 00 00 00 fa fa fa fd fd fd fa fa fa fd fd
0x0c067fff8040: fd fa fa fa fd fd fd fa fa fa fd fd fd fa fa fa
0x0c067fff8050: 00 00 00 fa fa fa fd fd fd fa fa fa fd fd fd fa
0x0c067fff8060: fa fa fd fd fd fa fa fa 00 00 00 fa fa fa 00 00
0x0c067fff8080: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c067fff8090: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c067fff80a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c067fff80b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c067fff80c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==1665037==ABORTING


I applied following change and that appears to avoid the heap-overflow, but
I'm not sure if this is correct fix:

diff --git a/mpi/mpi-inv.c b/mpi/mpi-inv.c
index 3ff5947a..a53a195a 100644
--- a/mpi/mpi-inv.c
+++ b/mpi/mpi-inv.c
@@ -526,7 +526,8 @@ _gcry_mpi_invm (gcry_mpi_t x, gcry_mpi_t a, gcry_mpi_t n)
else
_gcry_mpih_sub_n (diffp, x1p, x2p, x1size);
_gcry_mpi_free_limb_space (x1p, x1size);
- for (i = k % BITS_PER_MPI_LIMB; i < BITS_PER_MPI_LIMB; i++)
+ for (i = k % BITS_PER_MPI_LIMB;
+ i < BITS_PER_MPI_LIMB && k / BITS_PER_MPI_LIMB < x1size; i++)
diffp[k/BITS_PER_MPI_LIMB] &= ~(((mpi_limb_t)1) << i);

hsize = x1size * 2;



-Jussi

On 13.5.2020 9.44, Niibe Yutaka wrote:
> Guido Vranken via Gcrypt-devel wrote:
>> Here is a reproducer for the bugs. OOB reads and writes on i386:
>
> Thanks. It was me who embugged. It was just fixed by the commit:
>
> 69b55f87053ce2494cd4b38dc600f867bc4355be
>
> By the way, the problem in your original report was also fixed.
> Now, it should return correct value (if inverse exists or not).
>

Attached Files:

Re: gcry_mpi_invm succeeds if the inverse does not exist [ In reply to ]
gniibe at fsij
Jun 1, 2020, 12:39 AM
Post #8 of 11 (1717 views)
Permalink
Jussi Kivilinna <jussi.kivilinna@iki.fi> wrote:
> Cryptofuzz is reporting another heap-buffer-overflow issue in
> _gcry_mpi_invm. I've attached reproducer, original from Guido and
> as patch applied to tests/basic.c.

My fix of 69b55f87053ce2494cd4b38dc600f867bc4355be was not enough.
I just push another change:

6f8b1d4cb798375e6d830fd6b73c71da93ee5f3f

Thank you for your report.
--

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
Re: gcry_mpi_invm succeeds if the inverse does not exist [ In reply to ]
gcrypt-devel at gnupg
Sep 3, 2020, 5:19 AM
Post #9 of 11 (1609 views)
Permalink
The following inputs to gcry_mpi_invm():

36fb5bdb5daa9864113ad8a49a41722fc7003a40b02a13daca6997859c2d8534192ff6c02447
25c88352cfa171fc728503df037c355a6d5588b22e3510b08f10848ad7c0980b400

produces the number:

66CAF1A9A03478A288760C2E05E237F11432BA70BECEE56D942ACCD337470E5D77

But this is incorrect (another library reports the modular inverse does not
exist).

----------

The following inputs to gcry_mpi_invm():

12cf3a8ca3d97bea2f080362600cee355
1c3fddf62aee0be2f6dc2ef8471f1be2e

produces the number:

60A6520F494E6EE6EE436283FB34B945

but it should produce:

1339462644931fd624528ea6b3fb1f985

On Mon, Jun 1, 2020 at 9:39 AM NIIBE Yutaka <gniibe@fsij.org> wrote:

> Jussi Kivilinna <jussi.kivilinna@iki.fi> wrote:
> > Cryptofuzz is reporting another heap-buffer-overflow issue in
> > _gcry_mpi_invm. I've attached reproducer, original from Guido and
> > as patch applied to tests/basic.c.
>
> My fix of 69b55f87053ce2494cd4b38dc600f867bc4355be was not enough.
> I just push another change:
>
> 6f8b1d4cb798375e6d830fd6b73c71da93ee5f3f
>
> Thank you for your report.
> --
>
> _______________________________________________
> Gcrypt-devel mailing list
> Gcrypt-devel@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
>
Re: gcry_mpi_invm succeeds if the inverse does not exist [ In reply to ]
gcrypt-devel at gnupg
Jan 25, 2021, 11:40 PM
Post #10 of 11 (1486 views)
Permalink
Reminder that invmod is still broken and has been for a long time.

On Thu, Sep 3, 2020 at 2:19 PM Guido Vranken <guidovranken@gmail.com> wrote:

> The following inputs to gcry_mpi_invm():
>
>
> 36fb5bdb5daa9864113ad8a49a41722fc7003a40b02a13daca6997859c2d8534192ff6c02447
> 25c88352cfa171fc728503df037c355a6d5588b22e3510b08f10848ad7c0980b400
>
> produces the number:
>
> 66CAF1A9A03478A288760C2E05E237F11432BA70BECEE56D942ACCD337470E5D77
>
> But this is incorrect (another library reports the modular inverse does
> not exist).
>
> ----------
>
> The following inputs to gcry_mpi_invm():
>
> 12cf3a8ca3d97bea2f080362600cee355
> 1c3fddf62aee0be2f6dc2ef8471f1be2e
>
> produces the number:
>
> 60A6520F494E6EE6EE436283FB34B945
>
> but it should produce:
>
> 1339462644931fd624528ea6b3fb1f985
>
> On Mon, Jun 1, 2020 at 9:39 AM NIIBE Yutaka <gniibe@fsij.org> wrote:
>
>> Jussi Kivilinna <jussi.kivilinna@iki.fi> wrote:
>> > Cryptofuzz is reporting another heap-buffer-overflow issue in
>> > _gcry_mpi_invm. I've attached reproducer, original from Guido and
>> > as patch applied to tests/basic.c.
>>
>> My fix of 69b55f87053ce2494cd4b38dc600f867bc4355be was not enough.
>> I just push another change:
>>
>> 6f8b1d4cb798375e6d830fd6b73c71da93ee5f3f
>>
>> Thank you for your report.
>> --
>>
>> _______________________________________________
>> Gcrypt-devel mailing list
>> Gcrypt-devel@gnupg.org
>> http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
>>
>
Re: gcry_mpi_invm succeeds if the inverse does not exist [ In reply to ]
gniibe at fsij
Jan 26, 2021, 7:17 PM
Post #11 of 11 (1486 views)
Permalink
Guido Vranken <guidovranken@gmail.com> writes:
> Reminder that invmod is still broken and has been for a long time.

Thanks a lot. I overlooked your email on September.

I created the task:
https://dev.gnupg.org/T5269

And push a fix commit:
https://dev.gnupg.org/rCf06ff4e31c8e162f4a59986241c7ab43d5085927

--

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal