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
I mean, I see in the code how are they used, and also see the algorithm in Wikipedia. I wonder though, why may we need s1 and s2 being non-null, what benefit does their presence carry?..
It looks like in some cases (e.g. when the encrypted message is not sent over the wire to someone, but instead is stored locally and is encrypted just for privacy/security reasons), making s1+s2 process optional (and removing the tag suffix from the message) may free up some CPU resources.
The text was updated successfully, but these errors were encountered:
Yes, lots of performance optimizations could be made to current implementation. I was just trying to make the code simple because I believe the performance cost of those parts would be very small compared to ecdh calculations. What is your use case? Is that very performance-critical?
My usecase is encryption of the users’ data before writing it to some storage. The ciphertext is not transmitted over a public network, so there is no need for authentication.
What about doing encryption on client side or simply using a symmetric block cipher? The first choice resulting an end-to-end encryption and the second one is better than ecies for streaming and reading from random offsets.
I mean, I see in the code how are they used, and also see the algorithm in Wikipedia. I wonder though, why may we need s1 and s2 being non-null, what benefit does their presence carry?..
It looks like in some cases (e.g. when the encrypted message is not sent over the wire to someone, but instead is stored locally and is encrypted just for privacy/security reasons), making s1+s2 process optional (and removing the tag suffix from the message) may free up some CPU resources.
The text was updated successfully, but these errors were encountered: