101 Reply by dgarske

(2 replies, posted in wolfTPM)

Hi François,

This is a great question! Currently our TIS layer uses polling to detect data ready, however some TPM's do have an interrupt pin available. I have the ST33 TPM and will look into adding this feature. Aside from the physical GPIO it will also depend on how the ST33 enables the IRQ pin use.

Until then another option is to implement a delay in the polling period using the `XTPM_WAIT` macro, which you can define like this 

#define XTPM_WAIT() usleep(1000)

.

If you do end up making changes to wolfTPM for IRQ support and would like to contribute them back, you are welcome to open a PR and sign a contributor agreement.

Thanks,
David Garske, wolfSSL

Go to forum: wolfTPM

102 Reply by dgarske

(16 replies, posted in wolfTPM)

Hi Roman,

Did you try a lower SPI bus speed like 2 MHz? With longer wires the SPI bus impedance will be high and not function correctly.

Thanks,
David Garske, wolfSSL

Go to forum: wolfTPM

103 Reply by dgarske

(16 replies, posted in wolfTPM)

Hi r-type,

Were you able to get wolfTPM working with the Asus E15028 (Nuvoton NPCT750) on a Pi? Make sure you have the SPI wait state build option enabled `WOLFTPM_CHECK_WAIT_STATE` or use the `./configure --enable-nuvoton` option. Note: I pushed a wolfTPM v2.3 release this week, which does have some Nuvoton Fixups.

Thanks,
David Garske, wolfSSL

Go to forum: wolfTPM

104 Reply by dgarske

(3 replies, posted in wolfCrypt)

Hi swapnil,

To be clear the default sizes of the static memory buckets are not tuned for your use-case. So you will want to supply custom buckets appropriately sized to optimize use.

Example:
#define WOLFMEM_BUCKETS=64,256,384,432,512,1632,2976,3456,16128
#define WOLFMEM_DIST=16,8,6,4,6,3,2,1,1"

You might also try: #define ALT_ECC_SIZE or if use ECC only adjust your #define FP_MAX_BITS (256*2).

For debugging the sizes try using `WOLFSSL_DEBUG_MEMORY`.

Thanks,
David Garske, wolfSSL

Go to forum: wolfCrypt

105 Reply by dgarske

(3 replies, posted in wolfSSL)

Hi Mor71,

Thank you so much for this report! I was able to reproduce and locate the server side bug. I've put up a fix here:
https://github.com/wolfSSL/wolfssl/pull/4509

Let me know if you continue to see any issues.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

106 Reply by dgarske

(3 replies, posted in wolfSSL)

Hi Mor71,

Thank you for the report. I am trying to setup a use-case to reproduce. If you have any further tips you can share please do. If you'd like to keep the details private you can email support@wolfssl.com and reference this forum post.

I will share my results shortly.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

107 Reply by dgarske

(3 replies, posted in wolfSSL)

Hi Elliot,

To be clear, wolfSSL does not require an RTOS. In the generated configuration if no RTOS is selected it will define SINGLE_THREADED. It is only our TLS in-memory example since it starts multiple threads, although even that could be written non-blocking and used in bare-metal with shared memory.

Let us know if you have any questions. It would be great to hear more about your project so we can best support you.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

108 Reply by dgarske

(3 replies, posted in wolfSSL)

Hi Elliot,

Please see this link:
https://github.com/wolfSSL/wolfssl/tree … /STM32Cube

The built-in example in IDE/STM32Cube/wolfssl-examples.c allows running the wolfCrypt test/benchmark and also an in-memory TLS cipher suite test (requires RTOS, with lots of heap and stack).

The wolfSSL cube pack pulls in the wolfSSL/wolfCrypt files and generates a configuration file `wolfSSL.I-CUBE-wolfSSL_conf.h`. This is included automatically with wolfssl/wolfcrypt/settings.h.

If you wanted to pull in your own TLS example from https://github.com/wolfSSL/wolfssl-exam … master/tls just make sure it includes "wolfssl/wolfcrypt/settings.h" instead of wolfssl/options.h.

To use LWIP socket interface add the build option WOLFSSL_LWIP. Or setup your own IO callbacks using WOLFSSL_USER_IO and setting them with `wolfSSL_SetIORecv` or `wolfSSL_SetIOSend` like in the https://github.com/wolfSSL/wolfssl-exam … callback.c example.

If you need to customize the generated configuration the easiest option is to rename "wolfSSL.I-CUBE-wolfSSL_conf.h" to "user_settings.h" and add build option WOLFSSL_USER_SETTINGS to your CFLAGS pre-processor macros.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

109 Reply by dgarske

(16 replies, posted in wolfTPM)

Hi r-type,

That is a great little module ASUS has for their motherboard. The steps you listed for wolfTPM with direct /dev/spi access looks great. Make sure you have the right SPI chip select. The PI has two and they are "/dev/spidev0.0" and "/dev/spidev0.1". The modules Nuvoton provides for the Pi use CS0 (Pin 24).

Also the reset line is active low, so if pulled low it will hold in reset, so make sure it is high. Also you should make sure you have a pull-up on the Chip Select pin to make sure it is only active when the Pi drives it. I would leave the IRQ line alone and not tie to anything. Use 3.3v for VCC.

Thanks,
David Garske, wolfSSL

Go to forum: wolfTPM

110 Reply by dgarske

(2 replies, posted in wolfMQTT)

Hi Seyyed,

As I understand it the SIM800 is a UART based TCP modem? We've done customer projects using the SIM800, but I do not have an example available.

We have a template for what that would look like in wolfMQTT here: https://github.com/wolfSSL/wolfMQTT/blo … mqttuart.c

Let us know if you have any questions.

Thanks,
David Garske, wolfSSL

Go to forum: wolfMQTT

111 Reply by dgarske

(7 replies, posted in wolfSSL)

Hi raghu,

I also had that issue at first. Make sure you've pulled that branch and reconfigured your cmake. You might even need to delete wolfssl/options.h.

git fetch origin pull/4368/head:cmake_cflags
git checkout cmake_cflags
rm wolfssl/options.h
rm -rf build
mkdir build
cd build
cmake -DCMAKE_C_FLAGS="-DWOLFSSL_AESGCM_STREAM" ..
make

Let us know if that does not help.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

112 Reply by dgarske

(7 replies, posted in wolfSSL)

Hi Raghu,

This sounds like a build configuration issue. If building with ./configure it generates a wolfssl/options.h with settings. It looks like our CMakeLists.txt also does this. Assuming you have `HAVE_AESGCM` and `WOLFSSL_AESGCM_STREAM` in the generated options.h, the next item to check is the include at the top of wolfcrypt/test/test.c is including wolfssl/options.h, which it does if WOLFSSL_USER_SETTINGS is not defined.

I don't see your options.h attached, so I am unable to confirm.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

113 Reply by dgarske

(1 replies, posted in wolfCrypt)

Hi ACV,

You can instead call `wolfCrypt_Init` and `wolfCrypt_Cleanup`. For most use-cases you are not required to call these, but I recommend it to future proof yourself.

Thanks,
David Garske, wolfSSL

Go to forum: wolfCrypt

114 Reply by dgarske

(3 replies, posted in wolfCrypt)

Hi ACV,

Thanks for those details and I agree the RISC-V stuff there is very SiFive specific.

My best pointer is the user_settings_template.h file here: https://github.com/wolfSSL/wolfssl/blob … template.h
It explains each build option.

Let me know if you need details on any specific build options. Many of these are covered in the user manual chapter 2. https://www.wolfssl.com/docs/wolfssl-manual/ch2/

Thanks,
David Garske, wolfSSL

Go to forum: wolfCrypt

115 Reply by dgarske

(3 replies, posted in wolfCrypt)

Hi ACV,

Have you seen our RISC-V examples here? https://github.com/wolfSSL/wolfssl/tree … /IDE/RISCV

To build wolfCrypt only you can define `WOLFCRYPT_ONLY` and compile the source files in wolfcrypt/src/*.c that are applicable. If you are not cross-compiling with ./configure I would recommend defining CFLAG -DWOLFSSL_USER_SETTINGS and adding your own `user_settings.h` file. Your include path needs to be in the wolfssl root. Then in your application make sure you include wolfssl/wolfcrypt/settings.h prior to any other wolfSSL headers.

We have some user_settings.h examples here:
https://github.com/wolfSSL/wolfssl/tree … es/configs

This is also covered in the FAQ here:
https://www.wolfssl.com/docs/frequently … r_wolfSSL?

Let us know if you have any issues.

Thanks,
David Garske, wolfSSL

Go to forum: wolfCrypt

116 Reply by dgarske

(9 replies, posted in wolfSSL)

Hi tomris,

See https://github.com/wolfSSL/wolfssl/issues/4319
Similar report. Please try those suggestions.

Make sure `USE_HAL_DRIVER` is added to CFLAGS like "-DUSE_HAL_DRIVER" to include `wolfSSL.I-CUBE-wolfSSL_conf.h`. Also make sure you change you include so it does not use options.h and instead uses wolfssl/wolfcrypt/settings.h.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

117 Reply by dgarske

(9 replies, posted in wolfSSL)

Hi Tomris,

I have not yet tried using the "Makefile" code generation option in CubeMX with the wolfSSL pack. Can you share your Makefile as reference?

To work around this I suggest adding your own `MX_wolfSSL_Init` and `MX_wolfSSL_Process` API's that call `wolfSSL_Init()` and `wolfSSL_Cleanup()`.

Next time I am working on the Cube pack I will test with Makefile generation and see if there are improvements we can make.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

118 Reply by dgarske

(9 replies, posted in wolfSSL)

Hi Tomris,

Do you have a `main` function defined in your code? The `int main(void)` is an entry point required by the startup code. When you use the STM32 Cube back for wolfSSL it allows you to choose the wolfSSL/wolfCrypt features, but you would need to provide the code to call our API's. We have a wolfCrypt test demo that can be enabled also in the pack selections. What IDE are you generating code for? I have only tested with STM32CubeIDE, Keil and IAR.

You can find some great examples in this repo:
https://github.com/wolfSSL/wolfssl-examples

For LWIP we support their socket interface by default if you add `WOLFSSL_LWIP` to the generated configuration file `wolfSSL.I-CUBE-wolfSSL_conf.h`.

The documentation or the Cube pack is here:
https://github.com/wolfSSL/wolfssl/tree … /STM32Cube

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

119 Reply by dgarske

(2 replies, posted in wolfSSL)

Hi oloke5,

We have some great user setting templates here:
https://github.com/wolfSSL/wolfssl/tree … es/configs

Please try adding `WOLFCRYPT_ONLY`. This will enable only wolfCrypt and disable the TLS/SSL layer.

For ED/Curve I recommend using:

#define HAVE_CURVE25519
#define HAVE_ED25519
#define CURVED25519_SMALL

For AES 256-bit CTR only try:

#define WOLFSSL_AES_COUNTER
#define NO_AES_128
#define NO_AES_192
#define NO_AES_CBC

Let me know if you have any issues.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

120 Reply by dgarske

(7 replies, posted in wolfTPM)

Hi Messias,

Our support for Windows TBS has been tested on Windows 10. Can you tell us the compiler and exact Windows version? It is possible the toolchain being used doesn't have the tbs.h with TBS_HCONTEXT, but I am not sure why.

You can see our TPM code for windows in src/tpm2_winapi.c where it includes the required headers:

#include <windows.h>
#include <tbs.h>

We will do some additional testing here and see if we can find any issues.

Thanks,
David Garske, wolfSSL

Go to forum: wolfTPM

121 Reply by dgarske

(3 replies, posted in wolfSSL)

Hi ENOTTY,

The FP_MAX_BITS can be overridden as a build-time pre-processor macro and should be set to double the max RSA/DH key size. So for 4096-bit it should be `-DFP_MAX_BITS=8192` or `./configure CFLAGS="-DFP_MAX_BITS=8192` or `#define FP_MAX_BITS 8192`.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

122 Reply by dgarske

(2 replies, posted in wolfSSL)

Hi Noufal,

Seems like the issue is with the path to `cryptoauthlib`. I don't see any wolfSSL build errors. Are you trying to use the ATECC with wolfSSL?

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

123 Reply by dgarske

(7 replies, posted in wolfMQTT)

Hi Kelvin,

Thanks for this report. We are trying to reproduce and should get back shortly with a fix.

David Garske, wolfSSL

Go to forum: wolfMQTT

124 Reply by dgarske

(2 replies, posted in wolfTPM)

Hi François,

You can enable IO level debugging inside wolfTPM using `./configure --enable-debug=io`. The command code TPM_CC_GetRandom is `0x0000017B`. The command also includes a 16-bit request size at the end. The ST33 uses a SPI wait state, so the header is 4 bytes and a single byte is read until the 0x80 MSB is set. Then a tag, command size and command code are added.

b d4  0 24 /* header */
b  b  b /* ready bytes */
80 1  TAG 
0 0  0 c  SIZE
0  0  1 7b  COMMAND
0 20 Arguments (bytes requested)

Thanks,
David Garske, wolfSSL

Go to forum: wolfTPM

125 Reply by dgarske

(4 replies, posted in wolfSSL)

Hi Scott,

I put up a PR with the `wolfSSL_CTX_load_verify_buffer_ex` API documentation. Thanks for reporting that.
https://github.com/wolfSSL/wolfssl/pull/4161

David Garske, wolfSSL

Go to forum: wolfSSL