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,

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,

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,

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

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

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

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 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

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 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 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 Alex,

That comment is not very clear and I am sorry. It is referring to authentication specifically which is not handled in ECIES. The idea to hash the peers public key, sign it and send back is just an example for how to implement authentication. The important thing is to sign with a long term key, not the ephemeral key.

Thanks,
David Garske, wolfSSL