501

(5 replies, posted in wolfSSL)

Hi gussabina,

I never heard back from you so here is my educated guess of what is occurring. You stated the ATSAM4E has AES hardware crypto engine available so I bet the headers for that device have API's that provide access to that crypto engine (and also an Aes Structure definition that you are getting a conflict with). You would need to reference one of our existing pre-processor macros where we have added hardware support for other devices. One good one would be

STM32F2_CRYPTO

.

By referencing that macro and where it is used throughout the wolfCrypt sources, as it pertains to AES, you will get a good idea of the sections of the library that will need to be updated for your porting effort.

Let me know if this helps.


Warm Regards,

Kaleb

502

(4 replies, posted in wolfSSL)

Hi mtucholski,

Did the above recommendation resolve this issue?


Best,

Kaleb

503

(7 replies, posted in wolfSSL)

Hi huba,

Thank you for providing those details. Could you tell me which version of wolfSSL you are working with?

Also if possible could you share a brief overview of the project you are working on for qualifying purposes.


Thanks,

Kaleb

Hi jspaith,

No problem, it is my privilege to be able to answer your question. Let us know if anything else comes up in your testing!


Warm Regards,

Kaleb

Hi jspaith,

Thank you so much for using the wolfSSL forums. I understand you are having difficulties processing a certificate with a negative value in the serial number. Could you tell us a little about that certificate, how it was created, is it being used in the wild?

wolfSSL strictly adheres to the standards in order to provide our customers with the best security available on the market.

(though it has a negative Serial number if that matters?)

Unfortunately in your case this DOES matter. If you notice in RFC 5280 found here (https://www.ietf.org/rfc/rfc5280.txt) Section 4.1.2.2 is very explicit:

4.1.2.2.  Serial Number

   The serial number MUST be a positive integer assigned by the CA to
   each certificate.  It MUST be unique for each certificate issued by a
   given CA (i.e., the issuer name and serial number identify a unique
   certificate).  CAs MUST force the serialNumber to be a non-negative
   integer.

The key word "MUST" in an RFC Spec is never to be interpreted as an optional feature for best security practices. Furthermore the RFC uses both terms, POSITIVE and NON-NEGATIVE, leaving no room for interpretation! I am surprised the other implementations you noted chose to ignore this.

Please let us know if this addresses your question wholly.


Our Sincerest Regards,

The wolfSSL Team and Kaleb

506

(7 replies, posted in wolfSSL)

Hi huba,

Could you include the openssl command used to generate the certificate so we can re-create a test-case on our end for confirmation?


Warm Regards,

Kaleb

Hi rodrigoareis,

Yes wolfSSL has several increases planned, in fact the pull requests have been open for some time we just have to finish reviewing them and getting them merged. They are "want to have" at the moment so the priority on them has been de-escalated. You can see the changes in our github repo for example:

https://github.com/wolfSSL/wolfssl/pulls
Compatibility layer part2
Compatibility layer part3
Compatibility layer another part... etc


Warm Regards,

Kaleb

508

(3 replies, posted in General Inquiries)

Hi d1cor,

Thanks for using the support forums and expressing interest in OpenVPN + wolfSSL.


I understand that wolfssl uses post quantum (or quantum resistant) handshake with NTRU, is it true?

Yes wolfSSL supports NTRU. More info in our blog post on the topic here: https://www.wolfssl.com/wolfSSL/Blog/En … lfSSL.html

I has studied the open quantum safe (OQS) implementation of openssl, and I'd like know if this ntru implementation has a similar security level compared with the OQS proyect.

wolfSSL supports NTRU but we are not actively researching and comparing the various quantum safe algorithms against one another. This would be a question for Security Innovations!


Warm Regards,

Kaleb

Hi dodge55,

Do you have a file system on your device (SD card?)?

If so please try using the define NO_WOLFSSL_DIR to resolve this issue.

If you have no file system then you can define the higher-level controller for that include NO_FILESYSTEM


Best Regards,

Kaleb

510

(5 replies, posted in wolfSSL)

Hi gussabina,

Could you send the following please:

Compile/link error output
List of headers you are including in the application
Build Settings for wolfSSL
Summary of how you are building/linking against the wolfSSL library including compiler information


Warm Regards,

Kaleb

Hi delphiwolf,

As the wolfCLU project is currently un-funded I tend to work on it when I get time and that usually occurs around thanksgiving each year. I'll happily make a note that you wish RSA key gen to be the next feature added!

Alternatively if you have great demand and wish to fund the effort rod@wolfssl.com would always be happy to set up an exploratory call to discuss expediting that feature addition through our consulting service. Let me know if this interests you.


Warm Regards,

Kaleb

512

(4 replies, posted in wolfSSL)

Hi mt,

It is very common to see odd behavior / segmentation faults if the application and library are configured differently in any way.

On linux this is easily solved by including the header "wolfssl/options.h" which is auto-generated by the configure script.

On Windows you will need to include the same settings in the app as were used in building the library. On windows by default we use the header <wolf-root>/IDE/WIN/user_settings.h

Could you try including that header or a copy of it in your application and let us know if that resolves the unexplained seg fault?


Warm Regards,

Kaleb

513

(5 replies, posted in wolfSSL)

Hi gussabina,

While FreeRTOS does have a mechanism for threading it is not your standard "pthreads" type implementation. FreeRTOS uses "tasks" to "simulate" threading and are managed accordingly if I remember correctly.

I can look into this more if you like but my first thought here is that trying to remove the "SINGLE_THREADED" define would not be the correct approach here.


Warm Regards,

Kaleb

514

(1 replies, posted in wolfSSL)

Hi prateekthapar,

What is the "cooks simulator"?

How is the wolfSSL library being built?

1. If you are using the autoconf system to build (IE ./configure && make) then the header file "options.h" will be auto generated.
please make sure to include wolfSSL header files like so in this case:

#include <wolfssl/options.h> /* ALWAYS INCLUDE FIRST */
#include <... any other wolfssl headers ...>

2. If you are using some other method to configure the library please make sure to include the EXACT SAME configure options in your application build process so the application and the library have the same settings.


Warm Regards,

Kaleb

Hi delphiwolf,

You have the correct configuration.

./configure --enable-pwdbased --enable-opensslextra && make && make check

Did you also do:

sudo make install

After the successful 'make check'?

It looks like you have the correct setup but the CLU is linking to a different version of the library IE NOT the version you configured. Please double check there are no "other" versions of libwolfssl in the /usr/local/lib directory that wolfCLU might be linking against instead. Also please ensure to install the wolfSSL library after configuring.

You might also try in the wolfCLU directory re-running "./autogen.sh && ./configure && make".

Let me know what you find.


Warm Regards,

Kaleb

516

(1 replies, posted in wolfSSL)

Hi dodge55,

The enums correspond to the RFC 3546 Section 3.2 (https://www.ietf.org/rfc/rfc3546.txt)

In order to negotiate smaller maximum fragment lengths, clients MAY
   include an extension of type "max_fragment_length" in the (extended)
   client hello.  The "extension_data" field of this extension SHALL
   contain:

      enum{
          2^9(1), 2^10(2), 2^11(3), 2^12(4), (255)
      } MaxFragmentLength;

   whose value is the desired maximum fragment length.  The allowed
   values for this field are: 2^9, 2^10, 2^11, and 2^12

wolfSSL enums are defined in the <wolf-root>/wolfssl/ssl.h header file (see below):

 /* Fragment lengths */                                                           
 enum {                                                                           
     WOLFSSL_MFL_2_9  = 1, /*  512 bytes */                                       
     WOLFSSL_MFL_2_10 = 2, /* 1024 bytes */                                       
     WOLFSSL_MFL_2_11 = 3, /* 2048 bytes */                                       
     WOLFSSL_MFL_2_12 = 4, /* 4096 bytes */                                       
     WOLFSSL_MFL_2_13 = 5  /* 8192 bytes *//* wolfSSL ONLY!!! */                  
 };

wolfSSL provides the 5th option but that is unique to wolfSSL as indicated by the comment and would only work with wolfSSL on both ends of the connection. Options 1-4 are RFC and should work with any server that supports the extension IF the server implemented it correctly.

You would send either the "0x0001" or "0x0002"... etc.

Let me know if you have any other questions. We are always happy to help.


Regards,

Kaleb

Hi rodrigoareis,

We have not specifically tested on watchOS.
We do have tvOS as a target in <wolfssl-root>/IDE/iOS/wolfssl.xcodeproj/project.pbxproj

Our recommendation for watchOS would be "just try it" and let us know if you experience any issues. We would be happy to make recommendations if something comes up.


Warm Regards,

Kaleb

518

(1 replies, posted in wolfSSL)

Hi silverdos,

wolfSSL maintains a series of patch files internally since Nginx does not currently accept pull requests to their github repository. To request access to these patch file please shoot an email to info@wolfssl.com or licensing@wolfssl.com and one of our business managers will be happy to assist you.

The following versions are tested with wolfSSL v3.11 and a patch file is available for each Nginx version:

Nginx 1.12.0
Nginx 1.11.13
Nginx 1.11.10
Nginx 1.11.7
Nginx 1.10.3


Best Regards,

Kaleb

519

(6 replies, posted in wolfSSL)

Hi tdoering,

Sorry for delayed response.

I can confirm the requirement to define WOLFSSL_STATIC_RSA and use the static RSA cipher suites as ECDHE and DHE do not appear to be performing correctly in IE11/Edge.

I have not tested any of the static DH cipher suites yet but I suspect they will also work (define WOLFSSL_STATIC_DH).


Best Regards,

Kaleb

520

(6 replies, posted in wolfSSL)

Hi tdoering,

Just wanted to provide an update here since this post is a little older. I am working on reproducing this issue on my end and will detail my findings here soon.

Regards,

Kaleb

521

(3 replies, posted in wolfCrypt)

Hi mohammad,

wolfSSL has many features in progress and/or under review for implementation. I am unsure if CTR-DRBG is one of those items. I have requested that one of our business managers reach out to you directly to discuss future projects and get a better understanding of your need for CTR-DRBG.


Best Regards,

Kaleb

522

(2 replies, posted in wolfSSL)

Hi Jeff,

1. Unable to verify host cert.

To verify the host you need at a minimum a copy of the Host's ROOT CA. You can easily load this in PEM or DER format without a file system. Just use:

wolfSSL_CTX_load_verify_buffer(ssl_object, cert_buffer, sizeof(cert_buffer), SSL_FILETYPE_PEM);

Then format your cert like this:

const unsigned char cert_buffer[] = { "\n\
-----BEGIN CERTIFICATE-----\n\
MIICVzCCAd2gAwIBAgIBKDAKBggqhkjOPQQDAzBBMRMwEQYKCZImiZPyLGQBGRYD\n\
bWlsMRgwFgYKCZImiZPyLGQBGRYIVHlwZTFQS0kxEDAOBgNVBAsTB1BLSUNBMDEw\n\
HhcNMTcwNDE0MTgxMjM3WhcNMjIwNDE0MTgxMjM3WjA3MRUwEwYDVQQFEwxBMDAw\n\
MTAwMDAwMTExHjAcBgNVBAMTFTIuMTYuODQwLjEuMTAxLjIuMS4xNzB2MBAGByqG\n\
SM49AgEGBSuBBAAiA2IABDLKAVvq5fRxDwtVNWczivw7dPECc0I6d6V/+poMFGTC\n\
OhJ+1jubn6VwWGqE5oGm22vJ2CjXC8yTwt+HJ/NVN/oylXGRRAjH0kghGzBP7Zr8\n\
S85cmtn3lP7ygUx7WGNK5qOBsjCBrzATBgNVHSMEDDAKgAhx+thUesQIQzARBgNV\n\
HQ4ECgQI8oFMe1hjSuYwDgYDVR0PAQH/BAQDAgeAMBYGA1UdIAQPMA0wCwYJYIZI\n\
AWUCAQsGMCsGA1UdEQQkMCKgIAYIKwYBBQUHCASgFDASBghghkgBZQIBEQQGoAAQ\n\
AAARMDAGA1UdHwQpMCcwJaAjoCGGH2h0dHBzOi8vUHJpbWFyeVBERS9wa2kvMTAw\n\
MTI3MzkwCgYIKoZIzj0EAwMDaAAwZQIxANMDtwbS4vD+zrge2vuTLwt0cy0J6j9P\n\
LldPMuKrAxRMVQ0fTgDMlxjGyV7onb0NxAIwXW2qCXjEvZBzgOx+IQnCHOjxDLp2\n\
/bDPlrF8llEDzjYvTLmN0cUZ5bwcOQygi3Xo\n\
-----END CERTIFICATE-----\n\n"
};



2. Failure in the Encrypt() function

Yes my first thought here was that you have no encryption configured IE no aes, no 3des, no camellia... etc. The MQTT user_settings example is quite sophisticated but intended to try and present all the available options for customizing our library. You have resolved this already based on the above.

Finally I see you are calling wolfSSL_write() which will call wolfSSL_connect() if the handshake has not completed already, however the downside to doing this is that you will not be able to debug if something goes wrong in the handshake.

I would recommend trying this BEFORE calling wolfSSL_write():

return_value = wolfSSL_connect(xWolfSSL_Object);

if (return_value != SSL_SUCCESS) {
    printf("Handshake failed with error code: %d\n", return_value);
}

Is there an error code returned? If so what is the value? If it is -300 or less it is a TLS error and the definition can be found in <wolf-root>/wolfssl/error-ssl.h otherwise if it is in the -200 to 0 range the definition is crypto related and can be found in <wolf-root>/wolfssl/wolfcrypt/error-crypt.h


Regards,

Kaleb

523

(1 replies, posted in wolfSSL)

Hi JuanCarlos,

Have you contacted TI in regards to this issue?

The issue does not appear related to wolfSSL unfortunately, but rather it appears related to the toolchain itself. Could you tell us a little about the project and what you are working on?


Best Regards,

Kaleb

524

(1 replies, posted in wolfCrypt)

Hi telina,

We apologize for this inconvenience, we noticed this after the release with our work on TLS 1.3 and it has already been reverted:

https://github.com/wolfSSL/wolfssl/comm … d4937L4446

Please feel free to remove that check with the understanding it is safe to do so.


Warmest Regards,

Kaleb

525

(3 replies, posted in wolfCrypt)

Hi mohammad.abomokh,

Thank you for using the wolfSSL forums.

From the available DRBG implementations outlined in NIST special publication 800-90A wolfSSL has only implemented the Hash_DRBG.

http://csrc.nist.gov/publications/nistp … 00-90A.pdf

Hash_DRBG     - SUPPORTED in wolfSSL
HMAC_DRBG    - NOT SUPPORTED in wolfSSL
CTR_DRBG       - NOT SUPPORTED in wolfSSL
Dual_EC_DRBG - NOT SUPPORTED in wolfSSL

Please let us know if you have any questions on this.

Warm Regards,

Kaleb