Hi Ray,

Our compatibility layer has been designed to make it easier to port OpenSSL-based applications over to wolfSSL, but given that we map them to our internal wolfSSL API, not all functionality may be exactly the same.  Instead of returning a pointer to a static buffer, wolfSSL's ERR_error_string() will return a pointer to a static constant string "Please supply a buffer for error string".

We don't have a complete list of compatibility gaps, but will help answer your questions if you encounter them in your porting effort.  Our OpenSSL compatibility layer also only contains about 10% of the function in OpenSSL, and is a "work in progress" as we do more ports into existing OpenSSL-based applications.

Our preference, and recommendation for new applications is to use the native wolfSSL API.

Thanks,
Chris

Hi,

Are you using Micrium's uC-OS?  If not, can you find where NET_SECURE_MGR_CFG_EN is getting defined?  I just want to make sure you're using the correct XMALLOC for your environment.

As I noted above, sometimes Google's certificates can be very large.  Have you tried connecting to the wolfSSL example server which comes with the wolfSSL package?

Best Regards,
Chris

Sounds like an interesting project!  If you end up releasing something publicly, you should drop us a link so we can check it out!

Best Regards,
Chris

Hi,

The code you specified above is specific to our Micrium uC/OS build, which I'm guessing you're probably not using.  Your IDE may have just found the wrong XMALLOC define when you searched for the macro being called.

But it does sounds like you are running out of memory if XMALLOC is failing.  Sometimes the Google certs get fairly large (I've seen up to 11kB for a single cert).  If you are using the normal big integer math library, with 2048-bit RSA keys, expected stack usage should be around 7kB, with heap usage around 17kB.

In addition to those numbers, wolfSSL's I/O buffer can grow up to 16kB (on the heap).  This I/O buffer starts at 1kB, then grows and shrinks as needed.  The maximum SSL/TLS record size is defined as 16kB.  You may be able to reduce this using the Maximum Fragment Length Extension, which let's you specify a smaller maximum record size to use.

We put out a blog post about the Maximum Fragment Length Extension a while back, which can be found here:
http://www.yassl.com/yaSSL/Blog/Entries … yaSSL.html

API documentation for those functions can be found here:
http://www.yassl.com/yaSSL/Docs-cyassl- … sions.html

Best Regards,
Chris

Glad to hear you got it figured out!  Do you mind if I ask what kind of project you are working on with CyaSSL?

Thanks,
Chris

Hi Martin,

You can find the wolfSSL embedded SSL Porting Guide at the following URL, which should cover areas of the wolfSSL codebase which may need modification without an OS, or when porting to a new environment:

http://www.yassl.com/yaSSL/Docs-cyassl- … guide.html

We don't currently have support for integrating the wolfCrypt crypto primitives into the STM32 HAL drivers, but it's something which is on our desired feature list.

Best Regards,
Chris

Hi Demetri,

FP_MAX_BITS applies to EDH as well as RSA.  If you have FP_MAX_BITS already set to 8192, you will be able to support ephemeral DH up to 4096 bit as well.

Best Regards,
Chris

Hi Demetri,

Yes, including the options.h header should be common practice in applications using wolfSSL embedded SSL.  I'll take a look at our docs and see where we can make this more clear to end users.

Sounds like an interesting project!  When you put out a release, do you mind sending us a link?  Not only would it be interesting to look over, but we'd be willing to add your project to our Community page as well (http://wolfssl.com/yaSSL/Community.html).  If so, an email to info@wolfssl.com would be best!

Thanks,
Chris

Hi Jonas,

There are some additional defines that we use together with CYASSL_LEANPSK.  From configure.ac, inside of the leanPSK section, the complete list is:

-DCYASSL_LEANPSK -DHAVE_NULL_CIPHER -DSINGLE_THREADED -DNO_AES -DNO_FILESYSTEM -DNO_RABBIT -DNO_RSA -DNO_DSA -DNO_DH -DNO_CERTS -DNO_PWDBASED -DNO_DES3 -DNO_MD4 -DNO_MD5 -DNO_ERROR_STRINGS -DNO_OLD_TLS -DNO_RC4 -DNO_WRITEV -DNO_SESSION_CACHE -DNO_DEV_RANDOM -DCYASSL_USER_IO -DNO_SHA -DUSE_SLOW_SHA

I think adding NO_CERTS may solve your issue, but you may need to add some (or all) of the others as well.  Let us know if that works.

Thanks,
Chris

Hi Jerry,

Last time we tested CyaSSL against FreeRTOS v8 in house, I believe it was using heap_2.c.  CyaSSL's current FreeRTOS port (when FREERTOS is defined) has relied upon the user having the standard malloc(), free(), and realloc() available.

To be correct, we should probably change our FreeRTOS port to use pvPortMalloc() and pvPortFree() instead.  This is on our list of things to do.

In the meantime, CyaSSL does have a memory abstraction layer which allows users to register their own memory functions for CyaSSL to use.  This could be used to inform CyaSSL of the specific FreeRTOS memory functions you would like it to use.  More details can be found here:

CyaSSL Manual, Section 5.1.1.1: http://www.yassl.com/yaSSL/Docs-cyassl- … ility.html
CyaSSL API Reference, Section 17.10: http://www.yassl.com/yaSSL/Docs-cyassl- … ction.html

Best Regards,
Chris

Hi Melek,

We just added a function to wolfSSL which converts an ecc_key to DER format:

int wc_EccKeyToDer(ecc_key* key, byte* output, word32 inLen)

You can grab our latest code from GitHub, here: https://github.com/wolfSSL/wolfssl

This change was added with the following commit:

https://github.com/cyassl/cyassl/commit … f524f0bf94

Best Regards,
Chris