Update: Pushed an example here to

https://github.com/wolfSSL/wolfssl-exam … e86f32R144

To better clarify wolfSSL, for embedded design reasons, uses a single I/O buffer since TLS packets can be up to 16k we thought it unreasonable for resource constrained devices to have to maintain 32k for thread safe reads and writes, the overhead was too much. Because there is only one buffer used for both sending and receiving send calls can corrupt data that is not yet read. Similarly read calls can corrupt data that is not yet sent. A single mutex should be used to protect against both wolfSSL_read and wolfSSL_write calls on the same SSL object.

For blocking setups we added a feature called "write duplicate". This is where you use one SSL object to connect to a server. Once the connection is established and the handshake is complete you can make a duplicate of the SSL object for writing only. Then the first SSL object becomes a read only object. This gives a solution for the scenario SieRaybould noted but also adds that overhead of 32k for thread safe reading and writing. See wolfSSL_write_dup(ssl); for creating a write duplicate of an SSL object.

Warm Regards,

K

Hi ashetty,

It looks like the errors are completely unrelated to wolfSSL however one can link a shared object by using the following in your make file (this makefile assumes your application is named "test_app.c" just change to fit your test application name eipasm.c or whatever:

CC=gcc
WOLFPATH=/Users/kalebhimes/work/testDir/wolf-install-dir-for-testing
CFLAGS=-I$(WOLFPATH)/include -Wall
LIBS= -L$(WOLFPATH)/lib -lwolfssl

all: test_app

test_app: test_app.o
    $(CC) -o $@ $^ $(CFLAGS) $(LIBS)

.PHONY: clean

clean:
    rm -f *.o test_app

Regards,

K

Mircea,

Absolutely we'll keep it in mind and thank you for offering to test once we start work. I'm going to send my colleague david a message that you are interested in testing as he will be heading the effort!

Warm Regards,

K

Hi mircea,

Thank you so much for reaching out with this question. As luck would have it yes we have it on our roadmap with work to start in the next week or so! Great timing on your inquiry!

If there is anything else the wolfSSL team can assist with just let us know.

Warm Regards,

K

Juhuaguai,

We would very much appreciate knowing if the project is commercial, open source, hobby, personal research etc to better classify the inquiry. Can you share a bit about the background of the project and what drove this work?

Thanks!

Warm Regards,

K

zaliumz92,

Can you tell us a little bit about the background of this project and what is driving the effort? Thanks!

We have an example in the user_settings.h header in wolfssl-4.3.0/IDE/GCC-ARM/Header/user_settings.h (the arduino build similarly uses a user_settings.h setup)

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

Then implement the function "my_time(unsigned long* timer);" at the application level to return whatever the current tick-count is by calling millis() and converting the milli seconds to seconds.

int seconds = (int)((millis / 1000) % 60);
// source of function: https://stackoverflow.com/questions/17624335/converting-milliseconds-to-minutes-and-seconds

Warm Regards,

K

juhuaguai,

I went over this with the team and unfortunately we don't have any examples lying around, can you send a short complete test app that can be compiled and run with the commands:

$ gcc test.c -o run-test -lwolfssl
$ ./run-test

Also note that you are only setting the e,d, and n, you're missing some elements of the private key also (p, q, dP, dQ, u).

Warm Regards,

K

Hi juhuaguai,

I do not believe we have any examples showing the use of the WOLFSSL_RSA data structure being used in this way. One could use the internal RsaKey structure and possibly wc_RsaPublicKeyDecode to accomplish what you are attempting but let me check with the team tomorrow in a meeting and see if any of our other engineers have an example of using the WOLFSSL_RSA data structure in this way.

Warm Regards,

K

ballsmahoney90,

I apologize if you didn't see the last sentence or if it was unclear. Do not use user_settings.h when using the ./configure command. Instead just have your application include <wolfssl/options.h> which is automatically generated by the configure script.

user_settings.h is ONLY used when ./configure is not available.

Warm Regards,

K

Hi jpbland,

Thank you so much for reaching out about this issue and for the report. I am checking with our team that worked on the Espressif hardware port, it's possible there is simply a bug in the handoff to the hardware given this is AES-CTR mode (a less common mode). Have you tested with AES-GCM or AES-CBC modes and hardware crypto support enabled? Do those modes work and only AES-CTR mode is not working?

Warm Regards,

K

Hi @zaliumz92,

Have you had a chance to read through the porting guide for wolfSSL here? https://www.wolfssl.com/docs/porting-gu … y34rv6vyt5 (Link to specifically the TIME section). When XGMTIME and XTIME are not defined you need to track down a library for your device that provide the "time()" and "gmtime()" functions. If there is not an existing library that provides time functionality for your device you can write your own and then add the following to user_settings.h

#define WOLFSSL_GMTIME // Use the wolfSSL GMTIME solution
 #define USER_TICKS
 extern unsigned long my_time(unsigned long* timer);
 #define XTIME my_time
// Make sure that "my_time" returns second accuracy, doesn't have to be epoch related