Hi Fred,

Requests for adding support for new hardware crypto modules come from both manufactures as well as individual companies/developers.

I'll send you an email to continue the conversation.

Best Regards,
Chris

Case moved to email support.

Hi Blink,

wc_ecc_make_key() generates both the private and public key.  You can export the public key using the following function:

int wc_ecc_export_x963(ecc_key*, byte* out, word32* outLen);

A good usage example is the ecc_test() function inside the wolfCrypt test app (<wolfssl_root>/wolfcrypt/test/test.c).

Best Regards,
Chris

Hi Midas,

Can you verify that you are compiling your application with the same preprocessor defines used to compile the wolfSSL library?  A simple way to do this if you used the autoconf/configure system to build wolfSSL is to include the <wolfssl/options.h> header in your application code, ie:

#include <wolfssl/options.h>

Best Regards,
Chris

Hi Sudhakar,

Currently the only example project files that ship with wolfSSL are the CodeWarrior project files located under the <wolfssl_root>/mqx directory.  These were written for CodeWarrior in combination with the TWR-K70F120M platform.

If you download wolfSSL from our website and use it directly in your application, you can reference the wolfSSL Manual for documentation purposes:

https://www.wolfssl.com/wolfSSL/Docs-wo … l-toc.html

Freescale also has put together a CyaSSL Patch for KSDK which includes an evaluation version of CyaSSL in addition to an example HTTPS server using the RTCS web server (httpsrv_ssl_<platform>).  You can download this from the download link at:

www.freescale.com/ksdk

Freescale has a blog post explaining getting the httpsrv_ssl example up and running on a FRDM-K64F platform here:

https://community.freescale.com/message/469137#469137

Best Regards,
Chris

Hi Steve,

Nothing immediately sticks out at me as being incorrect in your above post.

Best Regards,
Chris

Hi Steve,

wolfSSL uses C_EXTRA_FLAGS with our ./configure system instead of CFLAGS.  Can you try appending your options to C_EXTRA_FLAGS instead?

We do this since at certain points we overwrite the default CFLAGS variable.

Best Regards,
Chris

Hi Matan,

By default, wolfSSL has an Input and Output buffer that are 5 bytes.  These grow and shrink using dynamic memory as SSL/TLS records are received or sent - growing up to a maximum of 16kB each.

If your application is only going to be doing one simultaneous read or write over SSL, you will only be using a maximum of 16kB.  If you will have two threads, both doing SSL/TLS, and may be doing a read and write at the same time, you could potentially get up to 32kB at a time.

Unfortunately, I don't have much experience with SMTP.  A while back, we did have a open source user integrate CyaSSL (now wolfSSL) into ssmtp.  His code can be found here:

https://github.com/tony2001/ssmtp

Best Regards,
Chris

Hi Matan,

The typical footprint size of wolfSSL with an embedded optimized compiler is around 60kB of Flash.  The smallest embedded SSL build we have done to date is our "LeanPSK" build which came in at around 21kB of Flash.  This was a very stripped down version of the library - supporting only TLS 1.2, pre-shared keys, and SHA256.

RAM usage is between 1-36kB per SSL/TLS session, as outlined in the attached Resource Use document.

Your understanding of the TLS Max Fragment Length extension is correct - the client can request that a smaller TLS maximum fragment length be used, but if the server doesn't support that extension, it is ignored.

The SSL/TLS spec defines the maximum possible record size to be 16kB, which makes reducing it challenging unless you have the ability to use the above extension.

We have had people use us with the uIP stack, but haven't used it in house before to my knowledge.  We have a I/O abstraction layer that allows you to write your own Input and Output callbacks.  This would allow you to run wolfSSL over any transport medium you choose.

The Resource Use document should be helpful, as well as taking a look into our LeanPSK build.  Do you know if there are certain cipher suites and protocols you need to use?

Best Regards,
Chris

Hi Jori,

After you've created a CSR with wc_MakeCertReq(), you can call wc_SignCert() to sign it with a CA key.  See <wolfssl_root>/wolfcrypt/test/test.c for an example.

Best Regards,
Chris

Hi Hemanth,

Using PSK will reduce the footprint size of the library significantly, but you'll need to have a framework in place to pre-distribute and manage the keys on your end devices.  Our "LeanPSK" build is the smallest build we have done to date.  Last time we compiled it on an optimized, ARM compiler, it had a footprint of around 21kB.  To compile the leanPSK build using the ./configure system, you can use the "--enable-leanpsk" build option.

If you don't want to use PSK, some things which will reduce footprint of a normal RSA or ECC build include:

1)  Define NO_OLD_TLS - this will eliminate all protocol versions except TLS 1.2 and reduce the library size by a few kB.

2)  Define NO_SESSION_CACHE - this will disable the session cache (as long as you don't need it) and will reduce the library size by a few more kB.

3)  Disable un-needed algorithms and ciphers.  For example, you could disable 3DES by defining NO_DES3

4)  If you only need to use ECC, you can compile out RSA by defining NO_RSA.  And, along these lines, you can define ECC_TIMING_RESISTANT, which cuts the heap usage in half and reduces the code size, but ECC operations are twice as slow.  Using ECC keys will save you memory, since ECC keys are much smaller than RSA keys at the same security level.

5)  If you are on an embedded platform which has hardware cryptography, this can reduce footprint size.  For example, AES has tables that take about 10kB, which are eliminated when offloaded into hardware.

Best Regards,
Chris