Consider moving to BouncyCastle signature generation and verification
AnnaShaleva opened this issue · comments
Summary or problem description
This is a discussion issue raised in #3209 (comment). The suggestion from @vang1ong7ang is to use BouncyCastle for both Secp256k1/r1 and SHA256/Keccak256 signature generation and verification instead of a mix of built-in and BouncyCastle usages.
Read the conversation for context, please, and add your opinions. An alternative - to leave this code as it is now.
Where in the software does this update applies to?
- Crypto
Do you have benchmarks?
Do you have benchmarks?
Well, I think it's a question to @vang1ong7ang, since I'm stick to the second option, to keep it as it is now.
Do you have benchmarks?
Well, I think it's a question to @vang1ong7ang, since I'm stick to the second option, to keep it as it is now.
Me too, unless it's incredible faster
I think benchmarks is least of our worries. I think the main focus is security. We are giving up our trust to a 3rd party. If a bug is introduced; it could cost us time, money and reputation. This goes for any 3rd party whether or not it has a good reputation. Including Microsoft; but at least with Microsoft we know they do excessive testing.
I think we should implement our own code like we did already for ECPoint and everything else.
Specially considering this comment here #3209 (comment), I think that @vang1ong7ang was straight to the point.
I believe that in Neo2 we were BouncyCastle only as well, or a kind of fork from it.
As he said (to make it easier to follow here):
for blockchain, consistency is very important, and behavioral differences caused by architecture and platform cannot be tolerated.
the implementation of dotnet's Crypto library is to directly call the operating system API instead of implementing it by themselves. even their own developers are not clear enough about these behaviors.
We had benchmark before, built-in is much faster than BouncyCastle. And i dont think we should focus on things like this. Mnay other issues should have higher priority, such as adding unit tests, benchmarks, existing issues and pr etc.
We had benchmark before, built-in is much faster than BouncyCastle. And i dont think we should focus on things like this. Mnay other issues should have higher priority, such as adding unit tests, benchmarks, existing issues and pr etc.
In my opinion, deciding upon a benchmark is not the case for this issue. Just if the benchmark is something that limits use case or would limit in 2-5 years, something like that.
Obviously, I want to see the benchmark. But even without seeing the number I believe it is feasible because we use to use it.
Try to run a node with MAC would be good test as well, re-sync the chain and verify everything.
But why bother now? Do we really have any issue here? any problem was found? Any bug addressed?
ecdsa is definately one of the core of the core performance bottleneck, i dont see any reason of updating it if there is no obvious problem.
We had benchmark before, built-in is much faster than BouncyCastle.
Let's not forget that this is the reason for using BouncyCastle for OSX #2499
We had benchmark before, built-in is much faster than BouncyCastle.
Let's not forget that this is the reason for using BouncyCastle for OSX #2499
Good recall, @ixje .
In the past, before commit #2340, we use to have our "fork" implementation for Bouncy Castle and was working for all OS.
In order to fix the lack of support for koblitz curves in the C# native implementation, we moved to bouncy castle for OSX only #2511.
@shargon may recall that because he was the author of the PR.
@shargon, are you not in favor now for setting up an standard for all Operation Systems?
The way would be move all to BouncyCastle as suggested by @vang1ong7ang, which is similar to what we had in the past before PR 2340.
Including
Microsoft; but at least withMicrosoftwe know they do excessive testing.
@cschuchardt88 this is not true unfortunately
BouncyCastle performs better than native dotnet in consistency. just as me said
the implementation of dotnet's Crypto library is to directly call the operating system API instead of implementing it by themselves. even their own developers are not clear enough about these behaviors.
We had benchmark before, built-in is much faster than BouncyCastle. And i dont think we should focus on things like this. Mnay other issues should have higher priority, such as adding unit tests, benchmarks, existing issues and pr etc.
@Jim8y I agree that this is not an urgent problem, but I doubt the conclusion of this benchmark
and, FYI, dotnet/runtime#36107