Hi he1n,

Yes. See `WOLFSSL_SSLKEYLOGFILE` define to output master secret used by Wireshark logging to file. Defaults to sslkeylog.log, but can be overridden using `WOLFSSL_SSLKEYLOGFILE_OUTPUT`.

1. Build wolfSSL using:
./configure CFLAGS="-DSHOW_SECRETS -DWOLFSSL_SSLKEYLOGFILE"

2. By default it outputs to a file named "sslkeylog.log" using this Wireshark Pre-Master-Secret Format:
CLIENT_RANDOM <clientrandom> <mastersecret>

3. You can tell Wireshark where to find the key file via Edit→Preferences→Protocols→SSL→(Pre)-Master-Secret log filename.

Key logging feature was added in PR 1873 (https://github.com/wolfSSL/wolfssl/pull/1873)
Commit: https://github.com/wolfSSL/wolfssl/pull … dd532b587b

You will get a compiler warning for this feature because it should never be used in production. Here is the PR with those details:
https://github.com/wolfSSL/wolfssl/pull/2053

The #warning can be ignored as error using ./configure CFLAGS="-W#warnings".

Thanks,
David Garske, wolfSSL

Hi weaver4,

You need to use the `--with-sysroot=` with your ./configure. Do some google searches for "undefined reference to `__fdelt_chk'" and you'll see some tips.

For example this cross-compile for a HiFive Unleashed board running Linux:

./configure --host=riscv64 \
    CC="/home/davidgarske/GitHub/freedom-u-sdk/work/buildroot_initramfs/host/bin/riscv64-sifive-linux-gnu-gcc" \
    --with-sysroot="/home/davidgarske/GitHub/freedom-u-sdk/work/buildroot_initramfs_sysroot/" \
    --disable-shared \
    --enable-sp \
    CFLAGS="-mabi=lp64d -march=rv64imafdc"
make

You can see the use of `--with-sysroot=`.

The sysroot is required because you are cross-compiling to an ARM system running Linux. If you want to cross-compile for bare-metal.

If you want to use a custom Makefile see example here:
https://github.com/wolfSSL/wolfssl/tree … DE/GCC-ARM

Or you can use CMake with an experimental PR here:
https://github.com/wolfSSL/wolfssl/pull/2746

Thanks,
David Garske, wolfSSL

Hi akhi_gangwar,

I see now that you are using the TI hardware acceleration in ti-aes.c. Have you tried running without the hardware acceleration? For that you'd just not define `WOLFSSL_TI_CRYPT`.

I will have another engineer who's worked on the TI parts review this report. It could be there is a new issue with tm4c129encpdt  and `AesAlign16`.

Also I cannot see where -1014 would be generated from the ecc_test, is it possible to share the stack information for the error or enable logging with DEBUG_WOLFSSL and wolfSSL_Debugging_ON()?

Thanks,
David Garske, wolfSSL

Hi akhi_gangwar,

The next operation is the "processing server hello done", which uses decryption. Have you run the wolfCrypt test yet to validate your platform's individual algorithms?

Here is an example for calling wolfcrypt/test/test.c:
https://github.com/wolfSSL/wolfssl/blob … est_main.c

Have you made sure your thread has enough stack space? Depending on the build options and cipher suite you may need up to 30KB in of stack space. You can reduce the stack requirement using build options like `WOLFSSL_SMALL_STACK` and `ALT_ECC_SIZE`. Here is a useful list I put together:
https://github.com/wolfSSL/wolfssl/tree … ng-options

Thanks,
David Garske, wolfSSL

Thanks,
David Garske, wolfSSL

Hi akhi_gangwar,

The error -188 means a certificate could not be validated to a trusted peer. The TLS Peer is sending 4 certificates and some of these are not validating. By default wolfSSL expects all provided certificates get validated. My guess is you are loading an intermediate CA and not the root CA. You can either load the correct root CA or you can add our `WOLFSSL_ALT_CERT_CHAINS` build option. This option only requires the peer's provided certificate matches to a loaded/trusted cert.

Also you can load PEM files directly using SSL_FILETYPE_PEM.

Thanks,
David Garske, 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

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

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

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

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

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