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_block

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

Hi Cxdinter,

Good find. It looks like the wc_EccPrivateKeyDecode doesn't support importing a custom key and passing the OID to the "wc_ecc_import_private_key" function. I did the implementation for the custom curve ECC support, but missed this import path. I've pushed changes to support this to pull-request 631.
https://github.com/wolfSSL/wolfssl/pull/631

I tested it using the following:

ecc_key key;
byte der[4096];
byte buf[4096];
word32 idx = 0;
FILE* derFile;
size_t sz;

RNG rng;

wc_InitRng(&rng);
wc_ecc_init(&key);

if (wc_ecc_make_key_ex(&rng, 32, &key, ECC_BRAINPOOLP256R1) != 0) {
    printf("error making ecc key\n");
    return -1;
}

/* write private key */
if (wc_EccKeyToDer(&key, der, sizeof(der)) < 0) {
    printf("error in ecc to der\n");
    return -1;
}
printf("writing private key to ecc-key.der\n");
derFile = fopen("ecc-key.der", "w");
if (!derFile) {
    printf("error loading file\n");
    return -1;
}

sz = fwrite(der, 1, 4096, derFile);
fclose(derFile);
wc_ecc_free(&key);


/* open and read from der file */
printf("reading in private key\n");
derFile = fopen("ecc-key.der", "rb");
if (!derFile) {
    printf("error reading from file\n");
    return -1;
}

sz = fread(buf, 1, 4096, derFile);
fclose(derFile);

/* load private ecc key */
printf("storing private key in ecc struct\n");
wc_ecc_init(&key);
if (wc_EccPrivateKeyDecode(buf, &idx, &key, (word32)sz) != 0) {
    printf("error decoding private key\n");
    return -1;
}
wc_ecc_free(&key);

wc_FreeRng(&rng);

Please give it a try and let me know how it goes.

Thanks,
David Garske, wolfSSL

Hi Cxdinter,

If you define HAVE_ECC_BRAINPOOL then it will enable the Brainpool curves, however you must create the ECC key using wc_ecc_make_key_ex to tell the ECC layer you want to use that curve type:

ecc_key key;
ret = wc_ecc_init(&key);
ret = wc_ecc_make_key_ex(rng, 32, &key, ECC_BRAINPOOLP256R1);

Then you can call wc_SignatureGenerate.

The best way to add defines if not using ./configure is to globally define WOLFSSL_USER_SETTINGS (like in your CFLAGS) and add a new user_settings.h file somewhere in your include path.

There is a good user_settings.h example here:
https://github.com/wolfSSL/wolfssl/blob … settings.h

Also, if you haven't seen it there is a great signature/verify example here:
https://github.com/wolfSSL/wolfssl-exam … /signature
Although its missing the custom ECC curve example above, so I'm going to add that soon.

Thanks,
David Garske, wolfSSL

Hi cxdinter,

Thank you so much for the report.

It looks like that scenario could happen if your call to wc_RNG_GenerateBlock did not return 0 (in wc_ecc_make_key_ex at line 2507). In that case variable "a" would be un-initialized from the stack and the call to "mp_clear" could cause a seg fault due to invalid pointer.

Will you confirm your wc_RNG_GenerateBlock return code? It should be zero indicating success.

I've pushed a fix for that here:
https://github.com/wolfSSL/wolfssl/pull/626

Let me know if that helps.

Thanks,
David Garske, wolfSSL

Hi Jesussotofan,

All calls to wc_GenerateSeed are in wolfcrypt/src/random.c. There are multiple places where this function exists depending on the hardware platform. Those start at line 1133.

If you are defining CUSTOM_RAND_GENERATE_SEED then it will use the function used in that define. I'd also make sure you don't have NO_DEV_RANDOM defined.

The function wc_InitRng calls wc_GenerateSeed. Make sure the wolfcrypt/src/random.c is being included with the build. Make sure you have a wc_GenerateSeed function in your random.c or use the CUSTOM_RAND_GENERATE_SEED define to remap it to your own function.

Have you seen our Arduino example for wolfSSL?
https://github.com/wolfSSL/wolfssl/tree … DE/ARDUINO

Thanks,
David Garske, wolfSSL

Hi Jesussotofan,

Your platform must not have a random number seed function defined in random.c (starting at line 1133).

Either you can:
1. Locate a reference implementation in random.c and make sure you have the right define set for your hardware platform / OS.

2. Define CUSTOM_RAND_GENERATE_SEED and use your own implementation:

int rand_gen_seed(byte* output, word32 sz);
#define CUSTOM_RAND_GENERATE_SEED  rand_gen_seed

In your example above, I also recommend:
including:
#include <wolfssl/wolfcrypt/random.h>

Using WC_RNG for the rng global:
WC_RNG rng;

Let me know if you have anymore questions,

Thanks,
David Garske, wolfSSL

Hi Hagai,

That's great you are using wolfMQTT and wolfSSL with Amazon AWS! It would be excellent to get more info on your project by emailing us at info@wolfssl.com when you get a chance.

I've seen an issue like this before and it was due to timezone differences between local time and the time in the cert. The ValidateDate function tries to offset the local time by looking for +/- at the end of the cert begin/end dates.

If you are using the FREESCALE_MQX or FREESCALE_KSDK_MQX defines the asn.c XTIME gets mapped to mqx_time which ends up calling "_time_get". The mqx_time function should be getting the number of seconds since UTC.

You might consider implementing your own XTIME function and by defining "USER_TIME" and adding a new function in your code called XTIME: time_t XTIME(time_t * timer);. Then you can offset the XTIME your timezone diff.

Thanks, David Garske, wolfSSL

Hey Avenuti,

I am able to reproduce the error with normal math and ECC-521 on that board. I was then also able to reproduce on my Mac with 32-bit mode (-m32) and NO_64BIT defined. Happens with or without ECC_TIMING_RESISTANT.

This failure only happens on 32-bit systems with normal math. Until then please use fast math with ECC-521.

For reference the error is:
"ecc_test_curve_size 66 failed!: -1023
ECC      test failed!
error = -1023"

The error is happening inside the "ecc_check_pubkey_order" function, which returns -215 (ECC_INF_E).

We are investigating the cause and will let you know when we have a resolution. Thanks again for the report!

Thanks, David Garske, wolfSSL