1 Topic by michymd

(2 replies, posted in wolfCrypt)

Hello,

I have read this paper https://eprint.iacr.org/2017/806.pdf on a side channel attack on Libgcrypt’s implementation of curve25519.

There are some countermeasures (I list them below) suggested to make ECC library resistant to this type of attack, and I would like to ask whether these countermeasure have been implemented in WolfSSL Crypto.

Countermeasures:
1) Constant Time Arithmetic
2) Rejecting Known Bad Points
3) Point Blinding
4) Scalar Randomization

About countermeasure 1), in the manual I read "wolfSSL provides the function “ConstantCompare” which guarantees constant time when doing comparison operations that could potentially leak timing information". Is "constant time" achieved also for the field arithmetic operations used for ECC?

About countermeasure 3), I know there is an build option, --enable-harden, that provides point blinding. Could you confirm that this applies to ECC points?

To sum up, my question is: is WolfSSL implementation of curve25519 vulnerable to the attack described in the paper?

Best regards,
Michela

Go to forum: wolfCrypt

2 Reply by michymd

(8 replies, posted in wolfCrypt)

Hi Jacob,

I wanted to recreate the key pair from the private key to perform a check of the endianness.
I was thinking that this key regeneration API could be also useful for checking the correctness of the imported key pair. When I import private/public key, if the key gets recreated, then a comparison between the recreated public key and the one passed in could signal an error in the imported key pair. I see this useful when performing tests.

I would have another question this time related to Ed25519 (should I open another topic for this?). I couldn't find in the source code any comment about the endianness of the exported keys. I have looked into the API code and what I could get from the maths operation is that the outputted keys should be big endian. Could you confirm that my understanding is correct?
In curve25519 case, import/export methods can be adapted to the desired endianness. Why that is not possible for ed25519?

Thank you very much for your help.

Regards,
Michela

Go to forum: wolfCrypt

3 Reply by michymd

(8 replies, posted in wolfCrypt)

Hi Jacob,

is there an API that allows to compute a public key by providing a private key as input? I have had a look at the import functions and if I'm not wrong the import of the private key doesn't trigger the derivation of the public key.

Thanks,
Michela

Go to forum: wolfCrypt

4 Reply by michymd

(8 replies, posted in wolfCrypt)

Hi Jacob,

I inverted the bytes of the private key I obtain by using wolfSSL wc_curve25519_make_key(..), input that into another librariy and finally got the same public key! Thank you for mentioning the little/bin endian format smile

Regards,
Michela

Go to forum: wolfCrypt

5 Reply by michymd

(8 replies, posted in wolfCrypt)

Hi Jacob,

thanks for replying.
What I did was to generate the key pair using wc_curve25519_make_key(..). Then printed the private key and used it to generate the public key using other libraries, among which the one I mention in the post that generates a different public key. I used yet another library with which I get the same public key generated with wolfSSL API. I'll try to use the *_ex function instead and see if I get the same public key.

Thanks,
Michela

Go to forum: wolfCrypt

6 Topic by michymd

(8 replies, posted in wolfCrypt)

Hi,

I wanted to ask a question about the implementation of Curve25519. I have used wolfssl and the "donna" implementation https://code.google.com/archive/p/curve25519-donna/. I have used the same private key with the two libraries to generate the public key but got two different public keys. What are the differences in the implementation of this curves? How does wolfssl differ from the donna implementation and what are the security implications?

Thanks a lot.

Kind regards,
Michela

Go to forum: wolfCrypt