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

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

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

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

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

Hi Alex,

This does not sound right. When you create an ECC key it generates a public and private key pair. The public portion is sent across (in the clear is fine).

The ECIES scheme itself establishes a secure channel by generating ECC keys (ephemeral / one time use), exchanging public keys and deriving a shared secret. The shared secret is then used to derive a symmetric key used for the cipher (like AES-GCM or ChaCha20/Poly1305).

If you want to authenticate in your application then on first connection you create an ECC key used for long term and provide that public key and some nonce for the peer to sign. The nonce can be random data or even a hash of the messages exchanged so far. For this to work on-going each peer should store the public key used to identify the peer as trusted. And for every connection the peer must sign something new to prove it has the private key associated with the public key.

Thanks,
David Garske, wolfSSL

Hi Alex,

Yes that would work fine and is known as public key authentication. Just make sure you use a different key for authentication. Typically that key is generated one time and use for all future authentications. Each side would present something to sign to prove having the private key. ECC is a very good algorithm for this.

The X.509 just adds the ability to have a chain of trust, however the overhead for certificates is quite large.

Thanks,
David Garske, wolfSSL

FYI: As a followup we did add DTLS SRTP support via https://github.com/wolfSSL/wolfssl/pull/4755 in wolfSSL v5.2.0 on Jan 20, 2022

Hi lili,

See out wolfssl/test.h example for the PSK values:

/* identity is OpenSSL testing default for openssl s_client, keep same */
static const char* kIdentityStr = "Client_identity";

static WC_INLINE unsigned int my_psk_client_cb(WOLFSSL* ssl, const char* hint,
        char* identity, unsigned int id_max_len, unsigned char* key,
        unsigned int key_max_len)
{
    (void)ssl;
    (void)hint;
    (void)key_max_len;

    /* see internal.h MAX_PSK_ID_LEN for PSK identity limit */
    XSTRNCPY(identity, kIdentityStr, id_max_len);

    if (wolfSSL_GetVersion(ssl) < WOLFSSL_TLSV1_3) {
        /* test key in hex is 0x1a2b3c4d , in decimal 439,041,101 , we're using
           unsigned binary */
        key[0] = 0x1a;
        key[1] = 0x2b;
        key[2] = 0x3c;
        key[3] = 0x4d;

        return 4;   /* length of key in octets or 0 for error */
    }
    else {
        int i;
        int b = 0x01;

        for (i = 0; i < 32; i++, b += 0x22) {
            if (b >= 0x100)
                b = 0x01;
            key[i] = b;
        }

        return 32;   /* length of key in octets or 0 for error */
    }
}

These values need to be agree'd upon by both the server and client. You should use your own key.

I would also recommend setting your cipher suite list to just the PSK ones so the peer is forced to use PSK.

wolfSSL_CTX_set_cipher_list(ctx, "DHE-PSK-AES128-CBC-SHA256:ECDHE-PSK-AES128-CBC-SHA256");

The send size of 121 is a client_hello. As the client it starts the connection and sends the "client_hello" then it will try and read 5 bytes (the TLS header) then the remainder.

We have some good PSK and IO callback examples here:
https://github.com/wolfSSL/wolfssl-exam … callback.c
https://github.com/wolfSSL/wolfssl-exam … master/psk

Thanks,
David Garske, wolfSSL