Hi Thomas,

-1 indicates that wolfSSL attempted to read from the socket and the read failed outright. Receive can return a non-read (0) which is not a failure, it is a successful read, but 0 bytes were waiting to be read. A -1 indicates an issue with the Receive methodology altogether, either the socket failed to be opened in the first place or there is a fundamental underlying error.

Have you registered your own IO callbacks or are you using our default "EmbedReceiveFrom" and "EmbedSendTo" functions?

Receive just calls whatever IOCallback Receive function was loaded with wolfSSL_SetIORecv API. If the user has not defined "WOLFSSL_USER_IO" and set their own callback function, then our default methods are loaded.

There are a number of reasons this could fail. What TCP/IP stack are you using? Are you checking all the return values when creating the socket? Are you confident the socket was successfully opened for TCP prior to calling wolfSSL_connect on the file descriptor?

Regards,

Kaleb

Hi hyongsop,

Ok this makes sense. Thanks for the info. By default our jni client example tries to load a Certificate Revocation List (CRL) to make sure your servers certificate is not an untrusted certificate. However our test CRL is related to our test ca-cert.pem You can either remove this code block from the test Client.java

343 //            ret = ssl.enableCRL(WolfSSL.WOLFSSL_CRL_CHECKALL);                
344 //            if (ret != WolfSSL.SSL_SUCCESS) {                                 
345 //                System.out.println("failed to enable CRL check");             
346 //                System.exit(1);                                               
347 //            }                                                                 
348 //            ret = ssl.loadCRL(crlPemDir, WolfSSL.SSL_FILETYPE_PEM, 0);        
349 //            if (ret != WolfSSL.SSL_SUCCESS) {                                 
350 //                System.out.println("can't load CRL, check CRL file and date " +
351 //                        "validity");                                          
352 //                System.exit(1);                                               
353 //            }                                                                 
354 //            MyMissingCRLCallback crlCb = new MyMissingCRLCallback();          
355 //            ret = ssl.setCRLCb(crlCb);                                        
356 //            if (ret != WolfSSL.SSL_SUCCESS) {                                 
357 //                System.out.println("can't set CRL callback");                 
358 //                System.exit(1);                                               
359 //            }

Or you can generate a CRL that is related to your new ca (certs/bc/x509-ca.pem). To see how we generate our test CRL please see the script in <wolfssl-root>/certs/crl/gencrls.sh.

Regards,

Kaleb

Hi Hyong,

Thank you for reaching out to us and using the wolfSSL forums!

I regret the wolfJNI package is only supported on Linux or Mach at this time. We placed that error intentionally as a sort of "hint" to that effect. We would be happy to explore a consulting effort to port to windows if you need it right away or are unable to port it yourself.

Unfortunately there is not enough demand from the community to justify prioritizing this effort above other paid work. We always desire to support our community and are torn we can not offer to do the port immediately. I hope you can appreciate our need to prioritize work accordingly.

I have added this to the list of requested features on your behalf. To prevent any confusion on the matter I feel obligated to express there is no delivery date associated with this request and our feature request list is quite long. It may be some time before we get around to supporting wolfJNI on windows.

Warmest Regards,

Kaleb

Hi Jinu,

See reply to zendesk ticket, but I just found out one of our engineers is currently working on a STM32F4 example, it has not made it into the repo yet. I'll get you an update when I have had a chance to touch base with him.

Warm Regards,

Kaleb

Hi Iguananaut,

Thank you for your feedback! We are always looking to improve our documentation and are very appreciative whenever we receive feedback of this nature from the community. I have updated that section in the manual to the following:

These changes will be reflected the next time the website is updated.

Warm Regards,

Kaleb

Hi mohammad,

If my understanding of your question was off I apologize. I am happy to hear the suggested API addressed your needs.

Warm Regards,

Kaleb

Hi mohammad,

To verify a given key you would use the API

wc_ecc_check_key(ecc_key* key);

which takes just the key as an argument. There is no need to extract curve/point for this.

A given point is not tied to any one curve, so to validate a key with a given point you need to already know which curve is being used to validate against. Therefore a curve can not be derived from a given point.

Could you tell us a little more about your project and the need to parse point to struct before calling "wc_ecc_check_key"?

Warm Regards,

Kaleb

Hi gavinfred,

One other note, we have a define for WOLFSSL_ARDUINO in <wolfssl-root>/wolfssl/wolfcrypt/settings.h that may be helpful if you hadn't seen that yet and also an issue here that might be helpful as well.

https://github.com/wolfSSL/wolfssl/issues/539

Regards,

Kaleb

Hi gavinfred,

We have not ported to the esp8266 yet. Have you had a chance to review our porting guide when building for a new platform?

https://wolfssl.com/wolfSSL/Docs-wolfss … guide.html

That will address all the issues you just noted:

.

See section:

.

See section:

Best Regards,

Kaleb

Hi mohammad.abomokh,

For example usage please see file <wolfssl-root>/wolfcrypt/test/test.c and in the "aes_test()" function see section wrapped in:

 #ifdef WOLFSSL_AES_COUNTER

Also including excerpt from "chapter 18: wolfCrypt API Reference" of the wolfSSL Manual: https://www.wolfssl.com/wolfSSL/Docs-wo … i-aes.html

Regards,

Kaleb

Hi cxdinter,

We have received a few inquiries of this nature over the years. To be absolutely clear let me express that this is

HIGHLY NOT RECOMMENDED by wolfSSL. This can open yourself up to attacks and in general is a bad idea. We can not express how strongly we do not recommend doing what you are requesting. To convey our concern let me provide a real world example.

A certificate belonging to the domain comehereforfreemoney.com is currently on the Certificate Revocation List (CRL) because if you visit that domain it will install a virus on your computer or do some other malicious thing. Once the certificate belonging to that domain expires it drops off the CRL and you can no longer tell it's a certificate belonging to a malicious domain by checking it against the CRL. You decide to trust it because you ignore the date and the CRL is checked and comes back with an OK status since that certificate is no longer tracked by the CRL. Your connection is allowed and you end up with a virus or other malicious behavior is performed due to the approved connection.

Now that you are briefed on the potential pitfalls of ignoring date checks:

Due to the requests over the years we have provided an example of doing this in <wolfssl-root>/wolfssl/test.h

The function "myDateCb" can be used as a model for achieving your desired use-case.
You would create your own custom callback similar to myDateCb and then register that "verify callback" with the API "wolfSSL_CTX_set_verify". Then whenever a verify is performed it will use your callback instead of the default one in wolfSSL.

Example:

int myCustomVerifyFunction(int preverify, WOLFSSL_X509_STORE_CTX* store);


int myCustomVerifyFunction(int preverify, WOLFSSL_X509_STORE_CTX* store)
{
    /* Model after myDateCb from <wolfssl-root>/wolfssl/test.h */
    /* return 1 for success */
    /* return 0 for failures */
}


... application code ...
wolfSSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, myCustomVerifyFunction);
... application code ...

Regards,

Hi khan92,

My apologies, I will also try to be clearer:

wolfSSL takes every effort to support any operating system and environment. We also make an effort to provide functionality that will allow any OS/environ we do not currently support, to be ported somewhat easily. To facilitate this portability, by default wolfSSL uses what is called a Custom In/Out Callback function(CustomIOCallback). The call chain is like this:

wolfSSL_read ->wolfSSL_read_internal -> ReceiveData -> (various paths) -> GetInputData -> Receive -> CustomIOCallback

You can register any custom IO callback you want to with the API's:

wolfSSL_SetIORecv(ctx, <your custom Receive function name here>);                                           
wolfSSL_SetIOSend(ctx, <your custom Send function name here>);

So to have wolfSSL_read be the equivalent of ANY input functionality, you write your custom IO receive callback to use the desired input functionality. In this case you desire wolfSSL_read to use a custom callback that calls readmsg() instead of some other input function.

I just opened a PR yesterday with example client and servers where wolfSSL_read actually reads out of a file and wolfSSL_write writes to a file. The client and server perform a TLS connection through the file system instead of using sockets. These examples are currently in a PR but should soon be merged. Please feel free to use them as a guide for your work.

https://github.com/wolfSSL/wolfssl-examples/pull/34

Warmest Regards,

Kaleb