Hi Betontod11,

Thank you so much for reaching out to wolfSSL support. Have you tried using non-blocking sockets?

Warm Regards,

K

Hi @sleepdefic1t,

Great! That indicates it is working. If the signature were deterministic that would be cause for concern.

ECC (unlike RSA) does not produce the same output every time, nor does it produce the same length every time! ECC signatures can vary by as much as 5-bytes (sometime more). IE you might sign the same data 100 times and see signatures that range from 70 - 75 bytes in length. This is expected and common with ECC. I see you are already doing a sanity check using the verify to double-check the signature, that is good! Below are a series of signature generation/verification calls on the same exact input data I ran locally. (You can also use a third party verify operation if you want to triple check it.)

Hexdump: Signature of length 71
Should output 4 lines
3045022073e648793a98424f345c06f0a6
63f406b82a3321702e692c0d6926fefa
681183022100a2fb9275f9b61f253564
26c745e6be56e43f134953931b54edbd
cefd802bf17c

Signature verification was successful!
Hexdump: Signature of length 70
Should output 4 lines
30440220106f09553c87c6a6622403503d
28b6469280d735207d29f614ec0da823
33608702204f0549bb242fb69e9939f5
f269f0720f624288ce9ae4d5dd27a304
fc84c63f8a

Signature verification was successful!
Hexdump: Signature of length 72
Should output 4 lines
304602210092aa287e79f309f686e98108
d11a0851b91ea9556e55954c7cfd2c49
97f6ca1c022100b3876fec6dcddc6546
a57d12fc0bd8e17930fd2af9f1049c77
fead7eba57e9c6

Signature verification was successful!
Hexdump: Signature of length 70
Should output 4 lines
304402205268f74dec640c683a92bde39c
a3125fa3b52cf54ab8f4439676a7bf9d
87a11a022065ab167156d580a328068f
1acd4de3fc35cf61e5b8df41c618466e
a9637cea3c

Signature verification was successful!
Hexdump: Signature of length 71
Should output 4 lines
304502207819fa3c308d7337b13c232fc9
a0b4d6ae7d1432fcdbd57b116d1a9aef
6da855022100ad65c70fd7fec03b70a7
5708d1512f08c98e3b7ecf84b4974ab3
7d0c3053f0ad

Signature verification was successful!

Warm Regards,

K

So when we initialize the RNG structure we run a "health test" to ensure that repetitive calls to the generate seed function do not return predictable data. If you want to reduce the number of checks you could try modifying the wc_RNG_HealthTestLocal function to call wc_RNG_HealthTest() less times though this is a good test to perform and we do not recommend reducing the number of health checks.

Regards,

K

Hi @roelof,

Thank you for using the wolfSSL forums. You'll note that in the case of not using crypto cell support the RNG and wc_GenerateSeed function are fully implemented. If you defined WOLFSSL_NRF5x the define NO_DEV_RANDOM is assumed in wolfssl-root/wolfssl/wolfcrypt/settings.h and it is expected that the user will either implement a device-specific version of generate seed to seed the wolfSSL hash DRBG. For reference please checkout the wc_GenerateSeed function in wolfssl-root/wolfcrypt/src/random.c when WOLFSSL_NRF51 is defined.

It is likely you would have seen some warnings in the build step if something was amiss. Can you tell us if the build was warning-free or were there any warnings generated?

Warm Regards,

K

Hi @sleepdefic1t,

Thanks for reaching out to wolfSSL. To get you started down the correct path I would suggest looking at wc_PBKD2. This is a password based key derivation function.

You could use it to generate ECC k value and then read k in with

ret = mp_read_unsigned_bin(&key->k, key, keySz);)

NOTE: You will want to add a sanity check that the generated K is less than the curve order (See "ecc_set_type" in ecc.h)

Next you'll need to call

wc_ecc_make_pub

to make the public portion of the key.

Finally since you are using any old passphrase and hashing it, using the hash to generate K with password based key derivation and then reading that into the key you can't really be sure that it's a valid K that lands somewhere on the curve right? So now you'll want to check the key you created is valid. For that use

wc_ecc_check_key

. Fail condition is if wc_ecc_check_key fails, need to either ask user for new input or come up with a method for adjusting the hash of the user input when used to generate K will more consistently fall on the curve.

Hope this helps.

Warm Regards,

K

@achimpieters,

It sounds like something in the file <wolfssl/wolfcrypt/settings.h> is defining XREALLOC to be one thing but then later in wolfssl/wolfcrypt/types.h where we try to detect based on OS/OE and set it smartly there is something not being skipped. Can you try adding a condition to types.h for

&& !defined(<>)

and replace the "<>" with the setting from settings.h that is defined and causing XREALLOC to be configured in settings.h?

It's hard to pin-point exactly without being able to test/build it but from the log we see the original definition is in settings.h on line 669 which in the version of settings.h I'm looking at from 4.1.0 would be in the FREERTOS section.

/project/components/common/wolfssl/wolfssl-4.1.0/wolfssl/wolfcrypt/settings.h:669:0: note: this is the location of the previous definition
         #define XREALLOC(p, n, h, t) wolfSSL_Realloc((p), (n))

In types.h the re-definition happens on line 295 which is inside a section protected by the setting "NO_WOLFSSL_MEMORY" setting which leads me to believe that somehow both FREERTOS and NO_WOLFSSL_MEMORY are getting set together.

/project/components/common/wolfssl/wolfssl-4.1.0/wolfssl/wolfcrypt/types.h:295:0: warning: "XREALLOC" redefined [enabled by default]
         #define XREALLOC(p, n, h, t) realloc((p), (n))

To resolve you can either remove NO_WOLFSSL_MEMORY from any custom settings you are using or you can add a second condition on line 273 of types.h to be:

#elif defined(NO_WOLFSSL_MEMORY) && !defined(FREERTOS)

Warm Regards,

K

Hi @DS,

Thank you for reaching out to wolfSSL. Please checkout our example here that does signature generation using the same method as OpenSSL

https://github.com/wolfSSL/wolfssl-exam … re/sigtest

It looks like you may have missed the step to encode the hash before calling wc_SignatureGenerate. Encoding the hash is an extra step OpenSSL does but that is opaque to the end user. I do wish the OpenSSL project would make more clear the steps being taken in their logs. This question does come up about 2 - 3 times a year, thus why we finally put up an example for it :-)

https://github.com/wolfSSL/wolfssl-exam … est.c#L165

Warm Regards,

KH

waigor,

Gotcha, I did just run a quick test using the openSSL command line tool and it does work:

Save this to file "tmp.txt"

[ req ]
default_bits = 4096
prompt = no
encrypt_key = no
default_md = sha256
distinguished_name = dn
req_extensions = req_ext

[ dn ]
CN = myquicktest.com
emailAddress = kaleb@wolfssl.com
O = wolfSSL Inc.
OU = Support
L = Florence
ST = MT
C = US

[ req_ext ]
subjectAltName = DNS: www.domain1.com, DNS: www.domain2.com, DNS: www.domain3.com

Run the command:

openssl req -new -config tmp.txt -keyout myquicktest.key -out myquicktest.csr

Upload the contents of myquicktest.csr to the csr checker at https://ssltools.digicert.com/checker/v … rCheck.jsp

SANs' are included. (See attached screenshot)

Not sure why the CSR checker complains about us Montanan's but apparently it doesn't know what state MT is :-)

- K

Hi waigor,

I was just doing some code review for another customer and while I can confirm setting the SAN using this method does work when generating a real cert, it looks like setting the SAN in a CSR is not supported, I do apologize.

I am checking with our ASN.1 experts to see if this was ever support for certificate requests or only with cert generation.

I'll let you know what I find out.

Warm Regards,

K

Hi waigor,

Thank you for reaching out to wolfSSL. Can you share a bit about what you are working on and end goals for your project? This helps us to better classify the inquiry for our records.

<EDIT>

Setting the SAN in CSR generation is not supported at this time. Using the method described in the other post is supported when generating an actual certificate.

Other Post: https://www.wolfssl.com/forums/topic140 … l-api.html

<END EDIT>

Warm Regards,

K

Hi rafnas,

It looks like pastebin.com expects the server name indication extension. Could you try adding the setting HAVE_SNI if not already present and then send the sting "pastebin.com" as the server name indication extension using the -S option in the client (see example below)

$ client.exe -h pastebin.com -p 443 -v d -d -g
wolfSSL_connect error -313, received alert fatal error
wolfSSL error: wolfSSL_connect failed

$ client.exe -h pastebin.com -p 443 -v d -d -g -S pastebin.com

SSL version is TLSv1.2
SSL cipher suite is TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
SSL curve name is SECP256R1
SSL connect ok, sending GET...
HTTP/1.1 403 Forbidden
Server: cloudflare
Date: Mon, 30 Sep 2019 16:48:42 GMT
Content-Type: text/html
Content-Length: 167

Connection: close
CF-RAY: 51e7af9bbb9b79a7-SEA

<html>
<head><title>403 Forbidden</title></head>
<body bgcolor="white">
<

Warmest Regards,

KH