Hi burakkirazli,
Thanks for your report. I pushed a fix into PR 135 here (https://github.com/wolfSSL/wolfMQTT/pull/135). Please give it a try and let me know if this works.
Thanks,
David Garske, wolfSSL
You are not logged in. Please login or register.
Please post questions or comments you have about wolfSSL products here. It is helpful to be as descriptive as possible when asking your questions.
ReferenceswolfSSL - Embedded SSL Library → Posts by dgarske
Hi burakkirazli,
Thanks for your report. I pushed a fix into PR 135 here (https://github.com/wolfSSL/wolfMQTT/pull/135). Please give it a try and let me know if this works.
Thanks,
David Garske, wolfSSL
Hi burakkirazli,
You must run the example from the wolfssl-root like:
./examples/echoserver/echoserver
Also you can find some simple TLS examples in our wolfssl-examples repo here:
https://github.com/wolfSSL/wolfssl-examples
Thanks,
David Garske, wolfSSL
Hi Cookie,
Have you seen our simple TLS examples in our wolfssl-examples repo?
https://github.com/wolfSSL/wolfssl-exam … master/tls
The -345 NO_PEER_CERT error indicates the peer did not present a certificate. See the wolfSSL_CTX_set_verify API for setting the verify options for the peer certificate.
Thanks,
David Garske, wolfSSL
Thanks,
David Garske, wolfSSL
Hi JMG,
You can find the RISC-V examples here:
https://github.com/wolfSSL/wolfssl/tree … PSE/SIFIVE
https://github.com/wolfSSL/wolfssl/tree … /IDE/RISCV
Also I just put up a PR to consolidate the RISC-V information into IDE/RISCV here:
https://github.com/wolfSSL/wolfssl/pull/2490
Thanks,
David Garske, wolfSSL
Hi Kvkhekale,
Also make sure you have the arm-none-eabi-gcc-8.3.1/bin directory in your path.
Thanks,
David Garske, wolfSSL
Hi kvhekale,
Try using something like this:
export WOLFSSL_PREFIX="`pwd`/../build"
./configure \
--host=arm-none-eabi \
CFLAGS="-mcpu=cortex-m0 --specs=nano.specs -DNO_WOLFSSL_DIR -DWOLFSSL_USER_IO -DNO_WRITEV" \
--prefix=$WOLFSSL_PREFIX/wolfssl-m0-baremetal \
--disable-examples
make
make installThanks,
David Garske, wolfSSL
Hi i.fedotov,
The PIC32MZ does not allow two hardware hashing operations to happen at the same time. We have two versions of the hardware crypto. Some of the TLS operations required overlapping update/final. Make sure you do not have WOLFSSL_PIC32MZ_LARGE_HASH defined.
1. Enabled with WOLFSSL_PIC32MZ_LARGE_HASH, which enables direct update/finish calls to hardware.
2. Caches updates and only uses hardware on final.
You can see this code in wolfcrypt/src/port/pic32/pic32mz-crypt.c. In Harmony sources its in HarmonyFramework/crypt/src.
Let me know if that makes a difference for you or not. If not please let me know the cipher suite and TLS version being used. If possible also enable debugging using DEBUG_WOLFSSL and calling wolfSSL_Debugging_ON();.
Thanks,
David Garske, wolfSSL
Hi Naveen,
By default we have threading support enabled and defaults to pthread. You can define NO_FILESYSTEM to disable it.
I recommend setting up your own build configuration file called "user_settings.h" and defining a single global pre-processor macro WOLFSSL_USER_SETTINGS. Then you can manage all your build settings in one place. In your user application make sure you include wolfssl/wolfcrypt/settings.h before any other wolf headers. We have a section on this in the FAQ link previously sent.
Thanks,
David Garske, wolfSSL
Hi naveen,
Our wolfSSL/wolfCrypt library does not have any references to "getcwd". Can you provide additional details as to where you are seeing that error? It sounds like a C stdlib issue with the ardupilot project and your compiler.
Thanks,
David Garske, wolfSSL
Hi EricDOS,
For measuring sizes of shared objects you might try the size command:
./configure --enable-leantls && make
size ./src/.libs/libwolfssl.dylib
__TEXT __DATA __OBJC others dec hex
262144 4096 0 36864 303104 4a000Thanks,
David Garske, wolfSSL
Hi EricDOS,
How are you measuring the code size? If you are just looking at the shared DLL size that has overhead for symbols, which aren't there in a static build. Also most of the size optimization occurs at link-time with the final application. Try using --disable-shared and use the static library with your application.
Can you tell us more about the target and application? We have many options for tuning, but it helps to know the CPU and RTOS.
The fast math library should be about the same size, but it uses stack for math variables instead of heap. The fast math library also support assembly optimizations.
You might also check our --enable-leantls option in ./configure.ac, which has many additional options for reducing code size. See https://github.com/wolfSSL/wolfssl/blob … re.ac#L637
You can find a good reference document here:
https://github.com/wolfSSL/wolfssl/tree … ng-options
If you are looking to boost performance you can try our `--enable-sp=small` option, which provides optimized code for specific keys and curve. This will not reduce code size.
Thanks,
David Garske, wolfSSL
Hi ENOTTY,
We put up an example for using the BIO compatibility layer with SSL here:
https://github.com/wolfSSL/wolfssl-examples/pull/171
Thanks,
David Garske, wolfSSL
Hi harish.reddy,
There is not enough data there to determine that information. Typically the AES GCM IV is 12 bytes. Typically the AES GCM Auth Tag is 16 bytes. Typically the AES GCM Encrypted data is a multiple of block size (16 bytes).
https://github.com/wolfSSL/wolfssl/blob … aes.h#L110
Thanks,
David Garske, wolfSSL
Hi naveen,
Thanks for your interest in our library. The project sounds interesting. Overall its pretty easy, since its all c code and GPLv2.
See these resources:
* wolfSSL Porting Guide: https://www.wolfssl.com/docs/porting-guide/
* wolfSSL FAQ: https://www.wolfssl.com/docs/frequently … tions-faq/
Let us know if you have any issues or questions.
Thanks,
David Garske, wolfSSL
Hi ENOTTY,
The BIO_write expects WOLFSSL_BIO_SSL for an SSL socket write. Have you tried setting up a BIO with that type?
We have some BIO enhancements in the queue. See this pull request: https://github.com/wolfSSL/wolfssl/pull/2462
Thanks,
David Garske, wolfSSL
Hi pm_vnct,
Your steps for certificate and key generation look correct. The DER format should be loaded with the `WOLFSSL_FILETYPE_ASN1` option as you are doing. The -4 option is `WOLFSSL_BAD_FILETYPE`, which would happen if the format was invalid.
Here is how the use private key buffer call should look:
wolfSSL_CTX_use_PrivateKey_buffer(ctx, buff, (long)sz, WOLFSSL_FILETYPE_ASN1);For the connection to work you also need the peer to load the CA as trusted using the wolfSSL_CTX_load_verify_buffer API. You will also need to load the client certificate using wolfSSL_CTX_use_certificate_buffer.
Thanks,
David Garske, wolfSSL
Hi coco21,
We've started a dialog with Hex-Five here: https://github.com/hex-five/multizone-s … /issues/65
Feel free to join the discussion.
Thanks,
David Garske, wolfSSL
Hi coco21,
Make sure:
1. Your Makefile/build script defines the `WOLFSSL_USER_SETTINGS` macro (CFLAGS="-DWOLFSSL_USER_SETTINGS"). This will make sure the user_settings.h configuration is included and the same build configuration is used.
2. You include <wolfssl/wolfcrypt/settings.h> in your application code prior to any other wolfSSL headers.
Thanks,
David Garske, wolfSSL
Hi coco21,
Thanks for the issue report.
The user_settings.h https://github.com/hex-five/multizone-s … ngs.h#L218 has `HAVE_FFDHE_4096` set, which would require `FP_MAX_BITS` = 4096*2 or 8192.
Options are:
1. Comment out `HAVE_FFDHE_4096` to disable 4096-bit DH support.
2. Change `FP_MAX_BITS` to 8192.
We'll make sure this gets fixed in the HexFive demo.
Thanks,
David Garske, wolfSSL
Hi pm_vnct,
You are on the right track. If you register IO callbacks using `wolfSSL_CTX_SetIORecv` and `wolfSSL_CTX_SetIOSend`, then return `WOLFSSL_CBIO_ERR_WANT_READ` or `WOLFSSL_CBIO_ERR_WANT_WRITE` it will go up to the original caller wolfSSL_connect, wolfSSL_read or wolfSSL_write. This allows you to check for the return code, do other work and call again.
Here is an example for using the callbacks with want read/write:
https://github.com/wolfSSL/wolfssl-exam … callback.c
Here is an example for non-blocking:
https://github.com/wolfSSL/wolfssl-exam … ing.c#L136
Thanks,
David Garske, wolfSSL
Hi harish.reddy,
Can you also tell us a bit about the build environment you are using such as compiler, IDE and RTOS?
I'm guessing you are building the sources directly. Make sure you have added the wolfssl-root to your include path. All our code include references the root. `CFLAGS="-I<wolfssl-root>"`. For build configuration I recommend defining `WOLFSSL_USER_SETTINGS` and having your own `user_settings.h` file. You can find a good article for this here:https://www.wolfssl.com/how-do-i-manage-the-build-configuration-of-wolfssl/
Thanks,
David Garske, wolfSSL
Hi harish.reddy,
We have a good AES CBC example here, which can be adopted to GCM:
https://github.com/wolfSSL/wolfssl-exam … -encrypt.c
Our AES GCM wolfCrypt test is here:
https://github.com/wolfSSL/wolfssl/blob … st.c#L7225
Thanks,
David Garske, wolfSSL
Hi rndtk9,
The certificate chain presented by peer should have server cert first, then intermediates, then root.
From src/ssl.c line 4779:
/* Chain should have server cert first, then intermediates, then root.
* First certificate in chain is processed below after ProcessUserChain
* and is loaded into ssl->buffers.certificate.
* Remainder are processed using ProcessUserChain and are loaded into
* ssl->buffers.certChain. */
Thanks,
David Garske, wolfSSL
Hi Kit,
The call to generate an ECC shared secret uses an encrypted channel with requires a paired encryption key. The default wolfSSL examples use `atmel_get_enc_key_default`, which is all 0xFF's. You should override this function with your own implementation and key. This can be done at build-time using `ATECC_GET_ENC_KEY`.
If you'd like to use a different slot for the ephemeral key generation you can override at build time with macro `ATECC_SLOT_ECDHE_PRIV` or at runtime by registering a slot allocator using `atmel_set_slot_allocator`.
You can test if its the encryption key by replacing the `atcab_ecdh_enc` with `atcab_ecdh` in `atmel_ecc_create_pms`.
Also the ATECC chips have a watchdog that will occur if the chip isn't put into idle state when done. You'll notice calls to `atcab_idle` in our wolfcrypt/port/atmel/atmel.c to resolve this.
Feel free to email us directly at support@wolfssl.com with your user_settings.h and logs. These emails get directed into our ZenDesk system and I'll make sure and grab the incoming ticket.
Thanks,
David Garske, wolfSSL
Hi TonyM,
The TPM 2.0 specification uses the term "evict" to indicate desire to perist a key into a permanent handle. Example for Native is here:
https://github.com/wolfSSL/wolfTPM/blob … est.c#L638
The wolfTPM wrapper has lots of code examples for doing this here:
https://github.com/wolfSSL/wolfTPM/blob … ap.c#L1190
https://github.com/wolfSSL/wolfTPM/blob … est.c#L199
Most TPM's only have room for about 8 permanent keys. Another option is to use the output from TPM2_Create or TPM2_CreatePrimary, which is encrypted and store that on your device (with more storage) then use TPM2_Load to put into a temporary handle.
Thanks,
David Garske, wolfSSL
wolfSSL - Embedded SSL Library → Posts by dgarske
Powered by PunBB, supported by Informer Technologies, Inc.
Generated in 0.012 seconds (58% PHP - 42% DB) with 4 queries