signalapp / libsignal-protocol-c

GNU General Public License v3.0
1.41k stars 295 forks source link

Make EC25519 implementation optional for static library #141

Open david-komarek opened 4 years ago

david-komarek commented 4 years ago

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.

dkonigsberg commented 4 years ago

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 commented 4 years ago

@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 commented 3 years ago

و