326 Reply by dgarske

(2 replies, posted in wolfSSL)

Hi faberge,

Thanks for your interest in wolfSSL! It sounds like you are 99% of the way there.

The call to read 5 bytes is to get the TLS header, which indicates the total size of the TLS packet. So the next read will be the remainder of the TLS packet. Perhaps you can share a bit more about the code used in your read and write callbacks? You can find our default IO callback functions here: https://github.com/wolfSSL/wolfssl/blob … io.c#L194.

Make sure you are properly handling a non-blocking case, which you would need to return `WOLFSSL_CBIO_ERR_WANT_READ`.

Another common pitfall (depending on your transport layer) is some stacks require getting the entire packet in which case you'd need to cache the remainder of the TLS packet for the read after the 5 byte header.

If you still need help debugging this please provide debug logs, wireshark trace and code snippets for review. If you'd like to keep those private you can email us directly at support@wolfssl.com and reference this forum link.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

327 Reply by dgarske

(5 replies, posted in wolfMQTT)

Hi Peter,

Thanks for the excellent question! We are working on an enhancement right now to add the ability to chunk large publish messages being sent. The engineer working on this is Eric B. He will be following up with you shortly.

Thanks,
David Garske, wolfSSL

Go to forum: wolfMQTT

328 Reply by dgarske

(24 replies, posted in wolfSSL)

Hi Paul,

We will look into supporting this feature. I've started an email thread with another engineer. Your code may be valid, but wolfSSL doesn't yet support the serial number as part of the multi-attrib.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

329 Reply by dgarske

(24 replies, posted in wolfSSL)

Hi ePaul,

The code changes to use multi-attrib for serial number are not valid. In fact the serial number field is different all-together and is not encoded into a CSR.

If you'd like to have a unique identifier in the certificate typically that goes into one of the subject fields such as common name. The only valid mult-attrib fields are: ASN_ORGUNIT_NAME and ASN_DOMAIN_COMPONENT.

Example here:
https://github.com/wolfSSL/wolfssl/blob … st.c#L8564

If you are going to use the multi-attrib fields then make sure the csr.c `CertName myCertName` is not const (I see you made it static above, which is fine).

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

330 Reply by dgarske

(2 replies, posted in wolfSSL)

Hi ePaul,

We've pushed an example for using large data with PKCS 7 sign/verify here:
https://github.com/wolfSSL/wolfTPM/pull/32

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

331 Reply by dgarske

(2 replies, posted in wolfSSL)

Hi ePaul,

We recently enhanced PKCS7 to support signing a large file using a computed hash and known total size. The wolfSSL pull request is here: https://github.com/wolfSSL/wolfssl/pull/1780
This works by computing the hash and providing it to the new wc_PKCS7_EncodeSignedData_ex API. It returns a header and footer that surrounds the original data.

I will post a wolfTPM example for using this shortly.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

332 Reply by dgarske

(24 replies, posted in wolfSSL)

Hi Paul,

The CSR should not contain a serial number. The serial number is assigned by the CA when it gets signed.

I will however take a look at your example and see if there is an issue that needs fixed around CSR gen with serial number provided.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

333 Reply by dgarske

(24 replies, posted in wolfSSL)

Hi ePaul,

You can do whichever is easier for you.

To clone the branch use:

git clone https://github.com/wolfSSL/wolfssl.git
cd wolfssl
git fetch origin pull/1805/head:fix_csr
git checkout fix_csr

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

334 Reply by dgarske

(24 replies, posted in wolfSSL)

Hi ePaul,

Thanks for the bug report. I was able to reproduce your issue and identiy the cause. I've pushed a wolfSSL fix for this issue here (https://github.com/wolfSSL/wolfssl/pull/1805). It was a new issue that happened after we added some additional fields to support BusinessUnit.

I'm located in PDT (UTC -7).

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

335 Reply by dgarske

(2 replies, posted in wolfCrypt)

Hi Ehsan,

The RSA key generation is a very intensive operation. Even on a top end Intel i7 part is takes almost 1 second. Generating an RSA 2048-bit key requires two 256 byte prime numbers. It requires a large amount of RNG data. I suspect it appears to hang, but its still running.

Example:

./configure --enable-keygen && make
./wolfcrypt/benchmark/benchmark -rsa-kg
wolfCrypt Benchmark (block bytes 1048576, min 1.0 sec each)
RSA     1024 key gen         8 ops took 1.058 sec, avg 132.305 ms, 7.558 ops/sec
RSA     2048 key gen         3 ops took 2.862 sec, avg 954.070 ms, 1.048 ops/sec

Thanks,
David Garske, wolfSSL

Go to forum: wolfCrypt

336 Reply by dgarske

(24 replies, posted in wolfSSL)

Hi ePaul,

To build you'll need to use:

./configure --enable-certgen --enable-certreq --enable-certext --enable-pkcs7 --enable-cryptodev --enable-opensslextra=x509small CFLAGS="-DTIME_T_NOT_LONG  -DWOLFSSL_MULTI_ATTRIB"
make
sudo make install
sudo ldconfig

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

337 Reply by dgarske

(24 replies, posted in wolfSSL)

Hi ePaul,

To resolve the build error in our api.c unit test you can build with the `./configure CFLAGS="-DTIME_T_NOT_LONG"` option. This uses a 32-bit time type.

For the wolfTPM question on creating a Certificate Signing Request you can find the complete example here:
https://github.com/wolfSSL/wolfTPM/blob … /csr/csr.c

Let us know if you have any other issues or questions.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

338 Reply by dgarske

(3 replies, posted in wolfCrypt)

Hi AdoraKalb,

That sounds like an issue with not providing enough stack space to the FreeRTOS thread on the xTaskCreate. Try increasing the stack size for that task and let us know if that helps.

Thanks,
David Garske, wolfSSL

Go to forum: wolfCrypt

339 Reply by dgarske

(2 replies, posted in General Inquiries)

Hi kjjy,

The actual function name is `wc_EccKeyToDer`.
https://github.com/wolfSSL/wolfssl/blob … lic.h#L402

The old Cyassl used `EccKeyToDer` and is deprecated here:
https://github.com/wolfSSL/wolfssl/blob … blic.h#L71

To use this you must have ECC enabled:
`./configure --enable-ecc` or `#define HAVE_ECC`.

Thanks,
David Garske, wolfSSL

Go to forum: General Inquiries

340 Reply by dgarske

(2 replies, posted in General Inquiries)

Hi kjjy7,

If you are using ./configure you do not need to use user_settings.h. The ./configure outputs a build configuration file to wolfssl/options.h. You can use this file as a template for user_settings.h if you are building the sources directly (without ./configure).

If you are building sources directly then you can define WOLFSSL_USER_SETTINGS and add a user_settings.h file to your include path. There is an excellent template for this here: https://github.com/wolfSSL/wolfssl/blob … settings.h

Thanks,
David Garske, wolfSSL

Go to forum: General Inquiries

341 Reply by dgarske

(4 replies, posted in General Inquiries)

Hi kjjy7,

Try using the function `wolfSSL_get_state`. We also have an API `wolfSSL_state_string_long` which gets a string version of the current state.

We also have an internal TLS client state is in `ssl->options.clientState`. The possible values are here: https://github.com/wolfSSL/wolfssl/blob … al.h#L1428

Let us know if that is helpful or not.

Thanks,
David Garske, wolfSSL

Go to forum: General Inquiries

342 Reply by dgarske

(1 replies, posted in wolfSSL)

Hi lupusn00b,

The user_settings.h file is only used when `WOLFSSL_USER_SETTINGS` is defined and is usually used when building the wolfSSL/wolfCrypt sources directly. You asked about only having HMAC+SHA256. It looks like yours is disabling HMAC and SHA256. You should not have the NO_HMAC and NO_SHA256 defined. Also there are a bunch of other defines you'll want for disabling other algorithms.

Here is a good tip: When you run ./configure with your desired options it generates a file in `wolfssl/options.h`. You can use this file as a template for your user_settings.h.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

343 Reply by dgarske

(1 replies, posted in wolfSSL)

Hi Te,

Fix posted here: https://github.com/wolfSSL/wolfssl/pull/1689

Thanks.
David Garske, wolfSSL

Go to forum: wolfSSL

344 Reply by dgarske

(1 replies, posted in wolfMQTT)

Hi Giovanni,

Have you tried adding `-mlongcalls` to your CFLAGS and CXXFLAGS?

See forum post here:
https://www.esp32.com/viewtopic.php?t=1612

Thanks,
David Garske, wolfSSL

Go to forum: wolfMQTT

345 Reply by dgarske

(3 replies, posted in wolfSSL)

Hi Gil,

Yes you can disable DH if you are using ECC or a static cipher suite.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

346 Reply by dgarske

(1 replies, posted in wolfCrypt)

Hi leroyk2,

We have a fix pushed for this here:
https://github.com/wolfSSL/wolfssl/pull/1505

Specifically this line:
https://github.com/wolfSSL/wolfssl/pull … d4937R8575

You may find some of the other improvements in that PR useful as well for the STM32 with CubeMX.

Thanks,
David Garske, wolfSSL

Go to forum: wolfCrypt

347 Reply by dgarske

(1 replies, posted in wolfMQTT)

Hi Ed,

Thanks for the report of these issues. I've fixed the script for directory check. The double equal works on some platforms, but you are right the single equal is the best practice. Fix pushed here: https://github.com/wolfSSL/wolfMQTT/com … o?expand=1

Is the `~/ARDUINO`a standard location on all platforms? The example we built uses the `#include <wolfMQTT.h>` include. Where did you see the `wolfmqtt.h` case expected?

Thanks,
David Garske, wolfSSL

Go to forum: wolfMQTT

348 Reply by dgarske

(1 replies, posted in wolfSSL)

Hi Marco,

The return code from the verify callback allows an error to do overridden. By default the verify callback is only issued in the error case, unless you have `WOLFSSL_ALWAYS_VERIFY_CB` defined. You can use the `store->error` variable to determine the error reason (if one exists). A non-zero return code such a 1 or `WOLFSSL_SUCCESS` allows an error to be overridden. A return value of 0 means continue processing the error in the default way (fail).

For everyones reference the verify callback is set using: `wolfSSL_CTX_set_verify(ctx, WOLFSSL_VERIFY_PEER, myVerify);`

Here are some example implementations we use for internal testing of the verify callback:
https://github.com/wolfSSL/wolfssl/blob … st.h#L1361
https://github.com/wolfSSL/wolfssl/blob … st.h#L1404

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

349 Reply by dgarske

(1 replies, posted in wolfMQTT)

Hi PeterL,

Thanks so much for the excellent bug report!

I've issued a fix for this here:
https://github.com/wolfSSL/wolfMQTT/pull/52

We should be doing a wolfMQTT release by the end of the month. This change will be included.

We are always curious how customers are using wolfMQTT and wolfSSL, so it would be great to hear from you by email at info@wolfssl.com.

Please feel free to ask additional questions anytime. You can also get support using support@wolfssl.com.

Thanks,
David Garske, wolfSSL

Go to forum: wolfMQTT

350 Reply by dgarske

(25 replies, posted in wolfSSL)

Hi olle,

We are looking into the DTLS 1.0 report. We see the CLIENT_HELLO retried even though the SERVER_HELLO is received. We believe this causes the DTLS sever to drop the connection since the second CLIENT_HELLO does not include the same packet information as the first request (its missing TLS extensions). We believe this may be a bug with our DTLS 1.0 code and we hope to have a fix available shortly. Thanks for your details report and we will provide you a followup soon.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL