LibTomMath is a free open source portable number theoretic multiple-precision integer library written entirely in C.



This is the git repository for LibTomMath, a free open source portable number theoretic multiple-precision integer (MPI) library written entirely in C.

Build Status

Travis CI

master: Build Status

develop: Build Status


master: Build status

develop: Build status

ABI Laboratory

API/ABI changes: check here


The develop branch contains the in-development version. Stable releases are tagged.

Documentation is built from the LaTeX file bn.tex. There is also limited documentation in tommath.h. There is also a document, tommath.pdf, which describes the goals of the project and many of the algorithms used.

The project can be build by using make. Along with the usual make, make clean and make install, there are several other build targets, see the makefile for details. There are also makefiles for certain specific platforms.


Tests are located in demo/ and can be built in two flavors.

  • make test creates a stand-alone test binary that executes several test routines.
  • make mtest_opponent creates a test binary that is intended to be run against mtest. mtest can be built with make mtest and test execution is done like ./mtest/mtest | ./mtest_opponent. mtest is creating test vectors using an alternative MPI library and test is consuming these vectors to verify correct behavior of ltm

Building and Installing

Building is straightforward for GNU Linux only, the section "Building LibTomMath" in the documentation in doc/bn.pdf has the details.

  • Please create a new release to help packaging in distros

    Please create a new release to help packaging in distros


    I'm trying to create a Debian package for Perl6. This packaging is currently blocked by a test failure. The root cause of this failure is fixed in libtommath by commit 6907f6ca4582064f28e3a58374083ab2a4d85418 (merged).

    To provide a proper Perl6 package, this library must be provided by libtommath Debian package which is at version 0.42.0 (4 years old).

    I'd like to create a new version of libtommath package so that the above fix is available for Debian users (and Perl6 package).

    To make this work much easier, could you create a new release of libtommath ?

    All the best

    opened by dod38fr 77
  • made set_double arch/mem-layout independent

    made set_double arch/mem-layout independent

    It is a bit slower (although completely unoptimized yet) but independent of anything but float.h and the macros DBL_EXP_MAX and FLT_RADIX therein. The same code can be used for floatwith minimal changes (just change DBL_EXP_MAX to FLT_EXP_MAX ). The same could be said for long double but that needs some more tests because of the slightly different format of long double and not everyone has it.

    It is now independent from the type of the architecture and its memory-layout. The values of DBL_EXP_MAXandFLT_RADIXcould be hardcoded to avoid the inclusion offloat.hbut the existence offloat.h` is a good sign for the existence for the availability of at least some floating point functions.

    work in progress 
    opened by czurnieden 48
  • faster Toom-Cook 3 algorithms

    faster Toom-Cook 3 algorithms

    Just brought the implementation up to state-of-the-art, nothing else changed. Halfs the cut-off point and brings it therefore into the expected region. The expected region is a bit less than twice the Karatsuba cut-off point and that is where it is now.

    This code was part of #227.

    opened by czurnieden 46
  • Time for a new release ?

    Time for a new release ?


    Moarvm (Rakudo/Perl6 VM) is using libtommath from April 2018 (

    As Debian packager, I'm building MoarVM with the last version of libtommath (1.0.1) which was released in August 2017.

    I've currently have not seen a problem using Rakudo with this old version of libtommath. But, the increasing gap of libtommath version between Rakudo development and Debian build is making me nervous.

    Since libtommath was last released a year ago and the development is quite active (119 commits since 1.0.1), it may be time to cut a new release...

    Thoughts ?

    opened by dod38fr 42
  • New release?

    New release?

    @sjaeckel Would it make sense to cut a new release at some point and remove deprecated stuff afterwards? Are there open issues right now which stand in the way of a new release?

    Or do you want to have all the open PRs resolved until then?

    opened by minad 36
  • lintings and more

    lintings and more

    This series contains:

    • the PR #40 (6 patches)
    • the end of linting (3 patches)
    • preparation for using a code formatter

    Now, I am ready to use the code formatter astyle (with But I don't know which is the correct indentation: 2, 3 or 4 spaces.

    opened by fperrad 35
  • Addition of mp_radix_size_overestimate (behaviour like the function in GMP)

    Addition of mp_radix_size_overestimate (behaviour like the function in GMP)

    Also changed mp_radix_size to use mp_ilogb while deprecating it at the same time and rewrote mp_fwrite to use mp_radix_sizeinbase instead.

    See comment in bn_mp_fwrite.c for some of the consequences.

    work in progress 
    opened by czurnieden 34
  • add feature detection macro MP_HAS (2)

    add feature detection macro MP_HAS (2)

    See #214. I wanted to try again if I can make this work without using variadic macros, this time only relying on C89.

    @karel-m Could you please try again your compiler suite?

    @sjaeckel @czurnieden This PR is simpler and better than the one before. Hopefully it also works on older compilers. This helps to clean up control flow. Another advantage is that the compiler will check all branches. Dead code elimination will make sure that the dead branches are not compiled.

    feedback required 
    opened by minad 33
  • libtomath build broken on win32, due to the use of uint8_t

    libtomath build broken on win32, due to the use of uint8_t

    When importing the "develop" branch of libtom/libtommath into Tcl, it broke the win32 build. The reason is that no header file is used which defines uint8_t, still this symbol is used in tommath_private.h and bn_mp_radix_smap.c. (the use in tommath.h is harmless, since Tcl doesn't use MP_8BIT)

    opened by nijtmans 30
  • Rename internals

    Rename internals

    See #164. These are only internal functions, no API or ABI changes. The renaming is done by the script. If something needs tweaking only the script should be changed and executed again.

    opened by minad 29
  • Restrict running Valgrind

    Restrict running Valgrind

    • Activate on the develop branch
    • Activate on branches containing the word v-algrind (without hyphen)
    • Activate if the commit message contains v-algrind (without hyphen)

    With valgrind the tests take about 15 minutes, without valgrind about 1 minute. We should not do that. I think it is bad for us and it is kind of abusive towards travis.

    opened by minad 27
  • Compiler & base OS versions

    Compiler & base OS versions

    Ubuntu 18.04 has entered the deprecation phase and with it, a lot of the compilers we use to test will go (and new ones will be available).

    Currently we test against:

    clang: 4.0, 5.0, 6.0, 7, 8, 9, 10
    gcc: 4.8, 5, 7, 8

    Ubuntu 20.04 provides:

    clang: 6.0, 7, 8, 9, 10, 11, 12
    gcc: 7, 8, 9, 10

    Ubuntu 22.04 provides:

    clang: 11, 12, 13, 14
    gcc: 9, 10, 11, 12

    I.e. we will loose clang: 4.0, 5.0 and gcc: 4.8, 5 soon and in two years then we'll loose clang: 6.0, 7, 8, 9, 10 and gcc: 7, 8

    Does someone need those compiler versions to be tested?

    opened by sjaeckel 0
  • add `MP_SMALL_STACK_SIZE` option

    add `MP_SMALL_STACK_SIZE` option

    This adds an option to use a heap-buffer for the usually stack-based MP_WARRAY-sized temporary buffers.

    Per default it will reserve a single buffer, which can be modified

    • at compile-time via the MP_WARRAY_NUM define
    • at run-time by calling mp_warray_init()

    The internal structure can only be created once. If one wants to modify the maximum number of elements, the entire structure has to be free'd by calling mp_warray_free().

    In case one wants to use this option with multiple threads, one shall use the mp_warray_init() function and pass appropriate locking functions.


    | op / algo | ECC | RSA | | ------------ | ------ | ------ | | decrypt_key | ecc_decrypt_key | rsa_decrypt_key | | encrypt_key | ecc_encrypt_key | rsa_encrypt_key | | sign_hash | ecc_sign_hash | rsa_sign_hash | | verify_hash | ecc_verify_hash | rsa_verify_hash |

    Related to: #441 #447 #511

    opened by sjaeckel 1
  • speed please!?

    speed please!?

    Creating this issue in order to pull the discussion regarding a mp_isone() macro out of #532

    Following up on

    [...] It might be tempting to generalize it but since the size of a mp_digit is not fixed over different architectures it would get too complex.

    I just thought about it a bit more and had a look into mp_cmp_d() and only then realized that #define mp_isone(a) ( ((a)->used == 1u) && ((a)->dp[0] == 1u) ) would falsely claim -1 as one ...

    So I have some follow up questions:

    1. maybe it'd be a better idea to have an inline version of mp_cmp_d()?
      • does the function-call overhead really matter that much? I can imagine that it matters, but have no clue to what extent. Did someone measure this?
      • are there any other candidates that could/should be inlined?
      • how will we do that? We're still providing C89 support, so I guess we can't expect all those compilers being able to handle inline functions correctly.
    2. maybe it's time to think about starting to merge in tfm?
      • Which functions should we start with?
      • Which architectures?
    opened by sjaeckel 1
  • Improve mp_root_n code

    Improve mp_root_n code

    Set a closer initial value for iteration and remove some unnecessary code. By the way, in the first for loop, one of the err=MP_OKAY branches (never reached) did not set c.

    opened by ssinai1 12
  • tommath_c89.h versus other solutions for backward compatibility with <C99

    tommath_c89.h versus other solutions for backward compatibility with

    The number of makefiles in this project is staggering, but in any case the issue I addressed in #525 for MSVC doesn't seem to be limited to MSVC. Seeing that there is a tommath_c89.h in the source tree, I was wondering if a more generalized approach for any C below C99 wouldn't be the better option at all. In the current draft pull request the header is pretty complete, but has preprocessor conditions which will make it fail on non-MSVC compilers.

    Arguably it could be tested on other old compilers (ancient Watcom comes to mind) and the switching could be done based on checking against the standard version, e.g.:

    #if (__STDC_VERSION__ < 199901L)
    #include <tommath_c89.h> /* an extended version of the current one */
    #include <stdint.h>
    #include <stdbool.h>

    (or invert the condition order, I don't care)

    Either way this would improve the robustness and have all compilers benefit from the C89 compatibility, not just builds done with that makefile where some sed command creates an illusion of compatibility by changing the source files prior to a build (something that in my book is a big no no when building third-party code).

    I would also recommend renaming the makefile to GNUmakefile and then consolidating its contents. E.g. for the assignment to OBJECTS it could use something akin to what the pre_gen (amalgamation) target has:

    SOURCES:=$(wildcard *mp_*.c)

    Rationale: if you already have a special makefile for GNU make it makes sense to make this explicit and limit its scope to GNU make. A makefile by the name GNUmakefile will be picked up first by GNU make (it has several names hardcoded), even before makefile. So it could in fact work to rename the current makefile to GNUmakefile then rename the current makefile.unix to makefile. The behavior should be the same, except that on BSD you no longer need to specify the file name.

    For the most part when using GNU make I'd also recommend immediate assignments (:=) as opposed to lazy ones (=).

    opened by assarbad 2
libtom projects
MIRACL Cryptographic SDK: Multiprecision Integer and Rational Arithmetic Cryptographic Library is a C software library that is widely regarded by developers as the gold standard open source SDK for elliptic curve cryptography (ECC).

MIRACL What is MIRACL? Multiprecision Integer and Rational Arithmetic Cryptographic Library – the MIRACL Crypto SDK – is a C software library that is

MIRACL 527 Jan 7, 2023
An updated, 1.2.1 version of Equalizer APO running with internal double precision processing (64 bit)

EqualizerAPO - 64bit port This repo contains an updated, 1.2.1 64-bit port of EqualizerAPO - system wide equalizer for Windows. The port here is inspi

FireKahuna 41 Dec 4, 2022
Simple long integer math library for C++

SLIMCPP Simple long integer math library for C++ SLIMCPP is C++ header-only library that implements long integers that exceed maximum size of native t

null 23 Dec 1, 2022
Long integer arithmetic.

LongInt Содержимое репозитория представляет из себя исходный код примитивного консольного калькулятора, который использует реализацию длинных чисел из

null 13 Nov 2, 2022
Universal Number Arithmetic

Universal: a header-only C++ template library for universal number arithmetic The goal of the Universal Numbers Library is to offer applications alter

Stillwater Supercomputing, Inc. 296 Dec 23, 2022
Kraken is an open-source modern math library that comes with a fast-fixed matrix class and math-related functions.

Kraken ?? Table of Contents Introduction Requirement Contents Installation Introduction Kraken is a modern math library written in a way that gives ac

yahya mohammed 24 Nov 30, 2022
A thin, highly portable C++ intermediate representation for dense loop-based computation.

A thin, highly portable C++ intermediate representation for dense loop-based computation.

Facebook Research 125 Nov 24, 2022
CMath is an open-source project for developers.

Project CMath An open-source project for developers by developers Member of GitHub Developer Program About CMath CMath is an open-source project for C

Jayed Rafi 2 Jun 11, 2022
Library for nonconvex constrained optimization using the augmented Lagrangian method and the matrix-free PANOC algorithm.

alpaqa Alpaqa is an efficient implementation of the Augmented Lagrangian method for general nonlinear programming problems, which uses the first-order

OPTEC 21 Dec 9, 2022
SymEngine is a fast symbolic manipulation library, written in C++

SymEngine SymEngine is a standalone fast C++ symbolic manipulation library. Optional thin wrappers allow usage of the library from other languages, e.

null 926 Dec 24, 2022
nml is a simple matrix and linear algebra library written in standard C.

nml is a simple matrix and linear algebra library written in standard C.

Andrei Ciobanu 45 Dec 9, 2022
Fast math tool written on asm/c

math_tool fast math tool written on asm/c This project was created for easy use of mathematical / geometric rules and operations. This project contain

portable executable 3 Mar 8, 2022
A C library for statistical and scientific computing

Apophenia is an open statistical library for working with data sets and statistical or simulation models. It provides functions on the same level as t

null 186 Sep 11, 2022
P(R*_{3, 0, 1}) specialized SIMD Geometric Algebra Library

Klein ?? ?? Project Site ?? ?? Description Do you need to do any of the following? Quickly? Really quickly even? Projecting points onto lines, lines t

Jeremy Ong 635 Dec 30, 2022
linalg.h is a single header, public domain, short vector math library for C++

linalg.h linalg.h is a single header, public domain, short vector math library for C++. It is inspired by the syntax of popular shading and compute la

Sterling Orsten 758 Jan 7, 2023
a lean linear math library, aimed at graphics programming. Supports vec3, vec4, mat4x4 and quaternions

linmath.h -- A small library for linear math as required for computer graphics linmath.h provides the most used types required for programming compute

datenwolf 729 Jan 9, 2023
OpenBLAS is an optimized BLAS library based on GotoBLAS2 1.13 BSD version.

OpenBLAS Travis CI: AppVeyor: Drone CI: Introduction OpenBLAS is an optimized BLAS (Basic Linear Algebra Subprograms) library based on GotoBLAS2 1.13

Zhang Xianyi 4.9k Jan 5, 2023
The QuantLib C++ library

QuantLib: the free/open-source library for quantitative finance The QuantLib project ( is aimed at providing a comprehensive softw

Luigi Ballabio 3.6k Dec 30, 2022
A C++ header-only library of statistical distribution functions.

StatsLib StatsLib is a templated C++ library of statistical distribution functions, featuring unique compile-time computing capabilities and seamless

Keith O'Hara 423 Jan 3, 2023