CC2642R: EdDSA Signature Verification of a Very Long Message

Hello Chris,

I am looking into your issue, and I will reach back out to the thread's author! 

Thanks,
Alex F

Hello Chris,

Looking into the F2 SDK and comparing the 7_10 sdk to the 7_40 SDK the EDDSACC26X2.c files are the same (unchanged) with these two releases a year apart. Looking internally, I currently cannot find an exact example of the linked reference, though I will see if there was one made. 

Thanks,
Alex F

I have a new additional question...

While waiting for feedback on this, I dug more into the EdDSA specification, and I've started trying to make a slightly easier modification to the driver to start out with, trying to implement Ed25519ph.  I then found <this thread> which was a similar suggestion from Clément.

However, after making the modifications, it seems building the project doesn't actually use my code.  I've only included my headers everywhere, and even tried to remove the source code files from the SDK, but it still runs the stock versions of the functions instead of my changed one.  So next I tried changing the name of the EDDSA_verify() and EDDSA_runVerifyFSM() functions to make sure that it was mine that were being called, and then I wasn't even able to build the project because of linker errors; not on those functions, but on all the other functions whose names I didn't change, because now it was actually using my file, and it saw all the unchanged functions as symbol conflicts with apparently precompiled libraries:

#10056 symbol "EDDSA_init" redefined: first defined in "./Drivers/EdDSA/EDDSACC26X2.o"; redefined in "C:/ti/simplelink_cc13xx_cc26xx_sdk_7_10_01_24/source/ti/drivers/lib/ticlang/m4f/drivers_cc26x2.a<EDDSACC26X2.c.obj>"

So my question is this: how do I tell the project not to use the precompiled version of the library?  With the older compiler and older versions of the SDK, this was as simple as copying the source file from the SDK into the local project, changing it there, and building it, such as is suggested in <this thread>.  That apparently no longer works, so how would I go about doing that now?

(Idk if you found it from somewhere else I shared the info, but I am indeed using the 7.10 version of the SDK.  However, I apparently put the wrong processor in this thread's title, as we are actually using the CC2652R1F and CC2652RB.)

Hello Chris,

For your new question I will see if Clement can provide some additional feedback here to assist you.

Chris Hunt said:

So my question is this: how do I tell the project not to use the precompiled version of the library?  With the older compiler and older versions of the SDK, this was as simple as copying the source file from the SDK into the local project, changing it there, and building it, such as is suggested in <this thread>.  That apparently no longer works, so how would I go about doing that now?

-Usually if we want to modify a library file we would drag it into the local project and tell the project to reference the local version instead of the library version here, from what I can tell you are already doing this but are getting errors. We could try modify the library project itself (*make a copy of the original to replace just in case) here.

Thanks,
Alex F

and tell the project to reference the local version instead of the library version here

How do you do that part?

Hello Chris,

As an example, what I do is take #include <ti/drivers/rcl/commands/ieee.h> and change to #include "ieee.h", this should tell the project to look at the "local" version instead of the SDK version. 

Thank

Oh, well then yes, I did all that and more, and it is still trying to use a precompiled version.

Hello Chris, 

There could be a makefile or library being pulled in by syscfg at times. 

I will ping Clement to see if he can give feedback on your previous question! 

Thanks,
Alex F

Well, you have my error message; is that what would happen?  And how would I prevent that?  It's worth noting that we disabled syscfg years ago, so it shouldn't be newly pulling this in.  I had to add the ti_drivers_config.c/.h entries by hand, and they also only reference my local header files.

Hi Alex and Chris, 

Reading through your exchange, I belive you should first ensure the project is built using the modified drivers file. 

Unless configured differently, the project will build using the pre/compiled libraries - which have certainly not been rebuilt after modifying the EdDSA code. 

You then have two options (I personally prefer the first one):

- option 1: copy the modified file inside your project

- option 2: rebuild the libraries as mentioned here: https://software-dl.ti.com/simplelink/esd/simplelink_cc13xx_cc26xx_sdk/7.41.00.17/exports/docs/simplelink_mcu_sdk/Users_Guide.html#rebuilding-the-libraries 

I hope this will help,

Hi again, 

One more comment - looking in the code I believe the suggestion I made a few years back should still be applicable. 

Best regards, 

Clément said:

I belive you should first ensure the project is built using the modified drivers file. 

Clément said:

You then have two options (I personally prefer the first one):

- option 1: copy the modified file inside your project

As stated already, if I copy the modified file inside my project, one of two things happens, depending on how it's modified: either 1) I don't change the names of the modified functions, and the project builds, but when it runs it is clear that modified versions are NOT the ones being called because they don't do what I modified them to do, or 2) I change the names of the modified functions to make sure that it's only mine that are being called, and then the project WILL NOT build because of the linker errors shown above, where I'm told that I'm redefining all the rest of the functions that I didn't rename, because it's still ALSO trying to use the precompiled versions of them.

Clément said:

Unless configured differently, the project will build using the pre/compiled libraries

So again, how do I configure it differently to not use the precompiled libraries?  

Hello Chris Hunt,

We can do a quick test here in debug mode:

1) Create a local copy of your modified driver in your local project. 

2) Change the #incluide <SDK Driver> to #include <local version> in the application files. 

3) Place two breakpoints, one breakpoint on your function call in application code, and one breakpoint in the modified driver in the function that should be called.

4) Enter debug mode and stop on the breakpoint in application code function

5) Step into the function and what happens:

A) do you enter into the modified driver

B) do you enter into the SDK driver

Thanks,
Alex F