Hi mnzdbz,

How is your stack configured? Fast math (tfm.c) uses stack not heap. The correct size for FP_MAX_BITS is your maximum key size * 2 (for multiplication of two big integers).

You would likely need about 8KB of stack with your configuration. If you would like to use heap I recommend the following build settings.


#define WOLFSSL_SP_MATH_ALL
#define WOLFSSL_SP_SMALL
#define WOLFSSL_SMALL_STACK

This will use our sp_int.c with heap allocations.

Thanks,
David Garske, wolfSSL

Looks like it is all working normal. I would recommend trying to run examples/wrap/wrap_test to verify.

It looks like the unit test makes an assumption about parsing capabilities. I will investigate tomorrow.

Hi Richeal C,

Have you tried adjusting the TPM2_SPI_MAX_HZ to a lower value?

Can you try building wolfTPM like:

./configure --enable-infineon=slb9670 CFLAGS="-DTPM2_SPI_MAX_HZ=33000000"

Note you can add --enable-debug=io to see the raw output. Some of the self-test and key creation routines take a while. You might consider looking at XTPM_WAIT.

Can you tell us more about your project? Feel free to email support @ wolfssl.com directly.

Thanks,
David Garske, wolfSSL

Hi mnzdbz,

1) If you are using wolfCrypt only (no TLS) and do not want to do any X.509 you should be able to use NO_CERTS. We did have some fixes around this recently. But you should be able to use NO_CERTS, WOLFCRYPT_ONLY and WOLFSSL_ASN_TEMPLATE.

2) That is a great question! We have several math options with varying memory use. You are using fast math which uses math variables on the stack. Those sizes are max key size * 2. Example #define FP_MAX_BITS (2*2048)". If you have only 3KB of RAM it is unlikely you'll be able to do any asymmetric operations RSA or ECC. For example a 2048-bit RSA key requires multiple 512 byte math variables and the underlying modulus exponent uses several more.  Do you really only have access to 3KB of RAM?

Thanks,
David Garske, wolfSSL

Hi mnzdbz,

For validation of certificate begin/end dates we need a time source/RTC. If this is not available you can bypass date checking by adding NO_ASN_TIME to your user_settings.h. If you have an RTC, but your stdlib doesn't expose time() then you can define your own API.

Example:

/* user_settings.h - Override Current Time */

/* Allows custom "custom_time()" function to be used for benchmark */
#define WOLFSSL_USER_CURRTIME
#define WOLFSSL_GMTIME
#define USER_TICKS
extern unsigned long my_time(unsigned long* timer);
#define XTIME my_time

/* example code */

/* This is used by wolfCrypt asn.c for cert time checking */
unsigned long my_time(unsigned long* timer)
{
    (void)timer;
    return hw_get_time_sec();
}

Thanks,
David Garske, wolfSSL

Hi mnzdbz,

To me it looks like you are running out of flash space. Its not a 32-bit/16-bit issue. Your 32-bit MCU has support for the 64-bit type (word64) using "long long".

I suggest you review our low resource build options and user_settings template here:
* https://github.com/wolfSSL/wolfssl/blob … template.h
* https://github.com/wolfSSL/wolfssl/blob … e.ac#L1962

You would likely benefit from the following:
* USE_SLOW_SHA512

Which C files are you building? Some of the algorithms are on by default and require a NO_ build option (example NO_SHA).

Thanks,
David Garske, wolfSSL

Hi Wangzihao,

Can you share the build settings you are using to compile wolfSSL (like the ./configure or user_settings.h)?

Thanks,
David Garske, wolfSSL

Hi Wangzihao,

The `wc_ecc_get_generator` is wrapped with the `OPENSSL_EXTRA`. Make sure when building you include `./configure --enable-opensslextra`.

However normally someone would export the private or public key using a different function after a make_key. See `wc_ecc_export_x963`, `wc_ecc_export_private_only`, `wc_ecc_export_point_der`, `wc_ecc_export_public_raw`, etc.


Thanks,
David Garske, wolfSSL

Hi Sebastian,

Building our libraries for bare-metal is the easy part. Both wolfSSL and wolfMQTT are pure C libraries designed for portability and even bare-metal use.

For building you have a few options:
1) Use ./configure and cross-compile the libraries for your target. Something like:

./configure --host=arm-none-eabi CC=gcc AR=ar --disable-shared --disable-examples --disable-crypttests --disable-asm --disable-rsa --disable-dh --enable-tls13 --disable-tlsv12 CFLAGS="-mcpu=cortex-m0 -mthumb" LDFLAGS="-mcpu=cortex-m0 -mthumb"

. The result is a .a static library. You can use --prefix= to specify a custom install path used with "make install". This generates a wolfssl/options.h with the build options used. You'll need to include this in your application

#include <wolfssl/options.h>

.

2) Use our example GCC Makefiles in IDE/GCC-ARM which can be easily setup for Cortex M0

3) Use your own IDE: Import the src/*.c and wolfcrypt/src/*.c files into your project and build directly. Add include to the wolfSSL/wolfMQTT root. Add pre-processor WOLFSSL_USER_SETTINGS and add your own user_settings.h file (examples here: https://github.com/wolfSSL/wolfssl/tree … s/configs)

You'll likely have to do some investigating on how to use LWIP on bare-metal. I don't know of an example we have for this. But google turned up this nice article: https://lwip.fandom.com/wiki/LwIP_with_ … ing_system

Perhaps a short technical call might help you get started?

Thanks,
David Garske, wolfSSL

Hi Sebastian,

Yes it is very possible to do MQTTS on bare-metal.

Can you tell us more about the compiler/IDE, hardware and reason for bare-metal requirement? Have you selected a network stack and confirmed it can be used in bare-metal?

You might find this MQTT over UART example useful for understanding how to customize the network IO layer: https://github.com/wolfSSL/wolfMQTT/blo … mqttuart.c

The wolfSSL FAQ covers some useful topics like build configuration: https://www.wolfssl.com/docs/frequently … tions-faq/

For building wolfSSL (TLS) you just need to build with SINGLE_THREADED, NO_FILESYSTEM, etc...

Let me know if you have any specific questions or build issues.

Thanks,
David Garske, wolfSSL

61

(6 replies, posted in wolfCrypt)

Hi Shammon,

Each asymmetric algorithm has different total memory requirements. We have several build options for altering where this memory comes from. For example you can put on heap, stack or static memory.

By default the memory comes mostly from the stack. If you'd prefer to use the heap then I would should consider updating to the latest wolfSSL in GitHub and using the `WOLFSSL_SP_SMALL_STACK` option, which is new. Or you could just try `WOLFSSL_SMALL_STACK` with your current release.

The RSA/DH algorithms have a much lager key size and generally use more memory. The ECC (ECDHE/ECDSA) and ED25519 algorithms use much less memory and can also be used with TLS v1.2 and v1.3.

Perhaps you can tell me more about your configuration such as RTOS/bare-metal, available heap/stack and TLS requirements?

Thanks,
David Garske, wolfSSL

62

(6 replies, posted in wolfCrypt)

Hi Shammon,

I still suspect you are running out of memory because DH uses a large amount from the stack. Have you considered using ECDHE?

You might also consider trying a different math library option. We have several (see https://github.com/wolfSSL/wolfssl/blob … .ftl#L202)

I recommend you try with a small math implementation like `3=Single Precision C (only common curves/key sizes)`.

Thanks,
David Garske, wolfSSL

63

(6 replies, posted in wolfCrypt)

Hi Shammon,

This sounds like a stack issue. Please try increasing your stack memory for the thread or adjust in the linker script if using bare-metal. What size DH key are you trying to generate? Have you tried running the wolfCrypt tests first? Make sure you have the right DH parameters enabled via `HAVE_FFDHE_2048`, `HAVE_FFDHE_3072`, `HAVE_FFDHE_4096`, etc.

Thanks,
David Garske, wolfSSL

Hi Geoff,

It is great to hear from you. This is a very interesting use-case.

For the TLS use case we have lots of examples for this in wolfTPM:
https://github.com/wolfSSL/wolfTPM/tree … s-examples
https://github.com/wolfSSL/wolfTPM/tree … amples/tls

In wolfSSL we support consuming a PKCS11 interface. We also have a wolfPKCS11 provider that uses wolfCrypt on the backend. It would be possible to take our wolfPKCS11 and use a TPM under it. We've discussed doing this, but is a decent effort. https://github.com/wolfSSL/wolfpkcs11

Let's have a call with Rich and I to discuss.

Thanks,
David Garske, wolfSSL

65

(4 replies, posted in wolfTPM)

Hi Luizg473,

I think your issue is not using `wolfTPM2_Init` and `wolfTPM2_Cleanup`. Have you tried that?

wolfTPM should have the WinAPI option enabled by default for windows: https://github.com/wolfSSL/wolfTPM/blob … ts.txt#L86

You can use `WOLFTPM_INTERFACE=WINAPI` to force it.

The build settings for wolfTPM come from here: https://github.com/microsoft/vcpkg/blob … file.cmake

Thanks,
David Garske, wolfSSL

66

(4 replies, posted in wolfTPM)

Hi luizg473,

Are you building with `--enable-winapi` or setting `#define WOLFTPM_WINAPI`? This will enable using the Window TBS layer for communicating with the TPM. If you are building with winapi then the TPM2_Init IO callback can be NULL. Also you should use wolfTPM2_Init if you are using wrapper API's.

Let me know if that doesn't work.

Thanks,
David Garske, wolfSSL

Hi Yusheng,

Here is an example for how I've built wolfSSL for QNX in the past:

./configure --host=aarch64 CC="aarch64-unknown-nto-qnx7.0.0-gcc" AR="aarch64-unknown-nto-qnx7.0.0-ar" RANLIB="aarch64-unknown-nto-qnx7.0.0-ranlib" --disable-examples CFLAGS="-DWOLFSSL_HAVE_MIN -DWOLFSSL_HAVE_MAX -DFP_MAX_BITS=8192"

You might consider adding `--disable-shared` so it is built statically. Then you can copy wolfcrypt/benchmark/benchmark to the target and run it.

Thanks,
David Garske, wolfSSL

68

(1 replies, posted in wolfSSL)

Hi Anika,

You can create a pull request in GitHub here: https://github.com/wolfSSL/wolfssl .
Then send an email to support@wolfssl.com requesting a contributor agreement to sign and return.
The pull request will be peer reviewed for coding standards and should also contain unit tests for any new code added.

Looking forward to seeing your changes, they sound useful.

Thanks,
David Garske, wolfSSL

69

(9 replies, posted in wolfSSL)

Hi MO380,

This means you have WOLFSSL_USER_IO defined, which requires setting your own TLS send/recv callbacks. If you remove WOLFSSL_USER_IO then it will attempt to use our default socket implementations in src/wolfio.c. These support POSIX and LWIP for example.

You can find examples for using the IO callbacks here:
https://github.com/wolfSSL/wolfssl-exam … aster/lwip

You can see our user manual section here:
https://www.wolfssl.com/documentation/m … sl_user_io

Thanks,
David Garske, wolfSSL

70

(1 replies, posted in wolfCrypt)

Hi Alex,

What ECC curve(s) are you trying to use? I assume NIST Prime 256-bit (SECP256R1)?

Please try with our single precision math and assembly options. This should make a greater than 10x improvement.

#define WOLFSSL_HAVE_SP_ECC
#define WOLFSSL_SP_ARM_CORTEX_M_ASM
#define WOLFSSL_SP_SMALL      /* use smaller version of code */

These are documented here:
https://www.wolfssl.com/documentation/m … th-support

We have a good section that covers our math options here:
https://www.wolfssl.com/documentation/m … th-options

Thanks,
David Garske, wolfSSL

Hi Sushanth,

Thanks for your interest in using wolfSSL and TLS v1.3 on the STM32 targets.

* STM32F407VGT6 Cortex-M4, 1-Mbyte Flash and 192 KB RAM
* STM32G431xB Cortex-M4, 170 MHz, 128-KB Flash and 22 KB RAM

Roughly a TLS v1.3 only client session takes about 70KB flash and 20 KB RAM. These are rough estimations and I recommend you try for yourself.

Our STM32Cube pack makes it easy to evaluate in the STM32CubeIDE. See https://github.com/wolfSSL/wolfssl/tree … /STM32Cube

We have some TLS v1.3 only examples here:
https://github.com/wolfSSL/wolfssl-exam … nt-tls13.c

For building with reduced code size and memory usage see this section of the user manual:
https://www.wolfssl.com/documentation/m … code-usage
https://github.com/wolfSSL/wolfssl/blob … e.ac#L1735

I recommend using an ECC only build (disable RSA/DH), since it uses much less memory.

Looking forward to hearing your progress. If you can send a note to support@wolfssl.com and tell us more about your project that would be wonderful.

Thanks,
David Garske, wolfSSL

Hi Alex,

Have you reviewed the BTLS example that uses ECIES here?
https://github.com/wolfSSL/wolfssl-exam … btle/ecies

The public key provided there is X.963 format, which is a small ASN.1 header and public X/Y (same format TLS uses). The public key is used to derive the shared secret used for encryption. It should be the public key provided by the peer.

Note: We have several ECIES modes. Perhaps you might consider one of these?
* yes = SEC1 standard (default)
* geniv = Generate IV (WOLFSSL_ECIES_GEN_IV)
* iso18033 = ISO 18033 standard (WOLFSSL_ECIES_ISO18033)
* old = original wolfSSL algorithm (WOLFSSL_ECIES_OLD)

Thanks,
David Garske, wolfSSL

Hi Akram,

My recommendation would be to get it working without static memory and use traditional heap first. Get that working then try using static memory. You are welcome to use my code snippets. You would inject that where you create the WOLFSSL_CTX with wolfSSL_CTX_new.

Let me know how it goes.

Thanks,
David Garske, wolfSSL

Hi khalesiakram,

Your issue is the static memory feature `WOLFSSL_STATIC_MEMORY`. This is an advanced feature that replaces the XMALLOC heap calls with a static pool. This requires additional configuration to support properly.


See documentation for this feature here:
https://docs.google.com/document/d/1nST … sp=sharing

Example for setting it up with TLS here:
https://github.com/wolfSSL/wolfssl/blob … nt.c#L2053

Code example:

byte memory[80000];
byte memoryIO[34500]; /* max for IO buffer (TLS packet can be 16k) */
WOLFSSL_HEAP_HINT *heap = NULL;

if (wc_LoadStaticMemory(&heap, memory, sizeof(memory), WOLFMEM_GENERAL, 1)
        != 0) {
    err_sys("unable to load static memory");
}

ctx = wolfSSL_CTX_new_ex(method(heap), heap);
if (ctx == NULL)
    err_sys("unable to get ctx");

    if (wolfSSL_CTX_load_static_memory(&ctx, NULL, memoryIO, sizeof(memoryIO),
        WOLFMEM_IO_POOL_FIXED | WOLFMEM_TRACK_STATS, 1) != WOLFSSL_SUCCESS) {
    err_sys("unable to load static memory");
}

You can configure the memory buckets using something like this:

#define WOLFSSL_STATIC_MEMORY
#define WOLFMEM_BUCKETS 64,256,384,432,512,1632,3456,16128
#define WOLFMEM_DIST 12,6,5,3,4,2,1,1
#define LARGEST_MEM_BUCKET 16128

Thanks,
David Garske, wolfSSL

Hi khalesiakram,

This typically suggests a math failure with the ECC shared secret due to a misconfigured stack. I would suggest a few things:
1) Increase your stack space on each board. In bare-metal this is done via the linker script.
2) Run the wolfCrypt test and verify all algorithms operate correctly. See: https://github.com/wolfSSL/wolfssl/blob … le.c#L1846

If that doesn't help please share your build settings (user_settings.h or wolfSSL.I-CUBE-wolfSSL_conf.h).

Thanks,
David Garske, wolfSSL