not fast enought

[ahfuzhang]

At first, I write a golang wrap of this lib, because golang version of ecdsa is not fast enought. But I found this lib is slow 10 times of go version.

Those are my test result:

go  26986 ns/op
c   292030 ns/op

And my test code:

const struct uECC_Curve_t * curve;

void init_ecc(){
    curve = uECC_secp256r1();
}

int main(){
    init_ecc();
    uint8_t private[32] = {0};
    uint8_t public[64] = {0};
    uint8_t hash[32] = {0};
    uint8_t sig[64] = {0};
    get_public_key(public);
    get_private_key(private);
    get_hash(hash);

    const runtimes = 10000;
    struct timeval start, end;
    gettimeofday(&start, NULL);
    for (int j=0; j<runtimes; j++){
        uECC_sign(private, hash, sizeof(hash), sig, curve);
    }
    gettimeofday(&end, NULL);
    int span = (end.tv_sec - start.tv_sec)*1000000 + (end.tv_usec-start.tv_usec);
    printf("spend: %d us, avg=%.4f ns/op\n", span, (double)span*1000.0/(double)runtimes);
    return 0;
}

And my compile line:

clang -o build/c c/main.c -g -Wall -I"pkg/" -mavx -mavx2 -O3 \
        -DuECC_OPTIMIZATION_LEVEL=3 -fomit-frame-pointer

I wish this lib can beat golang version. Thanks.

[CryptoManiac]

The golang wrapper wouldn’t do any good regardless of how fast the library is. First of all, there is a marshaling overhead that will consume all the difference. Second, you’re not taking the implementation details into account. Like what kind of RNG is used for signing in both cases? Then there is a fact that such a wrapper will be insecure, leaking the copies of your secrets around almost everywhere. When it comes to cryptography, using FFI is not a good idea.