• hstr
  • Member
  • Offline
  • Registered: 2016-04-28
  • Posts: 15

Topic: Questions about supported Elliptic Curves

Hi,

currently I am playing around with the ECC support of wolfSSL. I figured out that the curves secp256r1, curve25519 and ed25519 are implemented. But the usage of them are a bit confusing to me, so I got some questions about these curves.

- In the benchmark (https://github.com/wolfSSL/wolfssl/blob … enchmark.c) there seems to be no measurement for the sign and verify performance of curve25519. Is this intended? (Since there are sign/verify measurements for ecc (which I assume to be secp256r1) and ed25519)

- When I run the benchmark I get strange results regarding to ed25519. RSA needs 582 ms to sign and 20 ms to verify, ecdsa (secp256r1 ?) needs 178 ms to sign and 344 ms to verify, and now comes ed 25519 with very different results: 8 ms to sign and 20 ms to verify. Something seems to be wrong here, do you have any idea?

- Is there an option to run the TLS handshake with curve25519 and ed25519? I already think about problems with the certificates, since the included certs only support secp256r1. Are there any other issues with these new curves?

Thanks you,
hstr

Share

  • Jacob
  • Moderator
  • Offline
  • Registered: 2014-08-21
  • Posts: 79

Re: Questions about supported Elliptic Curves

Hi hstr,

It really is just that fast! Check out Daniel Bernstein's white paper on it here (https://ed25519.cr.yp.to/ed25519-20110926.pdf). He lists some cycles taken with the processor being used.

Leaving out sign and verify with curve25519 in benchmarking was intentional. The algorithm is set up to find a shared secret key rather then to sign/verify data. For ECC when doing sign and verify it is performing ECDSA, the equivalent of ECDSA would be setting up an ed25519 key and using it to sign and verify.

For use in TLS connections there was a start to a draft with curve25519 but it has not been finalized leading to potential future interoperability issues if used. Mainly the issue of certificates and which curve to use was handled by TLS extensions in the draft, such as with a namedcurve/ecc point format extension. So at the moment there is not an option to use curve25519/ed25519 in a TLS handshake only at the wolfCrypt level (non-TLS).

Regards,
Jacob

Share

3 Reply by hstr (edited by hstr 2016-09-01 01:40:56)

  • hstr
  • Member
  • Offline
  • Registered: 2016-04-28
  • Posts: 15

Re: Questions about supported Elliptic Curves

Hi Jacob,

thank you for the fast answer. I am still a bit sceptical about the performance of ed25519 since it would be over ten times faster than RSA/secp256r1. Even the paper does not mention an enhancement of this magnitude.
How complex would it be to change the code such that it is able to use ed25519/curve25519 for the handshake? This is actually a more general question, how can a custom cipher suite be implemented that uses algorithms which are not included by default?

EDIT:
The code size of a .elf file with ed25519 usage is much bigger than the code size with secp256r1 usage (around 75 kB difference). It seems like there is a trade-off between speed and size.

Regards,
hstr

Share

4 Reply by hstr (edited by hstr 2016-09-05 01:48:15)

  • hstr
  • Member
  • Offline
  • Registered: 2016-04-28
  • Posts: 15

Re: Questions about supported Elliptic Curves

I just found that this trade-off seems to be intended. In the wolfSSL manual there is an option "CURVED25519_SMALL" described that reduces the code size a lot but also decreases the performance very much.

However my question about how to implement custom cipher suites remains.

Share

  • Jacob
  • Moderator
  • Offline
  • Registered: 2014-08-21
  • Posts: 79

Re: Questions about supported Elliptic Curves

Hello hstr,

Yes there is a trade with table look ups giving speed. The tables take up memory and can be disabled with autoconf using the build ./configure --enable-curve25519=small --enable-ed25519=small or like you mentioned with the macro CURVED25519_SMALL. Our trade off in this is on the extreme side, all or nothing.

For adding custom cipher suites there is a couple places in wolfSSL that code needs added. This is a general overview and good starting point for the code changes.

wolfssl/internal.h (BUILD_TLS_****new cipher suite*** macro. Addition of TLS_*** new cipher suite*** value to be passed on the wire -- example of value being set is around line 827ish.)

src/keys.c (Set up ssl structure with cipher suite info. For sig algo new block of code in src/internal would be needed if using ed25519. If using curve25519 a new specs.kea would need to be added and kea block of code to src/internal.)

src/internal.c (BUILD_TLS_****new cipher suite*** added to cipher_name_idx and cipher_names arrays. Addition of new cipher suite to InitSuites function. Addition of cipher suite requirements to CipherRequires function)

src/ssl.c (addition of cipher suite to get cipher name functions)

If adding in curve25519 and ed25519 the biggest issues and code changes will be the kea and sig blocks needed in src/internal.c along with potentially adding in a mechanism for negotiation of these algorithms.

Regards,
Jacob

Share