You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 12, 2022. It is now read-only.
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.
The text was updated successfully, but these errors were encountered:
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.
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.
I have:
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
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.
The text was updated successfully, but these errors were encountered: