Open tianyuan129 opened 5 years ago
The adaptation needs to pass -DFEATURE_PERIPH_HWRNG
to compiler, so that normal signing is selected at compile time.
It would be a bad idea to select code path at runtime using if-else, because it increases binary code size.
Yes, and I'm not saying to use runtime if-else. I think I missed something here. No documentation have ever mentioned about FEATURE_PERIPH_HWRNG
and how to use it, so if you simply follow instructions on README, normal signing is never used. One can only see a simple statement below:
/**
* Sign a buffer using ECDSA algorithm. This function will automatically use
* deterministic signing when no hardware pseudo-random number generator is available.
* The signature generated will be in ASN.1 DER format.
What I wonder is should adaptation define the FEATURE_PERIPH_HWRNG
in code, otherwise we should improve the documentation.
esp8266ndn defines FEATURE_PERIPH_HWRNG
in code:
https://github.com/yoursunny/esp8266ndn/blob/087ebd7a4a9c83766decf941b13c43af86de96e7/src/ndn-lite/security/default-backend/ndn-lite-default-ecc-impl.c#L1
but this isn't the best approach.
It should be in Makefile, but Arduino doesn't allow libraries to set compiler flags.
Given security-frontend invokes security-backend via function pointer, one option is:
ndn_lite_default_ecdsa_sign_randomized
and ndn_lite_default_ecdsa_sign_deterministic
functions.ndn_lite_default_ecc_load_backend
function, which chooses correct signing variant; remove set_rng
function.ndn_lite_default_ecc_load_backend
function must appear in header, so that compiler can optimize out unused signing variant.
Current ECC backend uses macro
FEATURE_PERIPH_HWRNG
to decide whether to use deterministic signing.It's a copy from RIOT and shouldn't have been here. Also since non-RIOT package (e.g., POSIX) never uses this macro, each
ndn_ecdsa_sign
will fall intouECC_sign_deterministic
even if they already set a RNG (e.g.,ndn_lite_startup
in POSIX package).