Hi ravi.kumar,

The key is improperly formatted. I'm honestly surprised openssl is able to parse it. Just do this command and compare the outputs:

openssl rsa -inform pem -in private_key.pem -outform pem -out private_key_try2.pem

now diff the two files and you'll see they do not match in any way. If you do the same command on our existing ca-key.pem in the <wolfssl-root>/certs directory:

openssl rsa -inform pem -in ca-key.pem -outform pem -out ca-key_try2.pem

and diff those two files they remain identical in every way. Could you tell us where you got that RSA key you are using and how it was generated?

Fix for your issue is to use the resulting "private_key_try2.pem" from the command above. That is RFC compliant formatting and our libraries process it just fine.

Kind Regards,

Hi Subhash,

The following is the response from Texas Instruments:

I hope this helps in your decision making process.

Regards,

Kaleb

Hi Subhash,

I am looking into this and will get back to you as soon as I have any information.

Regards,

Kaleb

Hi lwatcdr,

Have you read our documentation in the manual on certificate usage? https://wolfssl.com/wolfSSL/Docs-wolfss … cates.html
Have you seen our examples on github https://github.com/wolfSSL/wolfssl-exam … rtmanager?
Have you looked at the usage example in wolfcrypt/test/test.c?

All of these may be extremely useful in assisting you with your project!

It is possible.
The WOLFSSL_CTX Structure contains a WOLFSSL_CERT_MANAGER* cm;

ctx->cm

The CERT_MANAGER contains a Signer* caTable[CA_TABLE_SIZE]

ctx->cm->caTable

and whichever Signer contains the byte* public key you desire to extract.

ctx->cm->caTable[<whichever signer>]->publicKey

No. As the API suggests this is "Initializing" a decoded certificate. So it is setting every value of the certificate structure to 0, or some default value. It is not actually decoding anything yet. It is just initializing the structure so it is not NULL.

Again no. InitDecodedCert does not convert or decode anything. I believe you are looking for the function: "ParseCert"

Regards,

- Kaleb

Hi rskkya,

It just sounds like there is a disagreement between the wolfssl libraries and your project. You have defined FREERTOS in the configuration of the wolfssl libraries so all the relevant portions of code were added to the libraries that you are now linking against however it sounds like your project does not have FREERTOS defined.

In your project could you try including <wolfssl/wolfcrypt/settings.h> and then your project will get the define for FREERTOS as well (since as you stated previously you had uncommented that define).

Regards,

-Kaleb

Hi rskkya,

You have:

./configure LIBS="-lc -lm -lgcc -lrdimon"  CPPFLAGS="-I/usr/include/"  --disable-examples --enable-aesgcm --enable-camellia --enable-sha512 --enable-keygen --enable-certgen --enable-dsa --enable-ecc --host=arm-none-eabi CC= arm-none-eabi-gcc  AR=arm-none-eabi-ar RANLIB=arm-none-eabi-ranlib  --build= x86-linux-64 march=armv7 mcpu=cortex-m3

could you try also setting the assembly language compiler:
AS=arm-none-eabi-gcc

could you try also setting the Linker/loader:
LD=arm-none-eabi-ld

could you try adding the following to CFLAGS:
-specs=rdimon.specs
-O0 (that is a capital "OH" and a zero for optimization level 0)
-DFREERTOS

If you intend to do any debugging you can add the "-g" flag for debug symbols to CFLAGS as well.

so you should end up with something like this:

./configure LIBS="-lc -lm -lgcc -lrdimon"  CPPFLAGS="-I/usr/include/"  --disable-examples --enable-aesgcm --enable-camellia --enable-sha512 --enable-keygen --enable-certgen --enable-dsa --enable-ecc --host=arm-none-eabi CC= arm-none-eabi-gcc  AR=arm-none-eabi-ar RANLIB=arm-none-eabi-ranlib AS=arm-none-eabi-gcc LD=arm-none-eabi-ld --build= x86-linux-64 march=armv7 mcpu=cortex-m3 CFLAGS="${CFLAGS} -DFREERTOS -O0 -specs=rdimon.specs"

If you still have issues after trying these changes let us know.

NOTE: If you define FREERTOS wolfSSL will look for various header files including FreeRTOS.h FreeRTOSConfig.h etc. You can add multiple include paths to get these headers for example above you had:

CPPFLAGS="-I/usr/include/"

Just extend that to be:

CPPFLAGS="-I/usr/include/ -I/path/to/FreeRTOS.h -I/path/to/FreeRTOSConfig.h -I/any/other/header/paths/etc"

Regards,

- Kaleb

Hi an.scall,

Have you seen our README on github for building TIRTOS with wolfSSL? I noticed you edited the .mak in our directory. Rather you should be modifying the .mak in ti/ directory.

You can find the README here: https://github.com/wolfSSL/wolfssl-exam … /README.md

I just worked through those same steps but instead of using

C:\

file paths I used

/home/khimes/ti 

and

/home/khimes/wolfssl

.
Everything worked beautifully for setting up and building the tcpEchoTLS example provided by TI in their examples repo. There would be a lot of modifications required to get our examples off github working in Linux. That is something I plan to do in the future but have not had time to work on yet. However the readme will get you going on Linux.

Best Regards,

- Kaleb

Hi kranthi,

You said the return code is not MP_OKAY, can you tell us what the return code is that you are seeing?

Regards,

- Kaleb

Hi Michael,

Sounds like a good plan. We look forward to hearing your progress. For a more private channel (posting logs and traces) feel free to open a ticket by sending an email to support@wolfssl.com or via zendesk directly.

Best Regards,

- Kaleb

Hi Michael,

From previous experience with similar issues IE "fails but not when run in the debugger" my first thought is that the state machine is not handling the threads properly. Could you configure wolfSSL with SINGLE_THREADED defined and see if that resolves the issue?

If it does you may need to implement some form of mutual exclusion / locking mechanism in the state machine if using wolfSSL in a multi-threaded fashion.

I look forward to your results.

Regards,

- Kaleb

Hi gawiz,

Our mp_int structure is laid out as seen below. You can view this structure in <wolfssl_root>/wolfssl/wolfcrypt/integer.h

 /* the infamous mp_int structure */                                             
 typedef struct  {                                                               
     int used, alloc, sign;                                                      
     mp_digit *dp;                                                               
 } mp_int;

The Visual Studio compiler is complaining that the mp_digit pointer (dp) is potentially not initialized. By assigning 0x0 to this pointer at the time of declaration you can silence this warning. I would add a comment to note this is only to silence an MSVS static analysis warning.

I did the following in integer.c:

 static int mp_div_d (mp_int * a, mp_digit b, mp_int * c, mp_digit * d)          
 {                                                                               
   mp_int  q;
   q.dp = NULL;

... rest of the function here ...
 }

Evaluating this thoroughly we have proven it can never be "uninitialized" by the time the assignment takes place. This is a false positive from MSVS.

Proof follows:

if c IS NOT NULL the mp_init_size will initialize q and malloc q.dp
The first time q is used if c IS NULL (outside the first if block) is in the for loop.
The value of c can not change between if block and for loop.
the value of c can not change within the for loop
before q is used in the for loop (the line MSVS complains about) c is again evaluated
if c IS NULL q will not be used / cannot be used "uninitialized"
we can conclude the following:

q is used iff c != NULL.
if c != NULL q is initialized in the if block (line 4096 below)
c cannot become NULL between if block and for loop,
therefore q.dp can never be used uninitialized.

4096   if (c != NULL) {                                                             
4097       if ((res = mp_init_size(&q, a->used)) != MP_OKAY) {                       
4098         return res;                                                             
4099       }                                                                         
4100                                                                                 
4101       q.used = a->used;                                                         
4102       q.sign = a->sign;                                                         
4103   }                                                                             
4104                                                                                 
4105   w = 0;                                                                        
4106   for (ix = a->used - 1; ix >= 0; ix--) {                                       
4107      w = (w << ((mp_word)DIGIT_BIT)) | ((mp_word)a->dp[ix]);                    
4108                                                                                 
4109      if (w >= b) {                                                              
4110         t = (mp_digit)(w / b);                                                  
4111         w -= ((mp_word)t) * ((mp_word)b);                                       
4112       } else {                                                                  
4113         t = 0;                                                                  
4114       }                                                                         
4115       if (c != NULL)                                                            
4116         q.dp[ix] = (mp_digit)t;                                                 
4117   }

Best regards,

Kaleb