251 Reply by dgarske

(3 replies, posted in wolfSSL)

Hi Carlo,

The non-blocking mode is on by default for TLS. You can just configure your socket as non-blocking and you'll be good. The read/write IO callback return "want write" or "want read" to indicate would block. The old `wolfSSL_set_using_nonblock` function maps to `wolfSSL_dtls_set_using_nonblock`, which only applies to the DTLS case.

You can find some TLS and DTLS examples in our wolfssl-examples repo. There is a TLS non-blocking example here:
https://github.com/wolfSSL/wolfssl-exam … blocking.c

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

252 Reply by dgarske

(3 replies, posted in wolfSSL)

Hi Waigor,

Are you trying to reuse the WOLFSSL_CTX between these connections? If the key/cert is loaded at the WOLFSSL_CTX level it gets shared/reused and only allows certain cipher suites. Have you tried loading the key/cert at the WOLFSSL object level using wolfSSL_use_certificate_file and wolfSSL_use_PrivateKey_file? If you'd like to share some code to review feel free to email us at support@wolfssl.com

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

253 Reply by dgarske

(3 replies, posted in wolfSSL)

Hi waigor,

The RSA keys will use more memory. Have you tried increasing the static memory pool size? What cipher suites are you trying to use with RSA and what TLS version?

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

254 Reply by dgarske

(2 replies, posted in wolfSSL)

Hi Carlo,

Thanks for pointing our the doxy return code error in the example. I've updated that.

The documentation you seek for SNI is in the wolfSSL user manual in chapter 4.
https://www.wolfssl.com/docs/wolfssl-manual/ch4/
See 4.9 SERVER NAME INDICATION

We do have a mix of zero return and WOLFSSL_SUCCESS/WOLFSSL_FAILURE. The wolfSSL_ level API's typically use the success/failure return codes and the reasoning goes back to the openssl compatibility layer which expects these. For our internal API's and wolfCrypt API's we prefer to use 0 to indicate success.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

255 Reply by dgarske

(1 replies, posted in wolfSSL)

Hi Carlo,

Thanks for your questions and feedback. Doing a wolfSSL read/write for the same WOLFSSL object at the same time is not thread safe by efault. The WOLFSSL object should only be used from a single thread. However we do have a build-time feature you can enable to allow read and write on separate threads. This feature is enabled using the `HAVE_WRITE_DUP` build option.

You can find an example for this feature here:
https://github.com/wolfSSL/wolfssl-exam … writedup.c

This allows creation of a second WOLFSSL object for writing only. The existing WOLFSSL object is flagged as read-only.

/* Duplicate read_ssl, setting it to read-only, creating write_ssl, which is write-only */
if ((write_ssl = wolfSSL_write_dup(read_ssl)) == NULL) {
    fprintf(stderr, "ERROR: failed write dup\n");
    return -1;
}

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

256 Reply by dgarske

(3 replies, posted in wolfSSL)

Hi carlo,

That's a great question. I am going to ask our Distro maintainer Felix to comment on this.

The equivalent option you should use is "--enable-all". This will have all the same "distro" features, but enables all features and generates a `wolfssl/options.h` you can use.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

257 Reply by dgarske

(1 replies, posted in wolfCrypt)

Hi cxdinter,

Yes we fully support RSA PSS padding. It was added with the TLS v1.3 support back in May 17, 2017.

To enable it use `./configure --enable-rsapss` or define `WC_RSA_PSS`.

The API's are `wc_RsaPSS_VerifyInline`, `wc_RsaPSS_Verify`, `wc_RsaPSS_CheckPadding`, `wc_RsaPSS_VerifyCheck`, `wc_RsaPSS_Sign`, etc...

See inline API documentation here:
https://github.com/wolfSSL/wolfssl/blob … sa.c#L3206

Thanks,
David Garske, wolfSSL

Go to forum: wolfCrypt

258 Reply by dgarske

(1 replies, posted in wolfSSL)

Hi s123unny,

It looks like `wolfSSL_dtls_set_using_nonblock` is missing in the C# wrapper and it is not designed for blocking mode only.I've put it on the C# wrapper feature request list.

It looks like the: https://github.com/wolfSSL/wolfssl/blob … SL.cs#L416

But if you are eager to work on it yourself you can find a C example for it here:
https://github.com/wolfSSL/wolfssl-exam … blocking.c

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

259 Reply by dgarske

(1 replies, posted in wolfCrypt)

Hi conallanoc,

The "authIn" is the AAD (additional authenticated data). Its extra data that can be included for the authentication tag generated. On an encrypt the "authTag" is generated and on decrypt you provide the value and the tag is compared after decryption to ensure integrity of the data.

Here is a NIST document for AES GCM test vectors: https://csrc.nist.gov/CSRC/media/Projec … /gcmvs.pdf

Thanks,
David Garske, wolfSSL

Go to forum: wolfCrypt

260 Reply by dgarske

(3 replies, posted in wolfSSL)

Hi Chris,

We just put up a TLS v1.3 fix that might resolve that -306 error. Another customer reported an issue with the order of the TLS extensions.

https://github.com/wolfSSL/wolfssl/pull/2934

Let me know if that helps. Looking forward to your PR. We'll need to get a signed contributor agreement in place to accept it. Go ahead and submit the PR and then send a note to support@wolfssl.com and we can send you that.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

261 Reply by dgarske

(3 replies, posted in wolfSSL)

Hi Chris,

Are you using the latest Curl and what is the TLS engine you are using in Curl? The `curl -h | sed -ne '/--tlsv/p' ` command will show you the TLS versions.

Is your Curl using openssl? Try running `openssl ciphers -v | grep TLSv1.3` and make sure the cipher suite is listed.

I ran a quick test on my Mac and it worked against openssl s_client. Using CURL I got a similar error, but I am running an older Curl.

./configure --enable-tls13 && make
./examples/server/server -d -b -g -v 4 -l TLS13-CHACHA20-POLY1305-SHA256
SSL version is TLSv1.3
SSL cipher suite is TLS_CHACHA20_POLY1305_SHA256
SSL curve name is SECP256R1
Client message:
openssl s_client -tls1_3 -ciphersuites 'TLS_CHACHA20_POLY1305_SHA256' -connect localhost -port 11111
...
wolfSSL has successfully performed handshake!
...

./examples/server/server -d -b -g -v 4 -l TLS13-CHACHA20-POLY1305-SHA256
SSL_accept error -308, error state on socket
wolfSSL error: SSL_accept failed

curl --version
curl 7.62.0-DEV (x86_64-apple-darwin17.7.0) libcurl/7.62.0-DEV wolfSSL/3.15.3 zlib/1.2.11 nghttp2/1.39.2
Release-Date: [unreleased]

curl -vvv -k --tlsv1.3 https://localhost:11111
*   Trying ::1...
* TCP_NODELAY set
* Connection failed
* connect to ::1 port 11111 failed: Connection refused
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 11111 (#0)
* CyaSSL: TLS 1.3 is not yet supported
curl: (35) CyaSSL: TLS 1.3 is not yet supported


Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

262 Reply by dgarske

(1 replies, posted in wolfCrypt)

Hi simplyembedded,

I believe we fixed that issue here: https://github.com/wolfSSL/wolfssl/pull/2903

See the changes in rsa.c. These are also in the latest v4.4.0 release tagged last week.

It occurred with RSA when RNG was disabled. "RSA PKCS #1.5 padding for signing is not reliant on a random."

As for the Xilinx SDK project we used 2018.2. We also have one for the latest Xilinx Vitis SDK 2019.2 we can share. Please send us an email at suport@wolfssl.com and request it.

Thanks,
David Garske, wolfSSL

Thanks,
David Garske, wolfSSL

Go to forum: wolfCrypt

263 Reply by dgarske

(1 replies, posted in wolfSSL)

Hi s123unny,

The DTLS server handles the peer address filter via the IO callbacks and the `wolfssl.set_dtls_fd`. See wolfSSL.cs `wolfSSL_dtlsCbIOSend` and `wolfSSL_dtlsCbIORecv`. Is there a use-case this is not covering for you?


I will still make a feature request note for `wolfssl.dtls_set_peer` -> `wolfSSL_dtls_set_peer`.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

264 Reply by dgarske

(8 replies, posted in wolfCrypt)

Hi kannan,


The GitHub PR is here: https://github.com/wolfSSL/wolfssl-examples/pull/155

Here is the branch and directory with instructions:
https://github.com/JacobBarthelmeh/wolf … x/FreeRTOS

Let me know if you have any questions.

Thanks,
David Garske, wolfSSL

Go to forum: wolfCrypt

265 Reply by dgarske

(8 replies, posted in wolfCrypt)

Hi Kannan,

We support the A9 and Aarch64 speedups and the Zynqmp hardware acceleration.
Here is the wolfSSL FreeRTOS Xilinx port:
https://github.com/wolfSSL/wolfssl-examples/pull/155

Here is Xilinx's performance write up on it:
https://www.xilinx.com/support/document … crypto.pdf

Thanks,
David Garske, wolfSSL

Go to forum: wolfCrypt

266 Reply by dgarske

(2 replies, posted in wolfSSL)

Hi bsda_dev,

Your error is: `SIDE_ERROR                   = -344,   /* wrong client/server type */`.

Yes we support both sides. We do have a feature to create a generic WOLFSSL_CTX method and the context role (client or server) is determined on the first connect.

To enable this feature use the build option `WOLFSSL_EITHER_SIDE` and use the method `wolfSSLv23_method`.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

267 Reply by dgarske

(4 replies, posted in wolfBoot)

Hi windyMk92,

Yes that all looks correct. Depending on your platform you may need to do a "sudo ldconfig" after the "sudo make install". Additionally some platform use "usr" and some use "usr/local", so you might need to adjust things. If you want to force wolfSSL configure to install to a different location use `./configure --prefix=/usr` (for example).

For wolfcrypt-py install using the local wolfCrypt are you using this command `sudo USE_LOCAL_WOLFSSL=/usr/local pip3 install .`?

Are you still getting the same `libwolfssl.so.24: cannot open shared object file: No such file or directory` error?

Thanks,
David Garske, wolfSSL

Go to forum: wolfBoot

268 Reply by dgarske

(5 replies, posted in wolfMQTT)

Hi DanielGruber,

I pushed a few FreeRTOS fixes to that MQTT multi-threading PR here: https://github.com/wolfSSL/wolfMQTT/pul … 7a4cc203eb

Let me know if you still see any issues on FreeRTOS.

Thanks,
David Garske, wolfSSL

Go to forum: wolfMQTT

269 Reply by dgarske

(1 replies, posted in wolfMQTT)

Hi rvogel,

Your code looks correct for loading a trusted CA. I would suggest its not locking up, but instead is taking a long time. Internally its doing an asymmetric verify operation. Are you able to see with a debugger where its "locking up". Have you confirmed you have enough stack/heap available? Is this an ECC or RSA certificate? Have you tried enabling debug logging? To do so define DEBUG_WOLFSSL and call wolfSSL_Debugging_ON();. If you want to redirect to printf instead of the default sprintf(stderr define `WOLFSSL_LOG_PRINTF`.

Thanks,
David Garske, wolfSSL

Go to forum: wolfMQTT

270 Reply by dgarske

(4 replies, posted in wolfBoot)

Hi windyMk92,

The error you are seeing is because the wolfSSL library is missing --enable-ed25519. See the instructions for setting up the Python signing tool here:
https://github.com/wolfSSL/wolfBoot/blo … ll-python3

Interestingly we also just merged in a pure C version of the signing tool along with a visual studio project in tools/keytools. See the section here: https://github.com/wolfSSL/wolfBoot/blo … gning-tool

Thanks,
David Garske, wolfSSL

Go to forum: wolfBoot

271 Reply by dgarske

(5 replies, posted in wolfMQTT)

Hi DanielGruber,

The issue turned out to be thread synchronization and switching to a binary semaphore resolved things. The code has been pushed here and is under peer review:
https://github.com/wolfSSL/wolfMQTT/pull/146

Thanks,
David Garske, wolfSSL

Go to forum: wolfMQTT

272 Reply by dgarske

(5 replies, posted in wolfMQTT)

Hi DanielGruber,

We can reproduce the issue and are working on a fix. Once it is available I will post a link here shortly.

Thanks,
David Garske, wolfSSL

Go to forum: wolfMQTT

273 Reply by dgarske

(5 replies, posted in wolfMQTT)

Hi DanielGruber,

Thanks for the detailed report for wolfMQTT and multithreading. I will see if I can reproduce and resolve.

David Garske, wolfSSL

Go to forum: wolfMQTT

274 Reply by dgarske

(1 replies, posted in wolfSSL)

Hi ashetty,

Those functions are "internal" as defined by `WOLFSSL_LOCAL`, which tells the compiler not to export them via wolfssl/wolfcrypt/visilbility.h "#define WOLFSSL_LOCAL __attribute__ ((visibility("hidden")))".

Is there a reason you aren't using a public API like: `wolfSSL_get_cipher_list`, `wolfSSL_get_ciphers`, `wolfSSL_get_ciphers_iana`?

If you really want to expose the internal API's you'll need to un-define HAVE_VISIBILITY or un-define BUILDING_WOLFSSL.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

275 Reply by dgarske

(1 replies, posted in wolfSSL)

Hi yighax2,

Check out our wolfssl-examples repo. We have a few examples that will help you with this:

https://github.com/wolfSSL/wolfssl-exam … -callbacks
https://github.com/wolfSSL/wolfssl-exam … master/tls
See the "-callback" TLS examples

These use our custom IO callbacks, which are set using:
wolfSSL_CTX_SetIORecv(ctx, my_IORecv);
wolfSSL_CTX_SetIOSend(ctx, my_IOSend);

You can also set a custom pointer context using:
wolfSSL_SetIOReadCtx(ssl, &recvCtx);
wolfSSL_SetIOWriteCtx(ssl, &sendCtx);

You can build with `WOLFSSL_USER_IO` to disable the internal "socket" handling and require use of these IO callbacks.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL