Skip to content
This repository has been archived by the owner on Feb 12, 2022. It is now read-only.

Make EC25519 implementation optional for static library #141

Open
1 task done
david-komarek opened this issue May 11, 2020 · 3 comments
Open
1 task done

Make EC25519 implementation optional for static library #141

david-komarek opened this issue May 11, 2020 · 3 comments

Comments

@david-komarek
Copy link

I have:

  • searched open and closed issues for duplicates

Bug description

curve25519-donna.c is built even for static libraries and this could lead to multiple implementation of ec25519 in binary.

Steps to reproduce

  • build libsignal-protocol-c as static library

Actual result: ec25519 implementation is part of static library.
Expected result: user should decide whether he/she wants the ec25519 implementation to be part of static library.

@dkonigsberg
Copy link
Contributor

The whole EC25519 subdirectory (including the mentioned file) is considered part of the internal implementation of the library. It is not a part that can be simply excluded or substituted with an external implementation. While it originally came from an outside source, it has been periodically modified to the needs of this library and I do not believe it can be cleanly substituted anymore.

From reviewing your open issues, I suspect you're running into this issue because the noise-c project made a similar decision. The last time I worked on a project that needed both a Signal Protocol implementation and a Noise Protocol implementation, the Noise implementation simply called into the libsignal-protocol-c functions for handling curve25519 signatures.

@david-komarek
Copy link
Author

david-komarek commented May 12, 2020

@dkonigsberg Thank you for you answer.

The whole EC25519 subdirectory (including the mentioned file) is considered part of the internal implementation of the library. It is not a part that can be simply excluded or substituted with an external implementation. While it originally came from an outside source, it has been periodically modified to the needs of this library and I do not believe it can be cleanly substituted anymore.

If you modified ec25519 code, you should probably rename these function to avoid link problems.

From reviewing your open issues, I suspect you're running into this issue because the noise-c project made a similar decision. The last time I worked on a project that needed both a Signal Protocol implementation and a Noise Protocol implementation, the Noise implementation simply called into the libsignal-protocol-c functions for handling curve25519 signatures.

How can noise-c call into libsignal-protocol-c functions? Whether curve25519_donna() is called from libsignal-protocol-c or from noise-c is up to linker.

One more thing. In curve25519_donna(), the part of code that modify e is commented out. Is there some reason to avoid these operations? Even RFC describes these operation as a part of algorithm.

@shw26y10
Copy link

و

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

No branches or pull requests

3 participants