Current master doesn't allow selecting curves at run-time

[mouse07410]

FIle relic_conf.h sets the default value F#define FP_PRIME 256. The following code in relic_ep_param.c makes sure that a curve is compiled in only if FP_PRIME is set to the corresponding value:

#if defined(EP_PLAIN) && FP_PRIME == 384
                        case NIST_P384:
                                ASSIGN(NIST_P384, NIST_384);
                                plain = 1;
                                break;
#endif

That precludes the code that uses this library from choosing curves at the run time, forcing to compile one curve only.

I hope that was not the intention, and urge fixing this. One way to do that would be removing the && FP_PRIME == xxx part from the corresponding #if defined(XXX) ...

[dfaranha]

Selecting parameters at compile time is the main design decision behind RELIC. :)

[mouse07410]

I'd really like you to reconsider.

In my use case, being able to process data secured by NIST P384 and P256 is desirable. Having to recompile for each of these is not.

Update
Also, how do I tell the current RELIC that I want, e.g., NIST-P384 curve?

[conradoplg]

I think it's possible to support curves with different sizes without affecting performance, maybe someday I'll convince @dfaranha 😆

But it would need a complete overhaul of the library, so it would take some time, if it will ever happen.

You can take a look at BearSSL if performance is not critical, it's a great library.

You can select the curve by calling ec_param_set(NIST_P384) and setting FP_PRIME=384.

[mouse07410]

I think it's possible to support curves with different sizes without affecting performance, maybe someday I'll convince @dfaranha 😆

I don't see any speed-wise performance impact of supporting multiple curve sizes. There would be some memory impact - but, say, between P256 and P384 I think it would be negligible.

You can take a look at BearSSL if performance is not critical, it's a great library

Unfortunately, performance does matter in my case.

You can select the curve by calling ec_param_set(NIST_P384) and setting FP_PRIME=384

I'm sorry, but I don't fully understand.

1. The library is built via CMake and CMakeLists.txt files, which have a ton of configurable parameters. Is there a parameter (or a set of parameters) that I need to set to compile-configure the library to use NIST_P384?
2. If the library is compiled to support one curve anyway, what's the point of doing ec_param_set(NIST_P384) (instead of, e.g., ec_param_set()), when the parameter obviously cannot matter?
3. Where should I set FP_PRIME=384? What file(s) and at what time?

Thanks!

[dfaranha]

Supporting multiple curve sizes implies function pointers for each field arithmetic function, which are a mess to deal with. Regarding your questions:

1. Setting FP_PRIME=384 in CMake.
2. There could be multiple curves defined over 384-bit fields. Check 256-bit fields to see multiple parameters.
3. CMake configuration at compile time.

You can also build multiple versions of the library for different parameters and link them together. Check the LABEL configuration variable for that.

A massive refactor of the library to support this is not in my current plans. I already have a hard enough time to maintain the library somewhat working, and can barely make progress in the current refactoring/cleanup with all my other work-related activities. Anyone is welcome to fork the library and adapt it to their needs.

[mouse07410]

I thought that FP_PRIME should be set in CMakeLists.txt, but couldn't find it there. How should I set it? As a define added to CFLAGS? Or...?

Since the library is built as a part of another project, ideally I shouldn't need to specify parameters in the invocation command...

[dfaranha]

You can pass configuration switches when invocating CMake to build the Makefiles.
What other project are you referring too?

[mouse07410]

My library provides high-level crypto API and uses RELIC for the actual ECC operations. And it's also built via CMake... So I do not invoke CMake manually in the RELIC directory.

[mouse07410]

Could you please give an example of how to pass FP_PRIME parameter to the CMake? Thanks!

[dfaranha]

You probably figured this out already after all these years, but it's cmake -DFP_PRIME=384 <path_to_target>.

[mouse07410]

As I said in #77 (comment), I am not invoking CMake manually - thus cmake -Dxxxx method of passing arguments isn't likely to work for CMake config a few directories down.

[dfaranha]

I imagine you can then import RELIC's CMakeLists.txt and configure it programmatically as in this example.

[dfaranha]

I recently learned of ExternalProject support in CMake and figured out I should leave it as a suggestion here.