Open mouse07410 opened 6 years ago
Selecting parameters at compile time is the main design decision behind RELIC. :)
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?
I think it's possible to support curves with different sizes without affecting performance, maybe someday I'll convince @dfaranha :laughing:
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
.
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 settingFP_PRIME=384
I'm sorry, but I don't fully understand.
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
?ec_param_set(NIST_P384)
(instead of, e.g., ec_param_set()
), when the parameter obviously cannot matter?FP_PRIME=384
? What file(s) and at what time?Thanks!
Supporting multiple curve sizes implies function pointers for each field arithmetic function, which are a mess to deal with. Regarding your questions:
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.
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...
You can pass configuration switches when invocating CMake to build the Makefiles. What other project are you referring too?
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.
Could you please give an example of how to pass FP_PRIME
parameter to the CMake? Thanks!
You probably figured this out already after all these years, but it's cmake -DFP_PRIME=384
As I said in https://github.com/relic-toolkit/relic/issues/77#issuecomment-389140733, 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.
I imagine you can then import RELIC's CMakeLists.txt
and configure it programmatically as in this example.
I recently learned of ExternalProject support in CMake and figured out I should leave it as a suggestion here.
FIle
relic_conf.h
sets the default valueF#define FP_PRIME 256
. The following code inrelic_ep_param.c
makes sure that a curve is compiled in only ifFP_PRIME
is set to the corresponding value: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) ...