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 kackle123,
The `struct timeval` is used in wolfMQTT for socket timeout handling. If you do define `struct timeval` you don't need to increment it. The structure is used for `select()` to define the time to wait before timing out. Since the build works it means your socket layer handles `select()`, so you are good to go.
If you want to bypass setting a socket timeout in the mqttnet.c example code you can define `WOLFMQTT_NO_TIMEOUT`.
Thanks,
David Garske, wolfSSL
Hi Nathan,
I assume you have downloaded the Atmel demo `Atmel_ATECC508_Demos.zip` from the web page and are using Atmel Studio to build and debug. Are you using the SAMD21 or some other board?
Would you mind enabling our logging and sending the log output? Add the define `#define DEBUG_WOLFSSL` and call to `wolfSSL_Debugging_ON()` somewhere early in the boot process, like before wolfSSL_init().
A common reason for a fault like that is not setting the stack size high enough.
I created our ATECC508A demo and have the hardware to try and reproduce any issues, so we should be able to resolve this quickly.
Thanks,
David Garske, wolfSSL
Hi embedded,
I've done some testing and found a bug and also pushed some cleanup to this PR:
https://github.com/wolfSSL/wolfMQTT/pull/24
Let me know your results with this.
This should get merged into master this week (its in peer review). Then we have a v0.13 release planned early next week.
Thanks,
David Garske, wolfSSL
Hi embedded,
I recognize the gap in getting return codes from the NetRead back to the caller via the wolfSSL layer. There is a fix I have in mind to pass that through the callback context. I'll push a branch/pull request to GitHub shortly to better demonstrate this. I'll let you know when its available.
Thanks,
David Garske, wolfSSL
Hi,
Is there a reason you haven't updated to the latest v0.12 wolfMQTT?
https://github.com/wolfSSL/wolfMQTT/releases/tag/v0.12
I believe the issue you are seeing has been addressed in one of these commits:
https://github.com/wolfSSL/wolfMQTT/com … b726821896
https://github.com/wolfSSL/wolfMQTT/com … 86ccb31caa
Also a MQTT_CODE_ERROR_TIMEOUT is considered a failure, is there a reason you aren't returning the MQTT_CODE_CONTINUE return code in non-blocking mode from your NetRead function?
Thanks,
David Garske, wolfSSL
Hi n7ekg,
The API for performing a full hash on SHA-256 data is "wc_Sha256Hash". This wraps our internal calls and allows you to provide an input/size and get a hash output (32-bytes for SHA-256).
int wc_Sha256Hash(const byte* data, word32 len, byte* hash);
Also you can call the wolfCrypt API's directly using something like:
#include "wolfssl/wolfcrypt/sha256.h"
Sha256 sha256;
unsigned char hash[SHA256_DIGEST_SIZE];
wc_InitSha256(&sha256);
wc_Sha256Update(&sha256, data, len);
wc_Sha256Final(&sha256, hash);
Of course make sure and check the return code from these, which should be 0 on success.
Here is another example for our wolfCrypt test:
https://github.com/wolfSSL/wolfssl/blob … st.c#L1234
Let me know if that helps.
David Garske, wolfSSL
Hi n7ekg,
That pull request is going through internal automated testing and peer review. Should get merged in shortly. You can pull those changes in locally until then.
To checkout a pull request you can use:
git fetch origin pull/747/head:int_min_max
git checkout int_min_max
Thanks, David Garske, wolfSSL
Hi n7ekg,
You are having a conflict between the min() function and the local variable called min inside integer.c.
I've submitted a patch for this, since min/max as a local variable name isn't ideal.
PR #747: https://github.com/wolfSSL/wolfssl/pull/747
However you could also try defining "WOLFSSSL_HAVE_MIN".
./configure CFLAGS="-DWOLFSSSL_HAVE_MIN"
Thanks, David Garske, wolfSSL
Hi Zhouhaohua,
Is there are reason you aren't using Visual Studio to build the Windows wolfSSL simulator with the FreeRTOS_Plus_WolfSSL.sln file? I wouldn't expect the Windows Simulator to build correctly with the ARM GCC compiler (cross-compiling).
See the following page for details with using the FreeRTOS wolfSSL example:
http://www.freertos.org/FreeRTOS-Plus/W … mple.shtml
We do support FreeRTOS with ARM and have many customers using this configuration. However this example is for Windows. We make it very easy to build with FreeRTOS as the OS using the define "FREERTOS". Next step is to setup the socket handling. If you are using FreeRTOS TCP then you'd want to define "FREERTOS_TCP" or if using LWIP define "WOLFSSL_LWIP".
It looks like you are building for an LPC part. Have you seen our LPC example here located here?
https://github.com/wolfSSL/wolfssl/tree … LPCXPRESSO
Thanks, David Garske, wolfSSL
Hi Sachin,
Yes we have many customers using wolfSSL and wolfMQTT on a bare-metal implementation with no RTOS. I recommend defining SINGLE_THREADED, which disables the RTOS (mutex/threading) support.
Thanks,
David Garske, wolfSSL
Hi Carlos,
I was able to reproduce the UnPadding error if the server didn't have the right private key loaded for the certificate. In the example you provided above the private key is in DER (ASN1) format and the loading of the private key buffer should be done as follows:
ret = wolfSSL_CTX_use_PrivateKey_buffer(ctx, privkey_der_2048, sizeof(privkey_der_2048), SSL_FILETYPE_ASN1);Make sure and check the return code for this call and the wolfSSL_CTX_use_certificate_buffer function. Its possible your call was using SSL_FILETYPE_PEM and failing.
As for the example you sent for rsa_test I was able to get it working, but I had to add an include for wolfssl/options.h prior to settings.h to make sure the compiled library settings matched the application.
Here is the working rsa_test example:
#ifdef HAVE_CONFIG_H
#include <config.h>
#endif
#include <wolfssl/options.h>
#include <wolfssl/wolfcrypt/settings.h>
#include <wolfssl/ssl.h>
#include <wolfssl/wolfcrypt/rsa.h>
#include <wolfssl/wolfcrypt/memory.h>
#include <wolfssl/wolfcrypt/error-crypt.h>
#include <wolfssl/wolfcrypt/tfm.h>
#include <wolfssl/wolfcrypt/logging.h>
volatile unsigned int pico_ms_tick = 0;
int close(int __fildes){
return 0;
}
#define HEAP_HINT 0
#define FOURK_BUF 4096
/* privkey.der, 2048-bit */
const unsigned char privkey_der_2048[] =
{
...
};
int rsa_test(void)
{
byte* tmp = NULL;
size_t bytes;
RsaKey key;
WC_RNG rng;
word32 idx = 0;
int ret;
byte in[] = "Everyone gets Friday off.";
word32 inLen = (word32)XSTRLEN((char*)in);
byte out[256];
byte plain[256];
byte* outPtr = NULL;
tmp = (byte*)XMALLOC(FOURK_BUF, HEAP_HINT, DYNAMIC_TYPE_TMP_BUFFER);
if (tmp == NULL) {
ret = MEMORY_E;
goto exit;
}
XMEMCPY(tmp, privkey_der_2048, sizeof(privkey_der_2048));
bytes = sizeof(privkey_der_2048);
ret = wc_InitRsaKey_ex(&key, HEAP_HINT, INVALID_DEVID);
if (ret < 0) {
goto exit;
}
ret = wc_RsaPrivateKeyDecode(tmp, &idx, &key, (word32)bytes);
if (ret < 0) {
goto exit;
}
printf("Key Size: %d\n", wc_RsaEncryptSize(&key));
ret = wc_InitRng(&rng);
if (ret < 0) {
goto exit;
}
#ifdef WC_RSA_BLINDING
ret = wc_RsaSetRNG(&key, &rng);
if (ret < 0) {
goto exit;
}
#endif
ret = wc_RsaPublicEncrypt(in, inLen, out, sizeof(out), &key, &rng);
printf("wc_RsaPublicEncrypt: %d\n", ret);
if (ret < 0) {
goto exit;
}
idx = ret; /* save off encrypted length */
ret = wc_RsaPrivateDecrypt(out, idx, plain, sizeof(plain), &key);
printf("wc_RsaPrivateDecrypt: %d\n", ret);
printf("\n%d", ret);
if (ret < 0) {
goto exit;
}
if (XMEMCMP(plain, in, ret)) {
printf("Compare failed!\n");
goto exit;
}
ret = wc_RsaSSL_Sign(in, inLen, out, sizeof(out), &key, &rng);
printf("wc_RsaSSL_Sign: %d\n", ret);
if (ret < 0) {
goto exit;
}
idx = ret;
XMEMSET(plain, 0, sizeof(plain));
ret = wc_RsaSSL_VerifyInline(out, idx, &outPtr, &key);
printf("wc_RsaSSL_Verify: %d\n", ret);
if (ret < 0) {
goto exit;
}
if (XMEMCMP(in, outPtr, ret)) {
printf("Compare failed!\n");
goto exit;
}
ret = 0; /* success */
exit:
wc_FreeRsaKey(&key);
XFREE(tmp, HEAP_HINT, DYNAMIC_TYPE_TMP_BUFFER);
wc_FreeRng(&rng);
return ret;
}
int main()
{
int32_t ret;
#if defined(DEBUG_WOLFSSL)
wolfSSL_Debugging_ON();
#endif
wolfCrypt_Init();
#if !defined(NO_BIG_INT)
if (CheckCtcSettings() != 1)
printf("\nBuild vs runtime math mismatch\n");
#ifdef USE_FAST_MATH
if (CheckFastMathSettings() != 1)
printf("\nBuild vs runtime fastmath FP_MAX_BITS mismatch\n");
#endif /* USE_FAST_MATH */
#endif /* !NO_BIG_INT */
ret = rsa_test();
printf("\nret %d", ret);
return 0;
}Please let me know your results.
Thanks,
David Garske, wolfSSL
Hi Sachin,
Thanks for the report about the wolfmqtt-0.12.zip archive on the website. Its been fixed.
You only need wolfSSL if you are using TLS with MQTT to secure the pipe (socket). By default wolfMQTT "./configure" enables TLS, so if you aren't using TLS then use "./configure --disable-tls". If not using ./configure the define to enable/disable TLS support is "ENABLE_MQTT_TLS".
The wolfMQTT download has several examples including an AWS IoT, Azure IoT Hub, Firmware Update and basic MQTT client.
The latest user manual is here:
https://www.wolfssl.com/documentation/w … Manual.pdf
Let me know if you had any other questions.
Thanks,
David Garske, wolfSSL
Hi Carlos,
Try using wc_InitRsaKey(&key) and not the _ex version. If you use _ex make sure your HEAP_HINT is NULL and devId is INVALID_DEVID.
What key size are you trying to use with your RSA server certificate? Our library enables RSA 2048-bit by default and you would need to define a higher FP_MAX_BITS (key size * 2). Can send me the public self-signed server certificate that you are using?
Also make sure you have HAVE_TLS_EXTENSIONS and HAVE_SUPPORTED_CURVES defined if using ECDHE and TLS.
If you are able to make the server external that would help us be able to test against it. Feel free to reach out to us at support@wolfssl.com if you don't want any of your server information public on the forum.
You have a great holiday as well!
Thanks,
David Garske, wolfSSL
Hi crmoratelli,
Which version of wolfSSL are you using? You can find it noted in wolfssl/version.h.
Can you try connecting to your https server using the following and send back the results?
openssl s_client -host [your host] -port [your port] -showcerts
For the wolfCrypt test I was not able to reproduce with the latest in master. But curious if changing your test so out and plain are sized as 128 and let me know your results:
byte out[128];
byte plain[128];
Also in the test try changing "ret = wc_InitRsaKey_ex(&key, HEAP_HINT, devId);" to use "ret = wc_InitRsaKey(&key);".
If you want to send an email to support@wolfssl.com with your https server host/port so we can test against it that would be wonderful.
Thanks,
David Garske, wolfSSL
Hi Thomas,
Please try using the "WC_SIGNATURE_TYPE_RSA_W_ENC" sig_type. This adds a DER encoded header to the hash prior to the verify. This type typically required when using RSA signatures generated from openssl.
Thanks,
David Garske, wolfSSL
Hi Zine314,
It looks like the AES CCM* (star) spec adds variable length auth tags plus some encoding info. We do support the normal AES CCM block cipher, which AES CCM* is backwards compatibility with, but we do not support CCM*.
I put this on our feature request list. We do offer consulting services to help expedite features. If you would like more info on this option please email us at info@wolfssl.com.
Thanks,
David Garske, wolfSSL
Hi Andrey,
Assuming you can get a server certificate with SHA384 digest and signed by a CA with a SHA384 digest and have a real HW RNG source (which you do) then you can disable SHA256. The commit that has this support is here:
https://github.com/wolfSSL/wolfssl/comm … df9e89bab0
With the way the random.c code is structured the wc_GenerateSeed function for STM32F2_RNG will not be available with CUSTOM_RAND_GENERATE_BLOCK defined. So best solution is to copy/paste the wc_GenerateSeed function at line 1414 into your own .c file and then you can do something like what you suggested. The code would look like:
/* Put this in your own .c file */
#undef RNG
#include "stm32f2xx_rng.h"
#include "stm32f2xx_rcc.h"
/*
* wc_Generate a RNG seed using the hardware random number generator
* on the STM32F2. Documentation located in STM32F2xx Standard Peripheral
* Library document (See note in README).
*/
int custom_rand_generate_block(byte* output, word32 sz)
{
int i;
/* enable RNG clock source */
RCC_AHB2PeriphClockCmd(RCC_AHB2Periph_RNG, ENABLE);
/* enable RNG peripheral */
RNG_Cmd(ENABLE);
for (i = 0; i < sz; i++) {
/* wait until RNG number is ready */
while(RNG_GetFlagStatus(RNG_FLAG_DRDY)== RESET) { }
/* get value */
output[i] = RNG_GetRandomNumber();
}
return 0;
}
/* Put this into user_settings.h */
/* Bypass P-RNG and use only HW RNG */
extern int custom_rand_generate_block(unsigned char* output, unsigned int sz);
#undef CUSTOM_RAND_GENERATE_BLOCK
#define CUSTOM_RAND_GENERATE_BLOCK custom_rand_generate_blockThanks,
David Garske, wolfSSL
1. It depends on your architecture and where it puts the stack region, but technically if a stack value is used and isn't cleared then it has the potential to be available later. That is why we use ForceZero on any private data after we are done with it.
2. Only the private (sensitive) information is cleared with ForceZero and that is always enabled. We don not have an option to clear all stack variables, but you could change the mp_clear to do a ForceZero and it would clear the dp section of the big integers. Also there is a GCC compiler option in the works for clearing stack. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69976
3. It depends on the math implementation used. We have a "normal" math and "fast" math (USE_FAST_MATH). The fast math uses stack and the normal math uses heap. So only the normal math uses dynamic mem (heap) for the big integer data.
Let me know if you have any other questions,
David Garske, wolfSSL
You are welcome. Internally we are careful to free any private information using the ForceZero() function. If you find places that you think memory should be cleared please let me know. The ForceZero() function ensures that the compiler doesn't optimize out a memset on a stack variable at the end of a function.
Hi, it sounds like you are looking for a way to clear allocated buffer with zero's on the free? If you are overriding the allocators for wolfSSL then you could do something like this:
void* my_Malloc(size_t size)
{
void* ptr;
ptr = malloc(size + sizeof(size_t));
if (ptr) {
*(size_t*)ptr = size;
ptr += sizeof(size_t);
memset(ptr, 0, size);
}
return ptr;
}
void my_Free(void *ptr)
{
if (ptr) {
size_t size = 0;
ptr -= sizeof(size_t);
size = *(size_t*)ptr;
memset(ptr, 0, size);
free(ptr);
}
}
wolfSSL_SetAllocators(my_Malloc, my_Free, NULL);This allocates some extra space at the front and stores the length in it. Let me know if that makes sense or not.
Thanks,
David Garske, wolfSSL
Hi Majkel,
You are correct that you only need the public key x and y plus the signature r and s to verify an ECC signature. Are these all in hex string format like "0102030405060708090A" or unsigned bin? How were these values generated? Typically the R and S values are encoded with a DSA DER header. The public key is typically encoded into a x963 format, which is a small header and raw x then y values.
The functions you'll want to use are wc_ecc_rs_to_sig() and wc_ecc_import_x963().
If you don't have encoded X,Y and R,S values then you can use mp_read_unsigned_bin to import the raw binary into public key such as:
ecc_key key;
wc_ecc_init(&key);
mp_init_multi(key->pubkey.x, key->pubkey.y, key->pubkey.z, &key->k, NULL, NULL);
mp_read_unsigned_bin(key->pubkey.x, x_buf, x_len);
mp_read_unsigned_bin(key->pubkey.y, y_buf, y_len);
mp_set(key->pubkey.z, 1);
// Then you'll have an ecc_key with public key
int status;
wc_ecc_verify_hash(sig, sigSz, hash, hashSz, &status, &key);
You can also use the "wc_SignatureVerify()" wrapper function. Examples for this are here:
https://github.com/dgarske/wolfssl-exam … /signature
Thanks and looking forward to your reply.
David Garske, wolfSSL
Hi Cxdinter,
Correct, those are the porting options. Its difficult for me to guess, which is better for you and the Poco library without a more detailed review.
For the first option you may have to implement some additional openssl compatibility API's. They have over 4000 API's and we only cover the most common ones. If you do add some and would like to contribute changes back to us that would be wonderful. We only require a signed contributor agreement, which I can send you.
We have more examples in this repo:
https://github.com/wolfSSL/wolfssl-examples
Some clean TLS examples are in this folder:
https://github.com/wolfSSL/wolfssl-exam … master/tls
Thanks,
David Garske, wolfSSL
Hi Andrey,
To clarify you would only need to do CUSTOM_RAND_GENERATE_BLOCK if you wanted to disable SHA256. Our P-RNG (pseudo random number generator) uses SHA256.
I recommend leaving SHA256 enabled and leaving your RNG settings as they are with STM32F2_RNG and wc_GenerateSeed seeding the P-RNG. You will find that most certificates use SHA256 for the digest and so you'll likely need it anyways even with a SHA384 TLS cipher suite.
Let me know if you need further clarification.
Thanks,
David Garske, wolfSSL
Hi Cxdinter,
We are continually working to add new openssl compatibility API's. You'll find the ones you are missing in the pull request #618, which should make it into master shortly.
https://github.com/wolfSSL/wolfssl/pull/618
SSL_CTX_ctrl:
https://github.com/wolfSSL/wolfssl/pull … 2c5b9R5625
SSL_ctrl:
https://github.com/wolfSSL/wolfssl/pull … 2c5b9R5614
We also just added a bunch on Nov 10th in PR #617 into master:
https://github.com/wolfSSL/wolfssl/pull/617
Commit: https://github.com/wolfSSL/wolfssl/comm … 4537f5279f
Hopefully that will help with the Poco port you are working on. Let us know if there is anything else.
Your feedback has been very excellent, so thank you!
David Garske, wolfSSL
Hi Will,
The EmbedReceiveFrom and EmbedGenerateCookie functions are for DTLS (with WOLFSSL_DTLS defined). The "struct sockaddr_storage" is a POSIX compliant data type for UDP.
If you are using DTLS and called wolfSSL_CTX_new with a wolfDTLSv1_2_client_method or wolfDTLSv1_client_method then you'll want to implement your own IO callbacks for the read/writes.
To do this define WOLFSSL_USER_IO and set the callbacks using wolfSSL_SetIORecv, wolfSSL_SetIOSend and wolfSSL_set_fd. A good example for this is here:
https://github.com/wolfSSL/wolfssl-exam … ack.c#L182
Let me know if you have any other questions or issues.
Thanks,
David Garske, wolfSSL
wolfSSL - Embedded SSL Library → Posts by dgarske
Powered by PunBB, supported by Informer Technologies, Inc.
Generated in 0.025 seconds (77% PHP - 23% DB) with 4 queries