1

(3 replies, posted in wolfCrypt)

Hi @sleepdefic1t,

I'm able to import the PrivateKey successfully, but am not able to generate Signatures deterministically.

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

@Cookie,

You can use the -d option when running the normal server example to disable client authentication.

For -308 when testing with the echo server try having your client use wolfTLSv1_2_client_method() (TLS v1.2) instead of wolfTLSv1_1_client_method() (TLS v1.1).

Cheers,

- KH

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

4

(3 replies, posted in General Inquiries)

Hi @roelof,

I can confirm what you are seeing in the code, the key pair is being generated but the private key does not appear to be getting decoded into the same structure. I will check with the developer that worked on that porting effort and see why there is no call to wc_RsaPrivateKeyDecode following the call to decode the public key.

I'll let you know what I find out.

Warm Regards,

K

5

(3 replies, posted in General Inquiries)

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 @torntrousers,

Please try using the below setup:

A) Define WOLFSSL_USER_SETTINGS globally or at the top of <wolfssl/wolfcrypt/settings.h> so that settings.h will look for and include the file "user_settings.h"
B) Create an empty header "user_settings.h" and use this file to tune the build
C) Include <wolfssl/wolfcrypt/settings.h> in your application
D) Update the include path for your project so "user_settings.h" can be included by settings.h.
E) Setup a custom function to seed the wolfSSL RNG with your own entropy source

// Define the type your function will be returning, for this example we'll return an unsigned int
 #define CUSTOM_RAND_TYPE      unsigned int

// Your function that provides entropy seed to "seed" the RNG declare as an extern
 extern unsigned int my_rng_seed_gen(void);

// define the wolfSSL CUSTOM_RAND_GENERATE to be your function
 #undef  CUSTOM_RAND_GENERATE
 #define CUSTOM_RAND_GENERATE  my_rng_seed_gen

Let me know if this helps.


Warm Regards,

K

7

(3 replies, posted in wolfCrypt)

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

@DS,

That is great news! I had a sneaky suspicion it was something about the input data because the app looked good. It should have been generating the same signature IFF the input was 100% identical. Happy to hear it was as simple as removing the null terminator from the input string. I see you resolved by switching from "sizeof" to "strlen", we also provide a more portable wolfSSL unique solution XSTRLEN if you ever need a more portable solution.  :-)


Cheers,

K

9

(4 replies, posted in wolfSSL (formerly CyaSSL))

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

Is the input supposed to be string or hex format? Just curious, if I leave your test app as-is I see in the output:

Digest Input Data:
65 64 36 32 33 35 39 33 36 63 35 63 38 31 63 65 
38 65 61 30 30 37 34 38 30 66 39 35 35 34 34 31 
32 30 34 36 30 35 61 30 61 36 37 37 37 66 31 37 
65 65 37 35 61 66 37 61 33 36 39 34 34 32 65 63 
00

If I modify it to hex format I see:

Digest Input Data:
ED 62 35 93 6C 5C 81 CE 8E A0 07 48 0F 95 54 41 
20 46 05 A0 A6 77 7F 17 EE 75 AF 7A 36 94 42 EC 

Changing that still doesn't get the expected output but I am not sure of the original test case. Can you send over the steps for doing this with openSSL so I can run both an OpenSSL and wolfSSL test and compare the two?

Thanks!

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,

Understood. I will bring this up with the team, would like to formally request this as a feature addition? If this ever does become a blocker for the project wolfSSL can accelerate feature additions anytime through our Business department.

Warm Regards,

K

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 just heard back from the team and I must apologize, I gave you some invalid advice on setting SAN in a CSR. This has never been supported. Setting the SAN using the method I described when generating an actual certificate is supported, with a certificate signing request it is not (and never has been) supported.

Is missing this feature a blocker for your project?

Warm Regards,

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

16

(4 replies, posted in wolfSSL (formerly CyaSSL))

Hi achimpieters,

Thank you so much for reaching out with your question. Can you tell us a bit about the background of this project and your use-case?

Typically a re-definition means that there are conflicting settings being used.

Given you are seeing an error on line 295 of types.h may I assume you are using static memory? Can you share the settings you are using to configure wolfSSL?


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.

<END EDIT>


Warm Regards,

K

@rafnas,

Not a problem! Happy to help out.

Cheers,

KH

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

Hi @coco21,

Can you tell us a bit about what it is you are working on? Is this an evaluation for an existing or upcoming project? Can you share any details about the project?

If this is for a commercial project and you do not wish to disclose details on the public forums please reach out to support@wolfssl.com for a more private channel to discuss project details!



Warm Regards,

KH

21

(0 replies, posted in Announcements)

For those interested wolfSSL just merged in support for the SiFive HiFive Unleashed board!

Checkout the changes here: https://github.com/wolfSSL/wolfssl/pull/2456

These are available in the github master and will be included in the next release.

- KH

UPDATE on related threads "SiFive":

https://github.com/wolfSSL/wolfssl/pull/2456
Support for SiFive HiFive Unleashed board

- KH

UPDATE on related threads "SiFive":

https://github.com/wolfSSL/wolfssl/pull/2456
Support for SiFive HiFive Unleashed board

- KH

Hi valcroft,

Rather than freeing the context (which will also free the context handlers) could you try only freeing and re-creating the SSL object?

If you do need to free the context factory you should try calling wolfSSL_Cleanu()p and wolfSSL_Init() also before proceeding but it isn't ideal.

- KH

25

(6 replies, posted in wolfSSL (formerly CyaSSL))

Hi harish,

Where did you download wolfSSL from? Did it come from: https://www.wolfssl.com/download/ or somewhere else?


Warm Regards,

KH