While hacking on ecc_sign+verify_hash_rfc7518 earlier today I realized that it would be possible to extract from my branch miko-ecc-enhancements the crucial part implementing generalized elliptic curves y^2 = x^3 + ax + b (current develop branch supports only y^2 = x^3 - 3x + b).

The API changes comprise of the following new functions:

int  ecc_export_raw(unsigned char *out, unsigned long *outlen, int type, ecc_key *key);
int  ecc_import_raw(const unsigned char *in, unsigned long inlen, ecc_key *key, ltc_ecc_set_type *dp);

ltc_ecc_set_type* ecc_dp_find_by_oid(unsigned long *oid, unsigned long oidsize);
ltc_ecc_set_type* ecc_dp_find_by_name(char *curve_name);
ltc_ecc_set_type* ecc_dp_find_by_params(char *hex_prime, char *hex_A, char *hex_B, char *hex_order, char *hex_Gx, char *hex_Gy, unsigned long cofactor);

These are missing due to #187

• ecc_export_full - export EC key in OpenSSL compatible format
• ecc_import_full - import EC key in OpenSSL compatible format
• ecc_import_pkcs8 - import EC key in PKCS#8 format

The idea of dh_make_key_ex (which allows using custom DH group params) was suggested and implemented by @lkinley as a contribution to my libtomcrypt perl bindings.

It is simply about adding:

int dh_make_key_ex(prng_state *prng, int wprng, char *prime_hex, char *base_hex, dh_key *key)

Unfortunately the implementation turned into a bunch of troubles&workarounds like changes to dh_key structure changes (incompatible) to import/export format etc.

Some questions:

• How far can we go in breaking DH API? (currently only in develop for some time, not released yet)
• Is the format used for DH key export/import intended to compatible with some specification? (this PR changed it in an incompatible way)

This patch implements ECC public key recovery from hash+signature.

There are only a small number of possible public keys, typically 2, corresponding to the 'r' value in an elliptic-curve signature. These can be represented by a single parity bit - as with X9.62 compressed keys - in addition to the signature, rather than pre-sharing the public key. This is used in Bitcoin/Ethereum to avoid an explicit representation of the public key, saving space in messages.

ecc_recover_key() takes a signature and message hash and an additional "recovery ID" value to specify which of the possible public keys to recover. Parameters are very similar to ecc_verify_hash(), but the public key is the output rather than an input.

See https://crypto.stackexchange.com/questions/18105/how-does-recovering-the-public-key-from-an-ecdsa-signature-work for the underlying maths.

Cheers,

Russ

Checklist

• [x] documentation is added or updated
• [x] tests are added or updated

it's been 3 years since this tomcrypt fork exists, and afaik there hasn't been any release.

i fear that if the development continues at this pace, libtomcrypt will be rendered obsolete soon.

from the outside it looks dead, so new software will probably not be written against it anymore, and chances that security researchers test a library that's not been updated since 4 years are little.

so if you really want to keep this project alive, you better start merging patches into master and pushing out releases soon.

Thanks for creating such elegant crypt library. It's just the thing that i want. But i found some difficult on transplanting it. I have a hardware which only have 512 KB memory to use. And the only two functions i need are "rsa_import" "and rsa_decrypt". So i just include "rsa_decrypt_key.c" and "rsa_import.c", and then whenever i found "undefined references", i will include corresponding source file.

Finally it passes compiling, but i found the final library is 900KB, libtommatch is already 700KB. Is there any chance for me to shrink it? And how can i do it?

Visual C/C++ 2008

1>.\src\math\ltm_desc.c(92) : warning C4244: 'function' : conversion from 'ltc_mp_digit' to 'unsigned long', possible loss of data
1>.\src\math\ltm_desc.c(135) : warning C4244: 'function' : conversion from 'ltc_mp_digit' to 'mp_digit', possible loss of data
1>.\src\math\ltm_desc.c(217) : warning C4244: 'function' : conversion from 'ltc_mp_digit' to 'mp_digit', possible loss of data
1>.\src\math\ltm_desc.c(233) : warning C4244: 'function' : conversion from 'ltc_mp_digit' to 'mp_digit', possible loss of data
1>.\src\math\ltm_desc.c(249) : warning C4244: 'function' : conversion from 'ltc_mp_digit' to 'mp_digit', possible loss of data
1>.\src\math\ltm_desc.c(284) : warning C4244: 'function' : conversion from 'ltc_mp_digit' to 'mp_digit', possible loss of data

related to:

mp_cmp_d
mp_add_d
mp_sub_d
mp_mul_d
mp_mod_d
mp_set_int

@sjaeckel do we want to fix them?

Hello,

now i reading the pdf from libtomaths and libtomcrypt. But i have lots of question if i generate a RSA key. for my solution is the function (10.5.2) the right. Then i want to generate the RSA from a very big int. But with the docu i don't know if i use this funktion. a) my int is to large for the functions (256 length). c) rsa_key is it = null?

My example:

//x= 5733336211291957930059404707424515459001308671312770355953656564034332742203603124315643680841135124130078998386115460347685517060243789055573316102146724
//n = 12195768979127026417187603714036391958048299327164883087603312522730977833600860696919578595717794043319551957556836036894416267108725971086946438691747253
		rsa_make_key(
			12195768979127026417187603714036391958048299327164883087603312522730977833600860696919578595717794043319551957556836036894416267108725971086946438691747253,
			5733336211291957930059404707424515459001308671312770355953656564034332742203603124315643680841135124130078998386115460347685517060243789055573316102146724,
			154,
			10000,
                      null
		);

Please give me a example.

I have found several functions taking non-cost pointers, while the only thing they do is return size of some keys.

I believe that functions like these really should take their arguments as const rsa_key* to preserve const-correctness and not being forced to write (i. e. in C++) things like

inline int GetKeySize() const { return ::rsa_get_size(const_cast<rsa_key*>(&key_)); }

If someone comes across another function(s) which should have const parameter but do not, you can write here and we can fix them all at once instead of splitting that into several commits.

Thanks!

EDIT: As was pointed out by several commenters, there are many more functions in which a non-const pointer parameter is not used to change the pointed-to object, therefore the pointer can be declared as a const pointer. See below for the full discussion.

Hi, libtom folks,

In libtomcrypt 1.18.0-rc3, the make test is failing for me, with an undefined symbol error. I'm using makefile.unix, and the main build succeeds, but the make test build fails at the link stage, with the following error.

$ make -f makefile.unix CFLAGS="-DUSE_LTM -DLTM_DESC -I/usr/local/lib" EXTRALIBS="-ltommath" test
cc -Isrc/headers -Itests -DLTC_SOURCE -DUSE_LTM -DLTM_DESC -I/usr/local/lib -c tests/base64_test.c -o tests/base64_test.o
cc -Isrc/headers -Itests -DLTC_SOURCE -DUSE_LTM -DLTM_DESC -I/usr/local/lib -c tests/cipher_hash_test.c -o tests/cipher_hash_test.o
cc -Isrc/headers -Itests -DLTC_SOURCE -DUSE_LTM -DLTM_DESC -I/usr/local/lib -c tests/common.c -o tests/common.o
cc -Isrc/headers -Itests -DLTC_SOURCE -DUSE_LTM -DLTM_DESC -I/usr/local/lib -c tests/der_test.c -o tests/der_test.o
cc -Isrc/headers -Itests -DLTC_SOURCE -DUSE_LTM -DLTM_DESC -I/usr/local/lib -c tests/dh_test.c -o tests/dh_test.o
cc -Isrc/headers -Itests -DLTC_SOURCE -DUSE_LTM -DLTM_DESC -I/usr/local/lib -c tests/dsa_test.c -o tests/dsa_test.o
cc -Isrc/headers -Itests -DLTC_SOURCE -DUSE_LTM -DLTM_DESC -I/usr/local/lib -c tests/ecc_test.c -o tests/ecc_test.o
cc -Isrc/headers -Itests -DLTC_SOURCE -DUSE_LTM -DLTM_DESC -I/usr/local/lib -c tests/file_test.c -o tests/file_test.o
cc -Isrc/headers -Itests -DLTC_SOURCE -DUSE_LTM -DLTM_DESC -I/usr/local/lib -c tests/katja_test.c -o tests/katja_test.o
cc -Isrc/headers -Itests -DLTC_SOURCE -DUSE_LTM -DLTM_DESC -I/usr/local/lib -c tests/mac_test.c -o tests/mac_test.o
cc -Isrc/headers -Itests -DLTC_SOURCE -DUSE_LTM -DLTM_DESC -I/usr/local/lib -c tests/misc_test.c -o tests/misc_test.o
cc -Isrc/headers -Itests -DLTC_SOURCE -DUSE_LTM -DLTM_DESC -I/usr/local/lib -c tests/modes_test.c -o tests/modes_test.o
cc -Isrc/headers -Itests -DLTC_SOURCE -DUSE_LTM -DLTM_DESC -I/usr/local/lib -c tests/mpi_test.c -o tests/mpi_test.o
cc -Isrc/headers -Itests -DLTC_SOURCE -DUSE_LTM -DLTM_DESC -I/usr/local/lib -c tests/multi_test.c -o tests/multi_test.o
cc -Isrc/headers -Itests -DLTC_SOURCE -DUSE_LTM -DLTM_DESC -I/usr/local/lib -c tests/no_prng.c -o tests/no_prng.o
cc -Isrc/headers -Itests -DLTC_SOURCE -DUSE_LTM -DLTM_DESC -I/usr/local/lib -c tests/pkcs_1_eme_test.c -o tests/pkcs_1_eme_test.o
cc -Isrc/headers -Itests -DLTC_SOURCE -DUSE_LTM -DLTM_DESC -I/usr/local/lib -c tests/pkcs_1_emsa_test.c -o tests/pkcs_1_emsa_test.o
cc -Isrc/headers -Itests -DLTC_SOURCE -DUSE_LTM -DLTM_DESC -I/usr/local/lib -c tests/pkcs_1_oaep_test.c -o tests/pkcs_1_oaep_test.o
cc -Isrc/headers -Itests -DLTC_SOURCE -DUSE_LTM -DLTM_DESC -I/usr/local/lib -c tests/pkcs_1_pss_test.c -o tests/pkcs_1_pss_test.o
cc -Isrc/headers -Itests -DLTC_SOURCE -DUSE_LTM -DLTM_DESC -I/usr/local/lib -c tests/pkcs_1_test.c -o tests/pkcs_1_test.o
cc -Isrc/headers -Itests -DLTC_SOURCE -DUSE_LTM -DLTM_DESC -I/usr/local/lib -c tests/prng_test.c -o tests/prng_test.o
cc -Isrc/headers -Itests -DLTC_SOURCE -DUSE_LTM -DLTM_DESC -I/usr/local/lib -c tests/rotate_test.c -o tests/rotate_test.o
cc -Isrc/headers -Itests -DLTC_SOURCE -DUSE_LTM -DLTM_DESC -I/usr/local/lib -c tests/rsa_test.c -o tests/rsa_test.o
cc -Isrc/headers -Itests -DLTC_SOURCE -DUSE_LTM -DLTM_DESC -I/usr/local/lib -c tests/store_test.c -o tests/store_test.o
cc -Isrc/headers -Itests -DLTC_SOURCE -DUSE_LTM -DLTM_DESC -I/usr/local/lib -c tests/test.c -o tests/test.o
cc tests/base64_test.o tests/cipher_hash_test.o tests/common.o tests/der_test.o tests/dh_test.o tests/dsa_test.o tests/ecc_test.o tests/file_test.o tests/katja_test.o tests/mac_test.o tests/misc_test.o tests/modes_test.o tests/mpi_test.o tests/multi_test.o tests/no_prng.o tests/pkcs_1_eme_test.o tests/pkcs_1_emsa_test.o tests/pkcs_1_oaep_test.o tests/pkcs_1_pss_test.o tests/pkcs_1_test.o tests/prng_test.o tests/rotate_test.o tests/rsa_test.o tests/store_test.o tests/test.o libtomcrypt.a  -ltommath -o test
Undefined symbols for architecture x86_64:
  "_ltc_mp", referenced from:
      _der_test in der_test.o
      _der_flexi_test in der_test.o
      _der_choice_test in der_test.o
      __prime_test in dh_test.o
      __dhparam_test in dh_test.o
      __set_test in dh_test.o
      _ecc_test_shamir in ecc_test.o
      ...
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [test] Error 1

The symbol does seem to be defined in the library:

$ nm libtomcrypt.a | grep _ltc_mp | grep --context=2 C
                 U _ltc_mp
libtomcrypt.a(crypt_ltc_mp_descriptor.o):
00000000000001a0 C _ltc_mp
                 U _ltc_mp
                 U _ltc_mp

This is on:

• macOS 10.12.6
• libtommath 1.0.1 installed via Mac Homebrew

Any idea what's going on here? Or any additional info I can provide to help debug?

When compiling libtomcrypt on ppc64 big-endian, I get the following result below when running the tests. It might be an endianness-related issue.

./test build == LibTomCrypt 1.17 (Tom St Denis, [email protected]) LibTomCrypt is public domain software.

Endianness: neutral Clean stack: disabled Ciphers built-in: Blowfish RC2 RC5 RC6 Safer+ Safer Rijndael XTEA Twofish (tables) DES CAST5 Noekeon Skipjack Khazad Anubis (tweaked) KSEED KASUMI MULTI2 Camellia

Hashes built-in: SHA-512 SHA-384 SHA-512/256 SHA-256 SHA-512/224 SHA-224 TIGER SHA1 MD5 MD4 MD2 RIPEMD128 RIPEMD160 RIPEMD256 RIPEMD320 WHIRLPOOL CHC_HASH

Block Chaining Modes: CFB OFB ECB CBC CTR LRW (tables) F8 XTS

MACs: HMAC OMAC PMAC PELICAN XCBC F9

ENC + AUTH modes: EAX OCB OCB3 CCM GCM (tables)

PRNG: Yarrow (LTC_YARROW_AES=2) SPRNG RC4 Fortuna (LTC_FORTUNA_POOLS=32, LTC_FORTUNA_WD=10) SOBER128

PK Algs: RSA (with blinding and CRT hardening) DH ECC (with blinding) DSA

Compiler: GCC compiler 6.0.0 20160227 (Red Hat 6.0.0-0.13).

Various others: ADLER32 BASE64 BASE64-URL-SAFE CRC32 DER LTC_DER_MAX_PUBKEY_SIZE=4096 PKCS#1 PKCS#5 HKDF LTC_DEVRANDOM LTC_TRY_URANDOM_FIRST LTC_RNG_GET_BYTES LTC_RNG_MAKE_PRNG LTC_HASH_HELPERS LTC_TEST LTM_DESC LTC_ECC_SHAMIR

MP_DIGIT_BIT = 28

store_test....passed misc_test.....crc32 fail! Is: 0x0 Should: 0xef7673b3 Algorithm failed test vectors. (5) misc_test.c:18:crc32_test()

Hello, do not know if this is the right place to post. I am trying do some simulations on cooja, i have used libtomcrypt.

I have

instant contiki on virtual box installed libtomcrypt-dev (installed from src) -> libtomcrypt.a (usr/lib) -> libtomcrypt.so (/usr/lib/i386-linux-gnu/) but it is giving me error (tomcrypt.h not found), but i have *.h in my /usr/include path which is default for gcc as far as i know.

-- myfile.c is working fine with TARGET=native but when i change it to SKY, it comes up with exceptions.

make TARGET=sky savetarget (saving MakeFile.target), seems it is working. make myfile.upload (generates error tomcrypt.h not found).

libtomcrypt is available as a port in vcpkg, a C++ library manager that simplifies installation for libtomcrypt and other project dependencies. Documenting the install process here will help users get started by providing a single set of commands to build libtomcrypt, ready to be included in their projects.

We also test whether our library ports build in various configurations (dynamic, static) on various platforms (OSX, Linux, Windows: x86, x64) to keep a wide coverage for users.

I'm a maintainer for vcpkg, and here is what the port script looks like. We try to keep the library maintained as close as possible to the original library. 😊

Checklist

• [x] documentation is added or updated
• [x] tests are added or updated

This adds support to create and build an amalgamated version of the library, which is maybe useful for some.

Gentoo Bug: https://bugs.gentoo.org/777084

This changes the makefile.shared build to not require libtool during the build instead of the existing hacks. This is helpful for avoiding the already existing hacks for slibtool. I am not sure this is the direction the libtomcrypt / libtommath projects want to go, but I am proposing it as an option.

Note: I tested this on Gentoo and Slackware linux, but there may be issues for other platforms I can't personally test and they should be tested first.

Prerequisites

• [x] Checked the developer manual
• [x] Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=repo%3Alibtom%2Flibtomcrypt
• [ ] Checked that your issue isn't related to TomsFastMath's limitation that PK operations can by default only be done with max. 2048bit keys

Description

rsa_decrypt_key doesn't properly handle buffer overflows. Instead of setting outlen to the required size to match the output and returning CRYPT_BUFFER_OVERFLOW, it leaves outlen untouched and returns CRYPT_INVALID_PACKET.

Steps to Reproduce

Code snippet:

#include <tomcrypt.h>

#include <cstdio>
#include <cstdint>
#include <vector>

int rsa_error_example()
{
  int err;
  unsigned long outlen;

  rsa_key key;
  const int bitsize = 1024;

  std::vector<uint8_t> aes_key(16); // To be encrypted with RSA
  sprng_read(aes_key.data(), aes_key.size(), nullptr);

  // Generate key

  int prng_idx = register_prng(&sprng_desc);
  if (prng_idx < 0)
  {
    return -1;
  }

  err = rsa_make_key(NULL, prng_idx, bitsize / 8, 65537, &key);
  if (err != CRYPT_OK)
  {
    return err;
  }

  // Encrypt data

  int hash_idx = register_hash(&sha256_desc);
  if (hash_idx < 0 || prng_idx < 0)
  {
    return -1;
  }

  std::vector<uint8_t> aes_key_encr(1);
  outlen = aes_key_encr.size();
  err = rsa_encrypt_key(aes_key.data(), aes_key.size(), aes_key_encr.data(), &outlen, NULL, 0, NULL, prng_idx, hash_idx, &key);
  if (err == CRYPT_BUFFER_OVERFLOW)
  {
    aes_key_encr.resize(outlen);
    err = rsa_encrypt_key(aes_key.data(), aes_key.size(), aes_key_encr.data(), &outlen, NULL, 0, NULL, prng_idx, hash_idx, &key);
  }

  if (err != CRYPT_OK)
  {
    return err;
  }

  aes_key_encr.resize(outlen);

  // Decrypt data

  int stat;
  std::vector<uint8_t> aes_key_decr(1);
  outlen = aes_key_decr.size();
  err = rsa_decrypt_key(aes_key_encr.data(), aes_key_encr.size(), aes_key_decr.data(), &outlen, NULL, 0, hash_idx, &stat, &key);
  if (err == CRYPT_BUFFER_OVERFLOW) // Error here
  // Expected: err == CRYPT_BUFFER_OVERFLOW   outlen == 16
  // Real:     err == CRYPT_INVALID_PACKET    outlen == 1
  {
    aes_key_decr.resize(outlen);
    err = rsa_decrypt_key(aes_key_encr.data(), aes_key_encr.size(), aes_key_decr.data(), &outlen, NULL, 0, hash_idx, &stat, &key);
  }

  if (err != CRYPT_OK || stat != 1)
  {
    return err;
  }

  aes_key_decr.resize(outlen);

  // Check

  if (aes_key != aes_key_decr)
  {
    return -1;
  }

  return 0;
}

int main(void)
{
  ltc_mp = ltm_desc;

  if (rsa_error_example() != 0)
  {
    printf("ERROR\n");
    return 1;
  }

  return 0;
}

Version

v1.18.2-654-g06a81aeb-dirty

Additional Information

I think the problem is with these functions: https://github.com/libtom/libtomcrypt/blob/910d6252770f1e517d9ed02dc0549a1d61dfe159/src/pk/pkcs1/pkcs_1_oaep_decode.c#L148 https://github.com/libtom/libtomcrypt/blob/910d6252770f1e517d9ed02dc0549a1d61dfe159/src/pk/pkcs1/pkcs_1_v1_5_decode.c#L88

Prerequisites

• [x] Checked the developer manual
• [x] Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=repo%3Alibtom%2Flibtomcrypt
• [x] Checked that your issue isn't related to TomsFastMath's limitation that PK operations can by default only be done with max. 2048bit keys

Description

If you look at the definition of CFB mode (for example in NIST SP 800-38A document), you will see that CFB mode can accept integer parameter (called s) telling the CFB (roughly) how many bits shall process at a time. The parameter is often incorporated into the mode's name (such as 1-bit CFB mode, the 8-bit CFB mode, the 64-bit CFB mode, or the 128-bit CFB mode).

The problem is, that libtomcrypt doesn't document which CFB variant it uses.

Therefore in this issue I suggest to improve libtomcrypt's documentation to tell its users that it always uses the "full width" version of CFB ("full-width" meaning 128-bit CFB for AES cipher (I didn't test with other ciphers, yet)). This might apply to other modes as well (I didn't test other modes, yet).

Steps to Reproduce

Write AES + CFB implementation from scratch (yes, I'm masochist reinventing wheel) and test its correctness against other crypto library (such as libtomcrypt) and discover that both libraries behave differently.

Version

Latest git head, develop branch, 1.17. Windows 10, x86 + x64, Visual Studio 2022.

Additional Information

It would be nice if libtomcrypt would implement the CFB s parameter, but this is not subject of this issue.

Best regards, Marek.