Update: Pushed an example here to

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

52

(4 replies, posted in wolfSSL (formerly CyaSSL))

abbey,

No not at all! In fact that is exactly what ./configure is doing when you tell configure to "--enable-aesni" the configure script writes the option "#define WOLFSSL_AESNI" into the file "options.h" which is then consumed by the wolfSSL library to know the build settings to use.

Since SGX is using a makefile you just have to specify the same flags the ./configure script would output. So if you want SGX library to have the same settings as the configure you ran you can first run ./configure with the desired settings. Open wolfssl/options.h and copy each #define line into the SGX makefiles with a "-D" prepended instead of "#define ". (NOTE you have to update all three makefiles, the library and the two makefiles for the examples trusted and untrusted (sgx_t.mk == sgx trusted makefile and sgx_u.mk == sgx untrusted makefile).

Warm Regards,

K

Once

Does that mean that I just need to protect against multiple calls to wolfSSL_read() and multiple calls to wolfSSL_write() and so can have a separate mutex for each or do I also need to prevent a call to wolfSSL_write() while another thread is in wolfSSL_read() and vice-versa?

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 damian.slee,

In the wolfSSL bundle download there is file wolfssl-4.3.0/tests/api.c and a function test_wolfSSL_PKCS12 that shows creating a pkcs12 object (or pfx or .p12) from DER formatted certs.

Can you use that as a reference and let us know how it goes?

Thanks!

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,

David said to send you his contact info so you can reach him directly. Could you send a quick message to support [at] wolfssl [dot] com with a link to this forum case and I'll get you davids' contact info.

Warm 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

58

(4 replies, posted in wolfSSL (formerly CyaSSL))

abbey_chase,

Thank you so much for inquiring. By default aesni is not enabled in SGX but you should be able to turn it on by adding the appropriate defines in Wolfssl_C_Extra_Flags section of:

wolfssl-4.3.0/IDE/LINUX-SGX/sgx_t_static.mk
wolfssl-examples/SGX_Linux/sgx_t.mk
wolfssl-examples/SGX_Linux/sgx_u.mk

The setting to add would be:

Wolfssl_C_Extra_Flags := -DWOLFSSL_SGX
Wolfssl_C_Extra_Flags += -DWOLFSSL_AESNI # Add this setting to enable AESNI support

Let us know if you have any trouble getting it setup.

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

60

(2 replies, posted in wolfCrypt)

@RyVel,

wolfSSL already has checks for both integrity defines (__INTEGRITY) || (INTEGRITY) and has built in support. Can you clarify the issues you are seeing and your build process?

Can you also share a bit about the background of this project. If you need to guarantee faster turnaround on responses feel free to reach out to our support staff at support@wolfssl.com.

Warmest Regards,

K

61

(7 replies, posted in wolfCrypt)

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

62

(7 replies, posted in wolfCrypt)

juhuaguai,

Can you tell us a bit about the background of this project using .NET framework and solution setup?

Warm Regards,

K

63

(3 replies, posted in wolfCrypt)

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

Hi jpbland,

I checked with our team that worked on the ESP32 port and they clearly indicated AES in COUNTER mode was never ported and was not intended to be used on that hardware yet. It is something we may add support for in the future!

We are surprised to hear you were able to build with the setting WOLFSSL_AES_COUNTER given the port didn't include it in the effort. We are curious if you had to make any changes to get it to build or did it just compile cleanly?

Warm Regards,

K

65

(7 replies, posted in wolfCrypt)

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

Can you double check the compiler output, is it actually using that path the way you intend?

Also try running make clean first to ensure everything re-links and uses any updates to the makefiles.

67

(7 replies, posted in wolfCrypt)

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

akhi_gangwar,

Please make sure you include wolfssl/wolfcrypt/settings.h BEFORE all other wolfSSL headers so the settings are in place when the other headers get included.

Next instead of doing the whole path to zlib.h in the include line update your configuration to have C:\ti\TivaWare_C_Series-2.1.4.178\third_party\windows\fltk-1.1.10\zlib in the include path so that when #include "zlib.h" is compiled it can be located by the compiler.

You stated:

2. In the configure file (wolfssl\configure), I have given with_libz = C:\ti\TivaWare_C_Series-2.1.4.178\third_party\windows\fltk-1.1.10\zlib\zlib.h    where other things are given like enable_fastmath, enable_fasthugemath, enable_examples etc.
    I have zlib.h at the location provided above.

Notice how you have the header itself in the path there, try modifying that rule to simply:

2with_libz = C:\ti\TivaWare_C_Series-2.1.4.178\third_party\windows\fltk-1.1.10\zlib

and let us know if that resolves it.

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 mirfälltnixein,

Can you try including <wolfssl/options.h> before all other wolfSSL headers to prevent mis-configuration issues and let us know if that resolves these issues?

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

It's possible the curve isn't supported in the browser though unlikely. Can you capture a wireshark trace of the failed connection for review and evaluation?

Warm Regards,

K

73

(3 replies, posted in wolfCrypt)

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

Hi @ballsmahoney90,

The include path is a system path that includes various locations where a C compiler might look for headers for example if the system CFLAGS or PATH contains the directory /my/directory and inside of /my/directory there exists an "include" directory your system would have:

/my/directory/include

The C compiler would know about /my/directory so when a .c source file in your application has the directive "#include <myheader.h> the compiler will look for a file named "myheader.h" inside of /my/directory/include/ if it finds it the header will be included, if not an error will be reported.

I see you are running the "make command" as a sudo command too, this is a very bad idea as the resulting executables will all have root access and can only be executed by a root user. root also does not have the same paths as the local user so. Instead run ./configure then make without sudo and only once the application is built would you then want to do "sudo make install".

To help the C compiler find your user_settings.h you can update the CFLAG using the -I (capitol "eye" for Include) directive. For example if I have user_settings.h in /home/kaleb/work/test-location and my Makefile looks like below it won't be able to find my header:

CC=gcc
KALEBS_LIB_DIR=/home/kaleb/work/testDir/wolf-install-dir-for-testing
CFLAGS=-I$(KALEBS_LIB_DIR)/include -Wall
LIBS= -L$(KALEBS_LIB_DIR)/lib -lwolfssl

aes-file-encrypt: aes-file-encrypt.o
    $(CC) -o $@ $^ $(CFLAGS) $(LIBS) 

.PHONY: clean

clean:
    rm -f *.o aes-file-encrypt

Now to update my Makefile so it can find my user_settings.h in /home/kaleb/work/test-location

CC=gcc
KALEBS_LIB_DIR=/home/kaleb/work/test-location
CFLAGS=-I$(KALEBS_LIB_DIR)/include -Wall
LIBS= -L$(KALEBS_LIB_DIR)/lib -lwolfssl

aes-file-encrypt: aes-file-encrypt.o
    $(CC) -o $@ $^ $(CFLAGS) $(LIBS) 

.PHONY: clean

clean:
    rm -f *.o aes-file-encrypt

If you are trying to use a user_settings.h with the configure script I would not recommend that approach instead when using the configure script it will generate the file <wolfssl/options.h> which is the replacement for user_settings.h when building with ./configure.

Warm Regards,

K

Hi @4f20,

Thank you for posing on the wolfSSL forums, nobody on the wolfSSL staff has worked with HEW4 but we do have a Quick Start service we offer where we will port to your target environment for you and document the process for future work. Is this a service you would be interested in learning more about? If so can you tell us where you are located in the world so I can put you in touch with the right resource?

Warm Regards,

K