Hi Ray,

Since your colleague tried the same test on Linux and wasn't able to see the performance delta that you did, my guess is that it is a difference in compilation options used by either OpenSSL and/or wolfSSL on those two different platforms.

The one that comes to mind is support for Intel AES-NI instructions.  Since you mentioned GHASH, you must be using an AES-GCM based cipher suite.  If OpenSSL had been compiled with AES-NI support on Windows but wolfSSL had not, that would explain the performance difference.  You can enable AES-NI support when compiling wolfSSL by defining WOLFSSL_AESNI.  This assumes that you are on an Intel processor with AES-NI support, and that your toolchain supports the AES-NI intrinsics.

Best Regards,
Chris

Hi LimeD,

Great!  Glad that helped clear things up.

Best Regards,
Chris

The way the 3SHAKE attack used Secure Renegotiation and session resumption is a protocol (or feature) level vulnerability.  This means that it affects any implementation that supports Secure Renegotiation.

wolfSSL's I/O callbacks are prototyped by the following:

int (*CallbackIORecv)(WOLFSSL *ssl, char *buf, int sz, void *ctx);
int (*CallbackIOSend)(WOLFSSL *ssl, char *buf, int sz, void *ctx);

Whenever wolfSSL needs additional data to advance its internal state machine, it will call the RECEIVE callback. The job of the RECEIVE callback is to place data into the provided buffer “buf”. wolfSSL asks for “sz” bytes of data, but if the callback has less data than requested, it can copy the number of bytes it has available into “buf” and return the number of bytes that have been written.

Whenever wolfSSL needs to send data in order to advance its internal state machine, it will call the SEND callback. The job of the SEND callback is to send the data in the buffer “buf” to the peer. The number of bytes in “buf” is given to the callback through the “sz” parameter. If the callback is only able to send part of the data in “buf”, it should return the number of bytes that were sent. wolfSSL will internally loop back around and call the callback again to get the rest of the data.

The third thing that comes into play with the I/O callbacks is the associated context (void *ctx). This can be a pointer to anything the user would like handed back to them during the I/O callbacks. Oftentimes this is a custom structure that would hold a pointer to data buffers, data sizes, socket handles, or in your case information necessary to send/receive data over your UART connection.

These I/O callback “contexts” can be set by the application using:

void wolfSSL_SetIOReadCtx( WOLFSSL* ssl, void *ctx);
void wolfSSL_SetIOWriteCtx(WOLFSSL* ssl, void *ctx);

From your last post, it sounds like in your case, your UART might buffer data when received, then in the wolfSSL Receive callback, you would simply copy data from the buffered area to wolfSSL’s internal buffer in the callback.

Does this make sense?  Is there anything that needs clarifying?

Best Regards,
Chris

This issue is being handled through the wolfSSL support channel instead.  Copying ECDSA signature size information here for reference:

Chris

Hi Sam,

Once you have a DSA key in PEM format, you can convert it to DER format using the OpenSSL command line utility:

openssl dsa -inform PEM -in dsa2048.pem -outform DER -out dsa2048.der

You could then use the gencertbuf.pl script we have in the root wolfSSL directory to convert the .der file to a C-style array.  You will need to modify the fileList_1024[] or fileList_2048[] array in gencertbuf.pl to add in your .der file, then run the script.  It will place a C array by the name specific in the file <wolfssl_root>/wolfssl/certs_test.h.

Best Regards,
Chris

Hi Semih,

Can you try enabling the "supported curves" extension when compiling wolfSSL?  We recently noticed that this is required to connect to some implementations using an ECC based cipher suite.

You can enable this using the "--enable-supportedcurves" ./configure option, ie:

./configure --enable-supportedcurves

Thanks,
Chris

Hi windsp,

wolfSSL does certificate validation internally during an SSL/TLS connection.  If you need to validate certain peer certificates manually during the SSL/TLS handshake you can do so by registering your own verify callback as the third parameter when calling wolfSSL_CTX_set_verify().  By default the verify callback will only be called upon validation failure unless WOLFSSL_ALWAYS_VERIFY_CB is defined.

If you instead are looking to validate certificates standalone from an SSL/TLS connection, you can use the wolfSSL CertManager functionality.  These functions are found in <wolfssl/ssl.h>.  You can view the API docs at the following URL [1], as well as a simple example [2].

Best Regards,
Chris

[1] https://wolfssl.com/wolfSSL/Docs-wolfss … nager.html
[2] https://github.com/wolfSSL/wolfssl-exam … ertmanager

Hi lwatcdr,

I just posted a response to your other thread related to this topic:
http://www.yassl.com/forums/topic761-der-to-rsakey.html

Best Regards,
Chris

Hi,

We don't place any restrictions on the format of the I/O read and write contexts.  Your application doesn't even need to register them if you don't need to use them.  The context is simply a pointer, which can be a pointer to anything you want. 

We don't currently have an example of using the I/O callbacks with memory buffers.  If you were using memory buffers, you might have your own custom structure which contains pointers to buffers and members to hold sizes of the buffers.  When your I/O callbacks were called by wolfSSL, your callback could then access the context to get information about your own buffers.

Does this help?  Can you share any details about your project?

Best Regards,
Chris